Enterprises have become increasingly reliant on the Java platform in no small part because of its scalability to even the largest internet and transactional workloads. To maximize their investments in Java, they’ve sought trusted advisors to provide commercial support to augment their own teams.

After Oracle acquired Sun Microsystems in 2010, it continued to deliver Java in a primarily free and flexible way, just as Sun had done. Things became more complicated in 2018, though, when Oracle changed how it licensed its distribution of the Java Development Kit (JDK), which includes the Java Runtime Environment (JRE) and the JVM, and provides a platform for running Java applications.

This chapter covers the challenges created as Oracle repeatedly changed how it priced its support services and licensed its JDK, leading many organizations to consider migrating to OpenJDK.

Developers had been requesting a more agile approach to developing the core Java platform for some time, and this change led to more features being added to Java — and more rapidly — than ever before. 

This change in strategy also resulted in a major change to the way Oracle delivers updates and support. Instead of providing extended maintenance and support for all Java versions, only Long-Term Support (LTS) releases would qualify for that. 

More changes came in June 2018, when Oracle announced its new licensing and pricing for JDK, which it bundled with the Java SE subscription.

Paid support is a familiar component of open-source communities, and the change was accepted — but a move Oracle made three months later wasn’t. Oracle announced it would end free public updates for commercial use for Java 8 — which was then the most popular version of Java — in January 2019. Updates would still be available with a subscription to Java SE; however, if you installed the updates without a subscription, you’d be liable to Oracle for the cost of the subscription. 

Then, in April 2019, Oracle unveiled a new Java license: the Oracle Technology License Agreement for Oracle Java SE. 

The cost for using Oracle Java under these new terms increased. Organizations like Cornell University began to take steps to minimize or eliminate their dependency on Oracle Java. In Cornell’s case, it published a blog post asking users of its network to uninstall Oracle Java from their computers and to install OpenJDK if they needed Java. 

Oracle’s popularity with Java developers plummeted. According to a survey of 2,000 developers by Snyk (https://snyk.io), only 34 percent reported using Oracle JDK in the second half of 2019 — down from 70 percent the year before. 

On September 14, 2021, Oracle announced a new No-Fee Terms and Conditions (NFTC) license that partially rolled back the changes announced in 2019. A new LTS release would now be free under NFTC until one year after the next LTS release. This gave users a chance to transition their applications to the next release. The NFTC license was available for developing, testing, prototyping, and demonstrating applications and personal use of the Oracle JDK or for use related to internal business operations. Oracle also shortened the time between LTS release from three years to two years. 

The move was generally viewed as positive, but it had little effect on OpenJDK’s growing momentum. 

The named-user metric applied to all individuals authorized to use a program regardless of whether they were actively using it. These definitions left the door open for uncomfortable conversations with Oracle reps who were famous for setting up meetings “to talk about your Java usage.” Unpleasant in themselves, these meetings could be a prelude to painful Java audits. 

The new pricing seemed straightforward. Instead of counting processors and authorized users, organizations needing an Oracle Java SE subscription would count their employees. But how? The fine print contained a complex definition and caused many existing customers to do a double take. 

Employee-count metrics are not uncommon in the technology world. Companies like Dropbox, Okta, Salesforce, and Workday all charge per employee per month (PEPM). Oracle itself charges on a PEPM basis for products like Oracle Cloud HCM. But typically, PEPM pricing is tied to usage. 

The new pricing for Oracle Java SE was disconnected from actual Java usage and could result in a massive price increase. The more employees, the larger the price increase.

One question we’ve been asked a lot over the years is how difficult a migration will be. Behind this question, there is typically an assumption that the migration will be a heavy lift.

In fact, migrating to certified builds of OpenJDK can be very straightforward and simple for the vast majority of enterprises. If you’re migrating server applications, you’re not likely to encounter any challenges. There are just a few potential issues, typically involving older, deprecated desktop technologies (see Chapter 2).

Migrating from Oracle JDK to an OpenJDK distribution is so straightforward because the Oracle JDK and OpenJDK distributions that companies like Amazon, Azul, BellSoft, and Red Hat provide are all built using the OpenJDK source code and undergo extensive compatibility testing. (Chapter 2 covers some additional Oracle JDK components that are not from the OpenJDK project.)

At its simplest, migration consists of installing the new OpenJDK distribution and configuring your application to use it instead of the previously installed JDK. Ninety-nine percent of the time, your application will work perfectly.

This book covers the 1 percent of the time when something doesn’t work as expected, and explains how to avoid that or diagnose and fix it. Later chapters cover these corner cases exhaustively. But before getting into that, you may want to understand how OpenJDK providers can be so sure that their distribution is a drop-in replacement for the Oracle JDK.

The Java Technology Compatibility Kit (TCK) was created to ensure compatibility between different implementations of the Java specification. It’s essential for Java’s portability — for delivering the “write once, run anywhere” promise. The TCK provides a high level of confidence that an application that runs on one TCK-tested distribution will run the same way on another distribution that has also passed the TCK test suite.

Originally developed and licensed by Sun Microsystems, today the TCK suites are Oracle’s intellectual property and require an Oracle license.

To claim compatibility with Java SE, individual binaries within each OpenJDK distribution must pass the TCK suite associated with that version of Java. TCK suites consist of more than 100,000 tests (about 126,000 tests for Java 8 and about 139,000 tests for Java 11).

Examples of TCK tests include language and application programming interface (API) tests, which verify that an implementation of Java meets the required specification of the syntax, semantics, and functionality of the language and its associated libraries. In addition, TCK tests for the JVM ensure compatibility across different operating systems and hardware architectures. TCK tests cover every aspect of the JDK, extending to features like printing, sound, and graphical interfaces.

Passing the TCK suite ensures that one distribution of a particular binary — say, JDK 17.0.7+7 — can be swapped for another distribution of that same binary that also passed the TCK. In this way, Oracle JDK can be exchanged for Azul Zulu Builds of OpenJDK, for example.

Passing the TCK also carries an additional benefit critical for commercial use: Conforming implementations inherit the right to use all the intellectual property in the specification defining that Java version.

Thanks to TCK testing, enterprises have a choice of OpenJDK distributions to choose from. These distributions differ from each other in ways that we explain in Chapter 4. For now, the important thing to understand is that you have options, and your chances of finding a distribution that meets the exact needs of your organization are high.