It´s not a fact neither an illusion. The end of Java is one of the multiple alternatives of the possible futures for Java (not the most likely, hopefully) and being informed can help us to avoid the disaster (insert your favorite Sci-fi movie quote here 😉 )
Two big milestones have been achieved with latest Java announcements: one is the six-month release plan for new versions; the second is the license restriction Oracle imposes for Oracle JDK, but not for their OpenJDK compilation, that will be released under the GPL License
What may be the consequences of both statements?
The first one means that Java 10 phased out its updates by September 2018 albeit Java 8 will have some updates until December 2020 least. This is quite a change in comparison to the previous 3-year cycle, we were used to with former versions. Java 8 seems to be most recommendable version to have. In this case, we will have plenty of time to decide before anything serious happens.
But what will happen in 2021 assuming you stay in Java 8? Java 8 will become obsolete, no patches, not even the security ones. And that is bad for any connected application. You’ll have to migrate your applications, either to Java 11 (as it has been marked as a LTS version) or Java 15, which is predicted to be the latest GA version of java by then.
Here comes the second announcement.
If you use Oracle JDK, both Java 11 and Java 15 are ruled by the second announcement:
“License Rights and Restrictions
…
Further, You may not:
– use the Programs for any data processing or any commercial, production, or internal business purposes other than developing, testing, prototyping, and demonstrating your Application;”
This points to the fact that you will need a license agreement with Oracle for deploying your application into Production, with the benefits of having support, of course. It looks like that Oracle took full eight years (since acquiring Sun, who was the owner of Java) to take this step towards monetizing Java SE; Java ME and other components already need licensing (a similar problem occurred with Google’s Android that lead to trials).
But, Java was free, isn’t it?
Kind of. Java is free, but the binaries and compilations are not, that is why the real problem arises when you want to use the binaries of a company that requires licensing, like Oracle. You’ll have to pay for it.
What other options do you have besides Oracle?
IBM developer kit includes Java version 8 and its latest release is Java 8 service refresh 5 fix pack 22, released on September,27th 2018. This means it is alive, and it also has a lot of platform options. The IBM License seems not to restrict Production use. (Disclaimer: this is only an opinion, not a legal statement).
There’s also the option of OpenJDK that, at the time of writing this article, only covered the x64 (Linux, macOS, Windows) binaries.
SapMachine would enter in the same category as OpenJDK. They define themselves as a friendly fork (although they also include ppc64 architecture). As well as Eclipse J9 that adds Linux s390x as available platform.
And then we come to Azul, a company that follows the steps of other companies related to open source offerings: they have an OpenJDK version with both community and enterprise builds, as well as asociated support
What can we expect from each of these options? How do they compare with Oracle JDK? Will it be secure and will they evolve at a proper speed?
OpenJDK has a public Bug System for tracking all the issues. At the time this article was written, there were only 9 open bugs of P1/P2/P3 priority related to the Java 8 version. Fortunately, Oracle uses the same nomenclature that can be searched. Eight of those nine bugs can be found on the Oracle site, except JDK-8200110, that relates to some string mismatch at GCC compilation, which is a minor difference, almost irrelevant. OpenJDK seems to be a good option, unless further testing of your application shows the contrary, if this ever occurs.
IBM SDK, Version 8.0 Fixes can be encountered at their website, but they do not follow the same nomenclature as OpenJDK/Oracle JDK, so comparing the issues between both is quit complicated. But at their version 8.0 Service Refresh 5 they have fixed about 300 defects (around one thousand between all patches of version 8), so it seems that in terms of defects IBM Java is quite reliable. They also map their versions with Oracle 8 release builds. Again it seems a nice alternative.
On the other hand, OpenJ9 for Java 8 has only 9 open issues of a total of 40. This seems to be a very small number for a reliable product. SapMachine’s GitHub is even more desolate.
Please notice that the SapMachine issue tracker is mainly used internally by the SapMachine team to organize its work (i.e. sync with upstream, downporting fixes, add SapMachine specific features, etc.).
Read it in GitHub
General VM/JDK bugs are maintained directly in the OpenJDK Bug System. You can open a SapMachine issue with a reference to an open or resolved OpenJDK bug if you want us to resolve the issue or downport the fix to a specific SapMachine version. If you find a general VM/JDK bug in SapMachine and don’t have write access to the OpenJDK Bug System you can open an issue here and we’ll take care to open a corresponding OpenJDK bug for it.
Every SapMachine release contains at least all the fixes of the corresponding OpenJDK release it is based on. You can easily find the OpenJDK base version by looking at the SapMachine version string.
I still believe that this first paragraph offers little visibility and for end users “each version of SapMachine contains at least all the corrections of the corresponding OpenJDK version” can be vague and complex to contrast. Anyway, the mere fact of sending us the comments makes you feel that they care about your product.
Zulu systems seems not to have a public searchable bug tracker, but you can find information about their releases and how they map with OpenJDK. For example Zulu Release 8.33, 8.32 dated October 18, 2018 states that their updates for Java SE 8 map to Java SE 8, update 191 and update192. It doesn’t seem a bad option, but in the same way as Oracle, they focus on paid agreements.
The current panorama for Java
This is the current panorama for Java. The roots of all our developments and frameworks have moved, but there is a need for better stability, until a non-Java alternative arises and puts the developers’ world upside down. “Hopefully you experience”, as the old Chinese curse says.
? To be continuous… Java 11 makes its comeback
Juan Tavira
Universia
Specialist, architect and interdisciplinary geek passionate about all kinds of innovations. This is easy to say for oneself, but when my computing colleagues, my geek friends and even my wife say so, then it must be true somehow ;-). I also like to build violins as a hobby. I see code
