Oracle announced in 2018 that updates for Java 8 would become chargeable from January 2019, meaning organisations wishing to continue receiving updates for Java SE 8 must do something. It is Oracle’s preference that customers purchase Java SE licences.
Oracle have since transitioned Java SE to a subscription licensing model.
Java has many uses and can be found across an estate – browsers, desktop applications, Line of Business apps, mobile devices etc., so letting it exist unpatched presents a real security threat. It is key that each organisation understands what Java 8 they have running and assess the security requirements around keeping it updated.
The standard term is 1 year. Java SE Desktop subscription pricing starts at $2.50 per user per month and Java SE per-Processor licenses start at $25 per month, both with tiered volume discounts:
It’s not just the removal of updates for Java SE 8 that Oracle have changed, they’ve also changed license terms and support schedules for new versions.
This is available free of charge from Oracle under an Oracle Technology Network (OTN) license, allowing it to be used only for test and development purposes. There is also a new release cadence in place where new “feature releases” of Java will be made available every 6 months – meaning most releases will become end of life (EoL) after 6 months. As Oracle say:
“Java SE 9 has reached its End of Life with the release of Java 10, and Java 10 will do the same with the release of Java 11”
For organisations concerned about this rapid cadence, Oracle have said they will designate certain Java releases as Long-Term Support (LTS) releases. These editions will receive 8 years of commercial support from Oracle – so even if you’re not still running Java SE 8, it’s now more likely you’ll need to purchase Java support from Orace.
As an alternative to purchasing support to organisations may wish to look towards OpenJDK, the free, open-source implementation of Java SE.
Move to OpenJDK
OpenJDK is free and, with version 11, has feature parity with the non-open source version, the Oracle JDK. However, the Oracle OpenJDK follows the 6 month rapid release cadence mentioned above.
Move to OpenJDK with Red Hat support
Another option is moving to OpenJDK and purchasing support from Red Hat, who have a long history of providing paid support programs for many open source programs. December 2018 saw them announce support for OpenJDK on Windows, supplementing their existing support for installations running on Red Hat Enterprise Linux (RHEL).
While Red Hat have a strong presence in many large organisations, their recent acquisition by IBM may give business reasons to be wary.
This project was created in order to add OpenJDK to Linux distributions, such as Fedora, that require totally free, non-proprietary, software. The IcedTea 3.0 release is based on OpenJDK 8 and the current stable release, 3.10.0, was released on December 25th, 2018.
Another flavour of Open Source Java, this builds upon source code from several different places – including OpenJDK.
They have listed their support schedule here – https://adoptopenjdk.net/support.html – which indicates they expect to be able to support Java 8 until “at least September 2023”. They also expect to support Java 11 until “at least September 2022”.
Many instances of Java within your environment will come from it being bundled with other products such as Oracle Weblogic or IBM Websphere.
For Oracle products, you are still entitled to Java SE 8 updates for those instances. For Java bundled with 3rd party products, you probably are still covered. For example, IBM have an FAQ page that confirms:
“IBM customers have a continued right to use these Java technology components at no additional cost under the terms of the IBM product license”
But you should check with each 3rd party vendor to ensure they will continue to supply Java updates as part of your agreement. This means not only will you need to identify all your Java instances but also which products, if any, they came with – and then contact the various vendors to discuss their Java support terms.
This adds another opportunity for organisations to be caught out with Oracle support policies. It will still, no doubt, be easy for the Oracle Java SE 8 patches to be downloaded and thus distributed across the environment. Even if you take out Java SE Oracle subscriptions for some of your servers, how will you ensure the patches aren’t deployed elsewhere too?
This can quite quickly be become a complex subject (writing this article took me down so many rabbit holes!) and, while it is certainly something asset managers should be focusing on, it raises several different questions that will require the involvement of other stakeholders.
While many ITAM teams have great visibility into the Windows environment, can the same be said for the Linux/Unix part of your estate? In many cases no, and it’s likely to be in that area where Java is particularly prevalent – making the risk even greater. Is there a separate Linux/Unix team you can engage with? Your security team will probably have a better insight into that area – so work with them to compare, contrast, and consolidate data.
Even within the environments you do scan, are you comfortable with how your tool handles Java? Can it differentiate between standalone instances and those bundled with other products, or at least give you enough information to do that manually?
You’ll need to work with enterprise architects, development teams, application compatibility teams etc. to determine if migrating to a new version is feasible, and in what timeframe.
If moving to an Open Source alternative makes sense from a cost/licensing perspective – does it make sense from a development and security perspective? Even if the migration to another Java source is possible, how long will it take? What happens if you choose not to purchase support and then Oracle release a new Java SE 8 patch during the migration timeframe – are you prepared to risk being unsupported against potential security threats, or will you perhaps purchase 1 year of Oracle support as a stop gap? Where will that budget come from? Introducing more Open Source software will potentially mean new license agreements that must be understood and monitored going forwards too.
Whatever resolution you come to as an organisation, I think it’s safe to say it won’t be instant, and will probably involve quite a few people, so getting started now is a good idea.
Start scanning systems and start talking to other teams, understanding who knows what and who will need to take part in the conversations.
Oracle Java SE Subscription Price List: https://www.oracle.com/us/corporate/pricing/price-lists/java-se-subscription-pricelist-5028356.pdf
Oracle Java Cadence FAQ – https://blogs.oracle.com/java-platform-group/update-and-faq-on-the-java-se-release-cadence
Java SE Support Roadmap – https://www.oracle.com/technetwork/java/java-se-support-roadmap.html
Download Oracle OpenJDK – https://jdk.java.net/
IcedTea Project – https://openjdk.java.net/projects/icedtea/
IcedTea Project on Wikipedia – https://en.wikipedia.org/wiki/IcedTea
AdoptOpenJDK – https://adoptopenjdk.net/support.html
IBM Java FAQ page – https://developer.ibm.com/javasdk/support/commercial-licensing/