incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: Choice of JDK version (earlier -- Re: Source code checked in, what next?)
Date Tue, 20 Sep 2011 15:59:58 GMT
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:svante.schubert@gmail.com] 
Sent: Tuesday, September 20, 2011 03:16
To: odf-dev@incubator.apache.org
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?

[ ... ]



Mime
View raw message