I don't understand the security risk observation. Unless the risk is such that a particular API object/method is compromised, and that is being used by the ODF Toolkit redistributable classes, the compromise would presumably be in the JVM. But later JRE honor the class files and methods of applications built with earlier JDKs. (Backward compatibility is *very* strong in Java, is it not?)
And JREs can be updated on user systems without them having to reinstall all of their Java applications. That will also provide update of the classes and (class path) that is part of the Java JRE, yes? So, EOL of a JRE is different than EOL of a JDK. Are you concerned about use of a deprecated object or method that is in the Java API? (I agree that if there are new objects/methods you require, such as for encryption, then that is a reason to set a minimum compatible JRE version when your release has such a dependency.) (Of course, a security vulnerability in the ODF Toolkit is a different matter, but that has nothing to do with JDK/JRE EOL and how those security vulnerabilities are dealt with.) - Dennis -----Original Message----- From: Svante Schubert [mailto:[email protected]] Sent: Tuesday, September 20, 2011 03:16 To: [email protected] Subject: Re: Choice of JDK version (earlier -- Re: Source code checked in, what next?) [ ... ] Nevertheless there are no further security patches and there should be some date to move on, as we are saving time in our development, becoming more efficient. I am curious why people stick with an old Java version and taking the security risk? [ ... ]
