I am frequently asked by customers whether they should pay for Java going online and I often see the similar question “what to do now that Oracle has stopped the free Java version for business use” being raised in online forums. The immediate reason for this quandary is the change that Oracle has made to the Java release cycle and the associated licensing model. This was pre-announced in 2017, but only came into force for end users in January of this year. In this blog I will try to explain what changes have been made and what options there are in Java software.
Note: below text is purely informative and cannot be used to fully map your specific situation. Every situation depends on the specific products and contracts within your company and is unique. Your situation may therefore be completely different from the one described below.
Java release and support model
To understand the changes in the support model of Oracle with regard to Java, it is important to examine the general release and support model for Oracle Java. What exactly has changed?
The old model
Up until version 8 of Java, a “major release” was executed every two years, for example JDK 7 (Java Development Kit). Then during the two years following the Major Release, three “minor updates” followed (in this example JDK 7.1, 7.2, and 7.3). Approximately two years later there would be a next major release (in this example JDK 8).
The new model
The new Java model delivers a new release every six months. The first release according to this new model was Java SE 9 in September 2017. According to Oracle, the reason for the quick successive releases is to make the newest functionalities of Java accessible to developers as early as possible. The disadvantage of the large number of releases is that Oracle will no longer continue to provide support on all of versions.
Long Term Support version
Although developers will prefer to get access to the newest functionalities of the software as quickly as possible, most companies would rather have a stable and secure version of Java. Hence, a Long Term Support (LTS) version will be released approximately every three years. Version 11 was the first LTS variant, the next will be version 17. Version 11 is also referred to as version 18.9 (September 2018), based on the release date.
The above is visualized in the following image, from the official Twitter account of Java.
Oracle JDK vs Open JDK
In case anyone wonders, I will try to explain the difference between Oracle JDK and Open JDK. Oracle JDK requires a paid support license from version 11 onwards. This license offers “Commercial support”. These licenses are available for the Oracle LTS versions and provide, for as long as it is paid for, eight years of support from the release of an LTS version.
OpenJDK: a new version every six months
Although the name suggests otherwise, OpenJDK is also an Oracle product. Oracle releases OpenJDK under the GPL licensing model. This means that the OpenJDK version of Java can be used for free. However, as you can see in the image, a new version of OpenJDk will be released every six months. After this, Oracle will no longer issue security patches for the previous versions, with the intention that you upgrade to the next version.
OpenJDK builds from other providers
In addition to Oracle OpenJDK, there are more OpenJDK builds available released by other software providers, such as AdoptOpenJDK. Many of these OpenJDK providers promise to release security patches for more than six months. In the case of AdoptOpenJDK, the intention is expressed to provide continuous security patches for more than four years.
Commercial variants of Java
There are suppliers, such as SAP, IBM and RedHat, that release commercial variants of Java. If you are considering using their software, it is recommended to test whether the software that is dependent on Java is also compatible with these variants.
What does this mean for me?
You now have a brief idea of the changes in Oracle Java usage, but how do you know what is the best choice for your company? The first two options require an investment, the last two are free. Note that these free options can entail risks.
1. Pay for Java support
You have the option to (start) paying Oracle for Java support. As a paying customer you can count on eight years of commercial support on the LTS versions. As you can see in the image above, this gives more than enough time to bridge the period until the next Long Time Support version of Java.
2. Commercial version of the competitor
You can also choose to use a commercial Java version from another provider.
3. Update every six months
The third option is that you update your Java installations to the latest publicly available version every six months. This not only takes a lot of time, but also has the disadvantage that you will not receive patches if you are one day late with updating, as you would then be using an “outdated” version of Java.
4. No more updating
Another free option is to stop updating your current Java version. This way you can continue to use Java but, you run a security and stability risk. For commercial use of Java version 8 (JDK and JRE), update 182 is the latest free available update. The usage would then be based on the Binary Code Licensing Agreement. All subsequent updates require commercial support unless a user does not use it for commercial purposes. Updates for non-commercial use are free until December 2020.
Please note: every situation is unique and depends on contractual agreements with Oracle, contracts with other vendors, installed software and the design of your IT landscape. Your situation may therefore differ from the situation as described in this blog. Do you need help with making the right choice? Do you want to pay, but are unsure what is the best choice: “pay per user or per processor core?” Are you looking for a party that combs through your Oracle contracts and gives you independent advice about the steps to take? Feel free to contact me or one of my colleagues.
If you want to know more about Oracle and Oracle Java, book a meeting via CSM@itamsoltuions.nl