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.").
- Why does SDL keep on relying on Oracle's defective technology?
- What is SDL doing to permanently solve these recurring issues?