on one hand, I'm pretty ok with this, it helps more understanding that "hey, you're several security patches behind!" rather than just hiding the information in a build number.
what's not really clear at least from the article, how will new APIs be rolled out with this faster release cycle?
New APIs will be part of the every 6 months feature releases. Which means if you aren't on the LTS, you need to stay up with feature releases to get security updates after 6 months.
> The new Java release train means that there will be a new release of Java every six months. And when the next release comes out, the previous release is obsolete.
> In practical terms it means that there are no more security updates from Oracle.
What?!? If I have Java 9, I have to upgrade the day Java 10 is released to be secure? I have to do major (i.e. feature breaking) upgrades to get security updates?
How is this a sane policy, and how many people are going to be running unpatched Java versions?
Per Oracle's own EOL notices, the overlap seems to be only for LTS versions; Java 8 LTS full support runs through January 2019 with Java 11 (18.9 LTS) scheduled for Spetember 2018. But Java 10 (18.3), GA in March 2018, support ends Spetember 2018; and Java 9 support ends March 2018.
What are the practical problems Java apps typically run into when upgrading? Or is this more about not wanting to redeploy and test your app every 6 months?
as with every main version: Things can break. Using a Swing based app which I use every day and which I don't maintain... it did not work properly on Java 9 and I'm not responsible in fixing that.
I would say it depends, its quite easy to unknowingly depend on non-standard behavior that can break like HashMap iteration order.
What often causes issues is that every release has a new byte code version and the ecosystem relies heavily on byte code libraries so these will have to be updated across the board (eg. you use middleware that uses a framework that uses a byte code library).
Things on the top of my head that can break with Java 9:
- new gc logging options and format
- rt.jar and tools.jar are gone
- new JDK layout
- Corba, XML and Annotation classes no longer visible by default
- application class loader is no longer and URL class loader
20 comments
[ 2.8 ms ] story [ 43.3 ms ] thread> In practical terms it means that there are no more security updates from Oracle.
What?!? If I have Java 9, I have to upgrade the day Java 10 is released to be secure? I have to do major (i.e. feature breaking) upgrades to get security updates?
How is this a sane policy, and how many people are going to be running unpatched Java versions?
They’re a machine to strip mine money out of your pockets, and they’re always looking for a new angle.
https://jenkins.io/download/lts/
https://github.com/nodejs/Release
https://www.python.org/dev/peps/pep-0407/
Either you or joda.org are incorrect. Let's hope it's joda.org.
http://www.oracle.com/technetwork/java/eol-135779.html
What often causes issues is that every release has a new byte code version and the ecosystem relies heavily on byte code libraries so these will have to be updated across the board (eg. you use middleware that uses a framework that uses a byte code library).
Things on the top of my head that can break with Java 9:
- new gc logging options and format
- rt.jar and tools.jar are gone
- new JDK layout
- Corba, XML and Annotation classes no longer visible by default
- application class loader is no longer and URL class loader
- a different hack is required to munmap files
It's not too bad in general.