Java 9 is obsolete in just six weeks (20th March 2018). What? You haven't upgraded yet? Well, Java 10 is only going to last six months before it is obsolete too.
Update 2018-03-20: Java 10 is released. Java 9 is obsolete.
Release train impact
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.
What do I mean by obsolete?
In practical terms it means that there are no more security updates from Oracle. (Theoretically, the OpenJDK community could release security updates, but there is no sign of this yet). And since you don't want to run your software without the latest security updates, you are expected to upgrade to Java 10 as soon as it is released.
As a user of Java, here are three possible ways to approach the release train:
- Stay on Java 8, the current LTS (long term support) release, until the next LTS release occurs (Java 11)
- Move from Java 9 to Java 10 to Java 11, making sure you update rapidly to get the security updates
- Stay on Java 9 (or Java 10) and don't worry about security updates
If you have already moved to Java 9, you have effectively committed to option 2 or 3. If you care about security updates, you need to be prepared to switch to Java 10 shortly after it is release on 20th March. To do this, you probably should be testing with a Java 10 pre-release now. If you find that to be a challenge, you have to stop caring about security, or consider going back to Java 8 LTS.
However you look at it, being on the release train is a big commitment.
- Will your dependencies work on the next version?
- Will your IDE be ready?
- Will your build tool (Maven, Gradle etc.) be ready?
- Will your other tools (spotbugs, checkstyle, PMD etc.) be ready?
- How fast are you going to be able to update when the release you are on is obsolete?
Lots to consider. And given the number of external tools/dependencies to consider, I think its fair to say that its a bold choice to use Java 9 or 10.
Summary
With a release every six months, it is important to decide on an approach to the release train. If you want to upgrade every six months, great! But you'll need to test pre-releases of Java with your whole toolchain in advance of the release to ensure you don't get stuck on an unpatched obsolete release of Java.
Am I correct in understanding that there will be no overlap between the support periods for either Java 8 or Java 10 and Java 11? That is, the moment a new LTS support release is generally available, support for all previous releases immediately ceases?
ReplyDeleteThe support page is the only public confirmation of plans, which show a 4 month overlap between LTS releases (support for 8 ends 4 months after 11 is released): http://www.oracle.com/technetwork/java/eol-135779.html
DeleteThe four month overlap is only between JDK 8 ad JDK 11. If you look at Oracle's public presentations on this they show no overlap for future releases. When JDK 11 is released there will no longer be any public Oracle JDK binaries. These will only be available to users with a commercial support contract. Free binaries will be the OpenJDK builds released under GPLv2 with CPE licence. For those, there is *no* LTS release.
DeleteIn future, to use Java for free and get security patches you will need to change JDK *every* six months.
I have two specific criticisms with Java's release train plan:
ReplyDelete1) The name Java 9 gives the confusing false impression that it is using the same release model as Java 8,7,6,5. The Java 9 release should have been named Java 17.9 to communicate the change in release strategy.
2) LTS support windows should overlap. The idea that there is no planned public support overlap between one LTS release and its successor is crazy.
But beyond that, Java moving to a release train model sounds fine. Colebourne writes this post as if everyone will be forced to upgrade every six months. The release train model is designed to cater to crowds that want a slower upgrade commitment and don't necessarily need the very latest and greatest features and crowds that want the latest & greatest features but are willing to commit to frequent upgrades.
I imagine most Java users will stick with the LTS releases. A convenient analog would be most shops running Ubuntu servers just use LTS releases. But other shops will want the faster releases, and that's fine. Every shop will choose to do what serves them and their client/user base most effectively.
>1) The name Java 9 gives the confusing false impression that it is using the same release model as Java 8,7,6,5. The Java 9 release should have been named Java 17.9 to communicate the change in release strategy.
DeleteThe release strategy wasn't determined until well after the naming for Java 9 had been settled on. Further the year.month notation has been rejected in favor of continuing with a linearly increasing major version number scheme.
I think Stephen's point was that people/organizations that upgraded to Java 9 perhaps didn't realize how short of a TTL it had and with tooling dependencies it might not be easy to update to Java 10 in a few weeks and then again to Java 11. Basically people might had not realized what they were signing up for when the upgraded to Java 9.
I agree though that most organizations will likely stay on the LTSs. Heck how many orgs are still running Java 6 or 7?
People didn't know what they were signing up for with Java 9, because the release naming is almost deliberately confusing. Java 9 and Java 10 are these transient releases, but Java 11 is a real stable LTS release? That is going to cause lots of unnecessary confusion. The naming should communicate the LTS vs non-LTS distinction. Or it should use the Ubuntu style date-versions.
DeleteI don't know what is the main driver for this but to me it look absurd. They were already releasing a lot of patches with minor versions without increasing the major version, could have done with small features as well.
ReplyDeleteThe version numbering is absurd. The underlying release cycle is reasonable. Naming these short term transient releases as Java 9 + 10, and then releasing the big LTS release as Java 11 is going to generate lots of confusion.
Delete4. Remove Java.
ReplyDeleteI like this one, LOL.
Deleteme too.
DeleteHonestly, we are considering favoring languages other than Java because of this,.
DeleteSix weeks or six months?
ReplyDelete2018/03/20 is in roughly 6 *weeks*.
DeleteSince the article referred to on Oracles archive is already about six month old this should no be news to anybody following current development in the Java world.
ReplyDeleteHowever, I can see that this comes as a bit of a surprise since we are used to very long and somewhat erratic release cycles for Java. Each major release contained at least one big and complicated feature which either delayed the release for months or was itself pushed after delaying the release for a while to a later release. Project Jigsaw for example.
I for one am happy with the change of the release model. Going through the additional material on the Oracle page I found a presentation outlining the future LTS model in some detail.
If I got the details correct, JDK 8 will be supported until 2025, 18.9LTS until 2017 and 21.9LTS until 2030. So there will be a considerable overlap of LTS releases.
What I am not sure about is who gets this support. The main release train will be the OpenJDK which is only supported until the next available release. The Oracle JDK however is the one with the extended support. I assume that this support has to be bought from Oracle.
The support documentation however does not list an end-date for public updates on the LTS release. Only the Short-term releases are listed.
So Oracle finally wants to start making more money from Java. Only time will tell how this move is embraced by the company world.
We did consider the Ubuntu-style numbering scheme of 17.9 etc. That was the first proposal from Mark Reinhold, but the community rejected it. There were two reasons: firstly, the numbering scheme for Java is already part of the specification, so it would have required a formal specification change. Secondly, for better or worse many scripts parse the Java version so to change the numbering scheme would have caused a great deal of disruption.
ReplyDeleteThe rapid obsolescence of JDK 9 is no bad thing in my opinion: as the first stab at Jigsaw it always was going to be one to throw away. The adoption of the new release cycle has been a bumpy time but it's settling down now.
With regard to the support lifetime, this really only applies to those downloading binaries from Oracle: everybody else on Linux distros will use the OpenJDK that's packaged with their OS. It will be supported, along with the rest of the system, for whatever support period that OS uses.
Thanks for very informative and helpful article.
ReplyDeleteI was trying to find out the impact of this release train on other frameworks (JSF/Spring/Hibernate etc.) we use. Also as an architect/developer, should I migrate my current default JDK based application to OpenJDK+Docker Image model? We have application server shared by multiple applications, and all of those are developed on Oracle JDK (Java 8). Application servers uses Oracle JDK as well.
Considering OpenJDK being used as a reference for Java 7 onward, would it be safe to use OpenJDK for windows OS based local development, but keep using future Oracle LTS JDK for PROD servers?
Any suggestions?
The difficulty there is you would be running different versions on PROD so your testing in the lower environments would in theory not be very useful. Honestly, I don't think anyone has any good suggestions. Upgrading from Java 7 to 8 was a GIANT undertaking for our shop, and I've heard 9 is not as easy as 8 which wasn't easy anyway. For example, we had trouble with Oracle Coherence locking up on Java 8. You'd think - Oracle is Oracle right? Now, the Coherence team saved the day with an excellent fix - but the underlying problem was due to a Java 8 bug! Furthermore, this highlights the fact that "everybody else" has time to kick the tires a bit and submit bugs, and Oracle has time to make the fixes. I'm all for the speeded up pace, but I just don't think Oracle is capable of keeping up with their own pace, honestly. HOWEVER, if the license terms are not exorbitant, I think it would be fine to send a little cash towards Oracle, provided we get a good ROI. Given the quick turnaround for Coherence, that seems very possible. Will be interesting..
Delete