While SDL has been very timely in signalling the problem, and in publishing a workaround in the KB article, saying that this is not an SDL-created problem (as SDL representatives are saying for example on ProZ) is, I think, disingenuous.
Yes: the actual problem is caused by Java, so it is ultimately Oracle's fault, BUT
- It is SDL who decided to use Java - so it is SDL who is responsible for using Oracle's unreliable and/or defective technology.
- It is SDL who keeps on using Java - despite previous instances of problems caused by Java: as far as I can see SDL fine-tunes their tools to a specific version of Java (7.25 in this case), and then they cross their fingers and hope that the next version released by Oracle won't break Multiterm.
- When (not if) such problems happen, SDL have little recourse but to recommend to uninstall the latest Java version, and reinstall the previous one. This may bring back the Multiterm functionality, but, presumably, at a cost: if the new version of Java has been released to solve newly-discovered vulnerabilities in the previous version, SDL is asking its customers to stay open to said vulnerabilities.
This, to put it mildly, is not a "best practice" (though SDL claims it as such in their KB article: "Step 3: Follow-up for Best-Practice to avoid the question to install Java 7 Update 45 again.").
My questions:
- Why does SDL keep on relying on Oracle's defective technology?
- What is SDL doing to permanently solve these recurring issues?
Hi Riccardo,
ReplyDeleteJust to give a bit more background on this:
- We did do work for SDL Trados Studio and MultiTerm 2014 to have a more robust integration of Java, following Oracle's advice of digitally signing components etc. so that you can use their new security concept.
- Apart from slowing down the terminology work especially the first time you edit (since the Java runtime slows down when it checks the digital signature), this did stabilise the integration, avoided security prompts, allowed users to work with High security setting etc. - so there were many benefits for all types of users (not least corporate users with tight security around Java). Also it meant that old problems (repeated prompts that would not go away, for instance) were gone.
- We tested this enhancement with our beta users (100+) before the release of 2014 – all was working as expected, and welcomed as a good robustness enhancement. That is, as long as users worked with the then current Java version – Java 7 update 25 and 40…
- … then Oracle had nothing else to do then to break their own implementation by introducing a breaking change and/or flawed change that does not work as advertised (research is still ongoing around this – we know of two other vendors suffering the same issues, more are expected to follow as this issue spreads). Basically the change means that even digitally signed components – as produced by us according to specs (!) - no longer work, and there is no workaround at the moment from what we can see. This does seem to point in Oracle's direction that a new update may be needed to fix this problem; there are some rumours around this in forums already.
So in summary – we did solve problems but then new ones were introduced by the new "update". But you are right – this is another example that means we need to look for ways of replacing/refactoring this component as soon as we can. This will not happen overnight, but it's clear we need to do this.
Thanks,
Daniel
Director Product Management
Hi,
DeleteI came across this article just by chance while I was looking for a solution to the problem mentioned above.
I couldn’t agree more with you Riccardo, this is a SDL problem. And it's been a recurrent problem that has been lasting for a very long time, with many versions of Java. I have been patient at the beginning, uninstalling the Java release Multiterm didn't want to work with, reinstalling it because I needed it for other applications and so on.
I'm now really fed up of this, can't spend that much time with problems caused by an expensive and inefficient tool. No wonder why my clients, when I ask them if they are going to adopt Studio 2011 or 2014, answer me that they are looking somewhere else.
I'm sorry if this sounds a bit harsh but considering the constant trouble it creates, I think that SDL should really care a little bit about its customers. And Daniel's answer: "…we need to look for ways of replacing/refactoring this component as soon as we can. This will not happen overnight, …" is not very comforting …
Thanks,
Sylvie
EN, ES>FR Freelance Translator