Oracle Java – The real costs of Java

Java licensing

As a result of the recent changes announced by Oracle with regards to Java, the software vendor claims that they’ve simplified licensing by:

  • providing Open JDK builds under an Open Source license
  • providing Oracle JDK releases under the OTN license

The below graphical overview provides a picture of the release plan as announced by Oracle:

But does this mean that Java is still free, or do you have to pay for it now? Although not clearly stated, Oracle suggests that Java can still be used for free, as long as you don’t need the extra luxury of getting immediate support after a new version is released. In this article we’ll investigate why that extra luxury comes at a cost and what are the real alternatives.

The real costs and the alternatives

When looking at alternatives to use Java for free, let’s take Oracle JDK version 11 and onward out of the equation. As explained in one of our previous articles, as of version 11 you can use Java Standard Edition for free only for the purpose of developing, testing, prototyping, and demonstrating your application – this means NO production and none of the other situations that are restricted by the OTN license.

So, to get back to our question, if you need Java from Oracle for running production applications, it means the free alternative that you’re left with is to use Open JDK. Furthermore, to ensure compliance with all the security regulations you may be required to use the latest release with the latest security patches.

But is it feasible for you to always use the latest release? One of the difficulties of keeping up to speed with the new release cadence of Java is related to the compatibility of the applications for which Java is required. Let’s understand how that works and what are the operational costs of attempting to keep the pace.

Assume that you use an application published by a third-party company and written for Java 8. This automatically means the application is implemented with the technical features and functionalities included in Java 8. Now, let’s assume Oracle releases a new version of Java and stops providing free patches and updates for Java 8. To ensure compliance from a security perspective you would have to migrate to the new Java version. But is your third-party application compatible with it? Chances are rather big that it’s not. The third-party publisher needs some time to react to the new Java release. Therefore, it will take some time until the third-party application is fully compatible with the new version of Java and furthermore, it might also take some time to simply understand if and where there are any incompatibilities. To make this scenario more concrete, consider that instead of the third-party application we’re talking about one that is developed in house. How long would it take your developers to redesign it? This topic has been addressed extensively by Oracle in this article. Their answers prove that this is a real concern of the user community.

So, what do you do in the meantime? Your choices are either to keep using Java 8 or upgrade and hope your application still works. Of course, you can always be lucky and figure out that the application wasn’t using any of the removed features. The questions to ask now are: “how often do the Java version changes lead to incompatibilities?” and “how critical is this application for my business operations so that I can take the chance of upgrading?”.

To answer the question related to the Java version changes and the incompatibilities they generate, we can tell you that a significant number of features are deprecated and then removed with each release. We recently had a customer who was facing precisely this issue, related to the fact that support for Java web applets was removed in JDK 11. His applications were making use of this exact functionality. Consider what was the impact of this technology on the “Internet culture” and you’ll be able to judge for yourself how widespread are the effects of such a change.

So therefore, you need to look at how critical each application is for your business. That’s an assessment you have to do yourself. How much money does your business lose if the application is not running for a day, a week or a month?

This leads to the final question. What are the options for you as a commercial organization to minimize Java related costs (both licensing and operational) going forward? Our suggestion is to make an inventory of all your applications and systems that rely on Java. Identify the ones that are critical for the business and negotiate a good price for Java subscriptions to cover them. For all the remaining non-critical applications, investigate the possibility of using non-commercial Java releases (e.g.: Open JDK). Assess also the impact of not having the latest security updates and patches on the machines where these non-commercial Java releases are installed.

In conclusion, because of the changes for Java, free usage becomes an impractical option. The problem you’re faced with now is costs minimization. Reach out to us if you want to find out more about the background and reasoning behind the changes or in case you need help with regards to the practicalities related to the cost minimization problem.

Andrei has been working in the Software Asset Management industry since 2011 when he started as technical analyst in Oracle’s License Management Services (LMS) department. After 3 and a half years, he joined B-lay in 2014. Since then he’s been working with customers from various industries to help them get in control of their software license management. In parallel he’s contributing to B-lay’s internal automation for software deployment analysis. Andrei has a bachelor degree in Electronics, Telecommunication and Information Technology and a master in Database and Web Technologies.