Java has a fairly long history, which is well-documented in Simon Ritter's article A Quarter of a Century of Java. While Java's history hasn't the time span of languages like FORTRAN, COBOL, BASIC, and C, it has encompassed a series of adventures that did not happen with the other languages. In other words, Java has evolved much more during its time than the older languages ever evolved. C is still basically C, about the same C that I first learned and used in the 1980s. FORTRAN and COBOL still exist, but mostly in the form of libraries of legacy code that are wrapped into packages callable by more modern languages. As for BASIC, though it still exists, it never really became a mainstream enterprise language; furthermore, its structure wasn't sufficiently modular for it to be easily wrapped inside more modern languages.
Within the 25 years of Java's existence, we've seen all kinds of changes that never happened for most other prominent languages. In my earlier post Why Java, C, and Python Are Today's Most Utilized Programming Languages I noted the huge difference between the three languages. Why was Java created? In large part the problem was that when using older languages developers had to create different versions of their software in order for it to run on different operating systems and hardware platforms. The concept "write once, run anywhere" struck both developers and enterprises as being brilliant: it saved both time and cost for producing new software. A primary objective of the Java Virtual Machine (JVM) was to accomplish this.
Those of us who have worked on developing software on multiple operating systems and multiple hardware platforms understand the problem: you have a limited amount of time available to develop your application, but if you need your application to work on multiple platforms, having to create and maintain multiple code bases reduces your overall productivity. Furthermore, your Quality Assurance department also has to test and verify all versions of the software on all the platforms your target customer base may utilize.
The invention of Java was a solution for this. How did Java solve this? Via the Java Virtual Machine, which is actually a kind of software operating system that floats on top of all major operating system and hardware platforms, allowing developers to write one set of code that is (mostly) guaranteed to work on any major platform.
Six-Month Java Licensing and New Java Releases
At first, I thought "Wow, Oracle is adopting Agile Programming Methodology!" - this means we'll have new great Java updates every six months. But then I saw that as soon as the new Java update is released, Oracle support for the prior release disappears! This leaves any company that relies on the OpenJDK in a bind, since it means, in part, that Oracle's Critical Patch Updates that correct newly discovered security flaws exist only in the latest Oracle OpenJDK version.
This fact, in essence, forces any company using the OpenJDK to constantly update their product every six months to remain in sync with Oracle's new OpenJDK releases. Oracle's new licensing policy is subscription based, so in order to always have the latest, safest OpenJDK, you need to pay.
Are you ready for a high performance Java platform?
Download this Gartner® report to see if a high-performance Java platform can help your cloud-native or compute-intensive use cases
Java Licensing: The Problem for Development and Quality Assurance Teams
Even worse than having to pay for support for the latest and only Oracle-supported OpenJDK, is the impact on your software development and quality assurance teams. The new Oracle licensing at minimum requires your Quality Assurance team to go through a full testing sequence of your software every six months, because if you do not test your software using the newest Oracle version of OpenJDK, you put your customers at risk of your product suffering security risks (see Simon Ritter’s post How to Keep Your Java Applications Secure).
In a sense, this is contrary to the original objective of Java. You can write once, run anywhere, but with the new licensing policy you need to keep testing if your once-written software can still run anywhere every six months. To have to do this testing every six months is a significant burden on any start-up whose software is based on OpenJDK, but it’s also a burden on enterprise companies as well.
A Solution: Back-Porting Critical Fixes to Older JDK Versions
Is there a solution? Many companies now offer their own alternatives to the Oracle JDK. If your company has built its product on top of Java 8 or Java 11, you’re sort of out of luck with the new Oracle licensing scheme. You cannot just develop enhancements to your product feeling safe that what your development team produces is guaranteed to work for your customers if you are using an OpenJDK that Oracle no longer supports.
This is where companies like Azul can help. Azul supports the latest versions of OpenJDK, but it also provides versions of earlier widely-used versions of OpenJDK (like OpenJDK 7, OpenJDK 8 and OpenJDK 11) which include back-ported security fixes. So, if your company’s product is based on one of these earlier prominent Java versions, you can simply download the latest edition of Azul’s update for that Java version, and the necessary work for your development and quality assurance teams will be minimal.
