INTRODUCTION

Like many enterprises with large Java estates, you signed a support contract with Oracle to ensure
access to stable and secure builds of the Java Virtual Machine — as well as access to a support team
with JVM expertise to troubleshoot issues that arise during the application life cycle. Now the time
has come for renewal.

In light of the recent changes to the Oracle Java SE pricing, you have three choices. First, you can
switch to per employee pricing. Second, if you do not need to change your existing license in any
way — and you prefer to continue to receive Java support from Oracle you can renew under those
terms. Third, you can move to an alternative provider with a support offering and licensing terms
that align with your business needs.

The top considerations in choosing a JVM provider are:

1) Breadth of commercial support for different versions of Java, different platforms, and different configurations
2) A 1-for-1 replacement for the Oracle JDK. You don’t want to modify source
code or re-compile application code
3) Timely releases of security patches
4) Access to Critical Patch Updates, also known as stabilized builds, to minimize the
risk of regression
5) Duration of support terms (longer is better)
6) Engineering expertise. The support from an alternate provider should match or
exceed Oracle Java Support in expertise and responsiveness
7) Certified non-contaminating JVMs to protect your intellectual property
8) Cost of ownership and licensing

A Quick Note

It can be easy to become confused by references to different versions of Java, like Java
8, 11, 17 and so on, and terms like Oracle Java SE, OpenJDK and Oracle JDK.
The key thing to understand is that Java runs on a Java Virtual Machine. Updates to
the Java Development Kit (JDK), which includes the Java Virtual Machine, are released
every three months. These are delivered via new builds of OpenJDK, the reference
implementation for the Java SE standard. Oracle delivers Java SE to customers in a
combination licensing and support package that is sold as a subscription.

When we talk about different versions of Java, such as Java 8, 11 and so on, we are
talking about new builds of the Java Platform that support Java applications. In other
words, we are talking about new builds of the OpenJDK reference implementation,
which Oracle implements in the Oracle JDK.

Unsupported builds of OpenJDK can be downloaded for free under an open-source
license at jdk.java.net. Commercially supported builds of Oracle JDK are the ones that
you receive from Oracle under your Oracle Java SE Subscription.

While Oracle JDK is licensed under the Oracle Technology Network License Agreement and Oracle No Fee Terms and Conditions, OpenJDK can be used under the GNU General Public License version two with a linking classpath exception. Oracle JDK and OpenJDK are technically equivalent.

Alternative vendors can provide drop-in equivalents to Oracle builds, often at a much
better value, provided they have passed the Technology Compatibility Kit tests and
are certified compatible.

Consideration 1: Breadth of Commercial Support

Java’s many flavors

“What is Java?” It’s a question members of the Java community hear constantly. “It’s one of the
world’s most popular programming languages,” is the stock answer. But it is only half true. There
isn’t just one version of Java. As of the writing of this sentence there are 24 versions, with a new
version released every six months.
The pace of innovation has kept Java as one of the four top ranking languages in the TIOBE Programming Community Index. Java also ranks in the top five of the fastest and most energy efficient
languages (Alibaba Cloud, 10 Programming Languages That Are Energy Efficient, June 7, 2022).

But continuous innovation has its cost. In Java’s case, your organization is likely maintaining
applications built on multiple versions of Java, including older versions like Java 6 and 7 that are
no longer commercially supported by most vendors. (Azul is the exception.)

1,000 JDKs

When Sun released Java, the first “write once, run anywhere” software language, in January 1995,
the computing giant changed software development forever. Java decoupled applications and the
underlying hardware they ran on.

“Java’s write-once-run-everywhere capability along with its easy accessibility have propelled the
software and Internet communities to embrace it as the de facto standard for writing applications
for complex networks,” JavaSoft President Alan Baratz told TechInsider in early January 1996.
“We’re delighted to invite developers to download Java 1.0 immediately and start building the
next killer application.”

Java brought huge upside for application developers. But software engineers assigned to maintain
the underlying Java infrastructure had just as much work as before. The Java Virtual Machine, or
JVM, is the reason developers can write one application and run it on a server, a desktop computer,
and multiple embedded devices. The JVM acts as the interpreter between an end user’s computing
device and the Java application she wants to use.

Today there are as many JVMs as there are different types of computing devices running Java.
Commercial providers can maintain more than 1,500 JVMs to account for different Java versions
running on different operating systems and different processors with different configurations. These
are updated on a quarterly basis, when reference implementations are released containing security
patches, bug fixes, and enhancements. Continuous updates mean continuous debugging.

Guidance: Make sure your JDK provider supports all the JVMs used by your organization, including
older JVMs.

Consideration 2: A Drop-in Replacement for Oracle Java SE

120,000+ Compatibility Tests

Providers of OpenJDK builds claim their JVMs are drop-in replacements for the Oracle JDK. But
what does that mean and how can you verify their claim? The answer is simple if they are certified
Java SE compliant using TCK tests.

What is a TCK test? For at least 20 years, the Java Community Process, which oversees
each version of Java via a Java Specification Request, has included the Java Technology
Compatibility Kit (TCK), a suite of tests and tools used to certify whether an implementation
of a Java technology conforms to the specification.

To be a drop-in replacement for Oracle JDK, your OpenJDK provider must pass more than 120,000
tests. These ensure that you can swap out the Oracle JDK in two steps: by installing it in a directory
of your choosing and configuring your application — for example, by modifying the PATH environment variable to include the directory where OpenJDK is installed.

With a drop-in replacement, you don’t have to modify source code or recompile your application.
Indeed, the steps are similar to installing an update for the Oracle JDK.

Guidance: Only consider OpenJDK builds that are TCK-tested.

Consideration 3: Timely Release of Security Patches

Critical Vulnerabilities

The National Institute of Standards and Technology at the U.S. Department of Commerce defines
a software vulnerability as a security flaw, a weakness, or a glitch that is found in software code and
can be exploited by an attacker. Beginning in 1999, known vulnerabilities were assigned an ID. The
MITRE Corp., an independent, not-for-profit company, began tracking CVEs on behalf of the technology community in the CVE List, which has become one of the world’s most widely referenced
security databases.

Vulnerabilities on the CVE List are scored from 0 to 10, based on the Common Vulnerability Scoring
System that is published in the National Vulnerability Database. A score of 0.0 means no severity.
A score of 10.0 means critical severity. The log4Shell vulnerability which affected the popular Java
logging framework log4j, received a score of 10. An arbitrary code execution vulnerability, log4Shell allowed an attacker to execute commands of his choosing on a target device. But even relatively low scoring CVEs can put an organization at risk and must be patched.

Fixes to vulnerabilities in OpenJDK — the reference implementation of Java SE — are included in the
CVE List after they are reviewed by the OpenJDK Vulnerability Group. This group, which is made
up of trusted members of the OpenJDK community, collaborates on fixing reported vulnerabilities
and then coordinates the release of the fixes four times a year. Oracle leads the way with releases to
Java SE, and alternative providers follow at a cadence that can range from under an hour to several
days or weeks

Guidance: Make sure you receive quarterly security patches in lockstep with the publication of vulnerabilities to minimize your risk of becoming a victim of a data breach or other attack.

Consideration 4: Access to Critical Patch Updates, Also Known as Stabilized Builds

Stable and Secure

Security patches to OpenJDK are typically delivered in two formats. The most common format is
called a Patch Set Update. These quarterly updates contain the security fixes recommended by
the OpenJDK vulnerability as well as bug fixes and feature enhancements. Patch Set Updates, also
known as PSUs, can contain anywhere from 200 to 400 changes.

Can PSUs cause regressions? It is not unusual for a PSU to cause a regression. Some
of these can be quite serious, requiring out-of-band releases of new OpenJDK builds to
remediate the bug. In August 2022, for example, a new build was released for Java 8 to
eliminate the possibility of a system crash that had been introduced with a July update
(OpenJDK 8u342). Even more serious regressions have prevented access to critical infrastructure like Hadoop, Solr/Lucene.

For this reason, Oracle and Azul offer stabilized builds known as Critical Patch Updates. Rather than
include all the new quarterly bug fixes and enhancements, the CPUs only include new security fixes.
These are deployed on builds released the previous quarter and have had three months to stabilize. To date, a CPU release from Azul has not experienced a regression.

Guidance: Take the time to understand the difference between CPU and PSU builds of OpenJDK to
minimize your risk of regression.

Consideration 5: Duration of Support Terms

Stable and Secure

For most organizations, their default response to the question “which Java version should I use?”
is the version with the longest support terms. Once you build an application on a specific JVM,
keeping it on that JVM as long as possible can reduce maintenance costs.

According to New Relic’s 2022 “State of Java Ecosystem Report,” the most common version of Java
used in production is Java 11, which is known as an LTS version for its long-term support. According
to the report, 48% of applications are using Java 11 in production, up from 11.11% in 2020. Java
8, another LTS version, is the second most used version. Another 46.45% of applications are using
Java 8 in production, down from 84.48% in 2020.

Java 8 was released in 2014 with free public updates for Java SE. But in 2019, Oracle changed
the pricing terms. Java 8 and Java 7 were designated Long-Term-Support (LTS) releases. While
Premier Support for Java 7 ended in 2019, Oracle ended commercial support in July 2022. Oracle
also offered Premier Support for Java 8 through March 2022 and extended support through December 2030. But the cost of the support subscriptions took many organizations by surprise.
Alternative Java vendors can offer very competitive support terms compared to Oracle. In some
cases, the support offered for older Java versions is longer than that of Oracle. For example, Azul
offers extended support for Java 6 and 7 through December 2027.

Guidance: Look for a vendor with competitive support terms. Make sure you can negotiate even
longer terms if you need them.

Consideration 6: Engineering expertise

Shaping Java’s present and future

More than a quarter-century of sustained attention from top software engineers around the world
has made Java the language of choice for enterprise applications. From financial services to
health care device manufacturers, the security and stability of applications written in Java enable
everything from hundreds of billions of dollars in stock market trades every day to the operation
of life-saving medical equipment every minute.

But the more organizations turn to Java to run critical tasks, the more important it is that their Java
estate is supported and maintained by engineers with real Java expertise. Luckily there are a few
key indicators that make it possible to easily identify seasoned Java professionals.

Look for a provider with a history of participating in the Java community — someone who is a longtime member of the Java Experts Group that decides on the features of new Java releases and of
the OpenJDK Vulnerability Group that creates fixes for new vulnerabilities and coordinates their
release. You’ll want a company that is heavily focused on Java and that understands and appreciates open source. Ask them: How big is your Java engineering team and how many Java champions do you employ?

Guidance: With Java, experience matters. Hire the most seasoned team you can afford.

Consideration 7: Certified Non-contaminating JVMs

IP Protection

The creation of the GNU General Public license catalyzed the Open Source movement and, with it,
a software revolution. According to the Linux Foundation, Free and Open Source software makes
up 70-90% of any given piece of modern software today.

Open Source freed dev teams from having to recreate perfectly good programs — but it came at a
cost. The GNU General Public license also covered any programs that incorporated licensed code.
Proprietary code built from open source became open source. Industry groups concerned with
the protection of intellectual property dubbed this open-source contamination. The risk of opensource contamination was illustrated by a case brought by the Free Software Foundation against
Cisco Systems in 2009.

OpenJDK is licensed under the GNU General Public license v2. However, it includes IP protection.
Much of the code in any OpenJDK release is covered by the classpath exception, which grants
application developers permission to link to open source libraries and to publish their work under
the license of their choosing.

The problem is that not all of OpenJDK is covered by the classpath exception. The classpath
exception is only required for code that directly touches code in the JDK — but if a single file that
requires a classpath exception doesn’t explicitly carry the exception, the entire proprietary
application defaults to open source.

Organizations that want to retain control of proprietary code must carefully curate their code to
make sure that all the files that require a classpath exception have one.
Guidance: To protect your intellectual property, it’s important that each quarterly update is curated
by a trusted provider who is willing to certify non-contamination.

Consideration 8: Certified Non-contaminating JVMs

IP Protection

Prior to the January pricing change, the total cost of ownership for your Java applications was
largely determined by how many processors or vCores those applications required to run.
To reduce costs, organizations invested significant effort in optimizing the footprint of their Java
applications.

Going forward with Oracle Java SE, the number of processors used by your Java applications will
not factor into the cost of your Java SE subscription. Instead, cost will be determined by your headcount, including full-time, part-time and temporary employees, as well as agents, contractors and
consultants.

In many cases, tying the cost of a commercial support for Java to headcount will increase costs and
add complexity to IT budgeting. The cost of Java will now be tied to other departmental initiatives
that may be completely unrelated to IT.

You can, however, receive equivalent or better commercial support from providers who continue
to offer capacity-based pricing. For example, Azul uses a metric known as a vCore.

What is a vCore? A vCore, or a virtual core or a logical core, is a logical unit of computer
processing power able to run an operating system. This is the same metric used by major
cloud vendors like Amazon Web Services to price their virtual machines.

Choosing capacity-based pricing will allow you to focus on indirect costs that can have a huge
impact — like the quality of engineering support you receive from your JVM provider.
Minimizing the risk of a regression resulting from an unstable update by using stabilized builds
with security-only fixes (Critical Patch Updates) can also lower your total cost of ownership.
Similarly, access to timely security updates can dramatically lower the likelihood of a costly breach.
And using a JVM that is certified as non-contaminating will protect your IP.
Guidance: How you pay for Java can have a big impact on your TCO. Make sure you choose a
pricing model that is aligned with your business needs.

Conclusion

If you have made investments to limit your Java footprint, the new Oracle pricing
terms may not make sense to you. Azul provides a drop-in identical replacement for Java SE with
a pricing/support bill that is typically 70% less than Oracle.

All the considerations highlighted in this white paper can positively impact the cost of ownership
of your Java applications. Whether you choose to stay with Oracle or move to an alternative
provider, make your decision based on which options offer the greatest overall value.

Copyright © 2023 Azul Systems, Inc. 385 Moffett Park Drive Suite 115, Sunnyvale, CA 94089-
All rights reserved. Azul Systems, the Azul Systems logo, Zulu and Zing are registered
trademarks, and ReadyNow! is a trademark of Azul Systems Inc. Java and OpenJDK are
trademarks of Oracle Corporation and/or its affiliated companies in the United States and
other countries. Monotype is a trademark of Monotype Imaging Inc. registered in the United
States Patent and Trademark Office and may be registered in certain other jurisdictions. The
Monotype logo is a trademark of Monotype Imaging Inc. and may be registered in certain
jurisdictions. Other marks are the property of their respective owners and are used here only
for identification purposes. Products and specifications discussed in this document may
reflect future versions and are subject to change by Azul Systems without notice.