About cookies on this site Our websites require some cookies to function properly (required). In addition, other cookies may be used with your consent to analyze site usage, improve the user experience and for advertising. For more information, please review your options. By visiting our website, you agree to our processing of information as described in IBM’sprivacy statement. To provide a smooth navigation, your cookie preferences will be shared across the IBM web domains listed here.
Article
Where do you get your Java?
Have you considered IBM Semeru Runtimes?
On this page
If you download your Java directly, you might think that you can only get an official version from Oracle or a small number of providers. Over the last decade, however, there has been an explosion in the number of Java distributions available to developers to use to build and run their Java application workloads.
With so many options available, it's not always clear why any Java distribution might be a better choice than any other distribution. The goal of this article is to help developers to make an informed choice on the Java distribution they should use. For example, here is a list of some of the more commonly used distributions:
- Amazon Corretto
- Azul Zulu Build of OpenJDK / Platform Prime
- BellSoft Liberica
- Eclipse Temurin
- IBM Semeru Runtimes
- Microsoft Build of OpenJDK
- OracleJDK
- Red Hat Build of OpenJDK
The good news is that there really are no bad choices. All of the distributions reflect the core Java principles of robustness, security, portability, and ease of use. And all the distributions provide the same Java language features that are defined and evolved at the OpenJDK project. (More on that later.)
But that doesn't mean they're all the same, and it doesn't mean you shouldn't put some thought into which Java distribution you're using.
So what are the differences in all these Java distributions? How can I decide which one to use?
To help you learn how to answer these questions, this article starts with a brief explanation of the key parts of a Java distribution. Then, we'll point out some of the ways in which these distributions aren't all the same. We'll also discuss some of the reasons you might choose one distribution over others.
What's in a Java distribution?
These components make up a Java distribution:
- Java Virtual Machine (JVM)
- Just in Time (JIT) compilers
- Java Class Libraries (JCL)
Java Virtual Machine (JVM)
Everyone knows that the Java programming language was designed to be able to run a Java application anywhere, on any hardware platform. "Write Once, Run Anywhere" (WORA) was the famous guiding principle. To fulfil this principle, a very important component of Java called the Java Virtual Machine (JVM) was designed and detailed specifications for how the JVM executes Java programs were created. These specifications enabled a variety of vendors to create their own JVMs that expanded the early Java market to all kinds of servers and desktop machines.
Because of the specifications, these different JVMs faithfully ran Java programs on a wide variety of hardware platforms. Unlike some other languages like Python and Ruby that came before it, however, Java's virtual machine designers invested aggressively and early into unlocking the native hardware performance of the system running Java programs.
Just in Time (JIT) compilers
Specifically, Java vendors incorporated into their JVMs optimizing Just In Time (JIT) compilers that transparently compiled the platform neutral JVM instructions called "bytecodes" into native instruction sequences that run blazingly fast on each hardware platform.
These JIT compilers helped to propel Java into becoming a practical alternative to writing applications in the more popular, and high performance, languages of the time (C, C++, etc.). Of course, there's more to a JVM than the JIT compiler. There's garbage collection, thread management, monitoring, profiling, as well as the complex behavioural requirements to run Java programs properly on every platform. All of these components work together to deliver the excellent performance we know and expect from Java in the modern world.
Java Class Libraries (JCL)
There's also more to a Java distribution than "just" the JVM. Every Java distribution includes a comprehensive (about two million lines of code!) set of Java Class Libraries (JCL) that make writing Java applications easy without having to implement so much lower level code yourself. In fact, most Java applications depend much more on the public APIs presented by the JCL part of a Java distribution than the JVM part, and that's by design.
The JVM is intended to be mostly (ideally completely) transparent to the application: it's just "there" enabling the Java application to run and run well. On the other hand, an application will need to refer directly to specific classes in the JCL by name, located in specific packages, and the application will likely call named methods expecting to provide specific parameters that must have specific data types, etc. When any of those specific details change, which can happen when you upgrade to a newer version of Java, for example, an application needs to be updated to account for anything that changed in the newer version of the JCL. The designers of the language are well aware how painful those changes can be and they work incredibly hard on behalf of the entire Java ecosystem to minimize that pain where ever they can, while also working hard to improve the expressiveness and clarity of the language.
At the heart of the Java ecosystem: OpenJDK
OpenJDK is a source code project where the Java community collectively works on the reference implementations of the Java class libraries and a Java Virtual Machine called HotSpot. Oracle, as the steward of this project and the owners of the Java trademark and compliance test suite, direct and oversee much of the work that occurs at OpenJDK, though there are many contributors like IBM, Amazon, Azul, and many others.
OpenJDK produces a new "feature" release every 6 months. For each of these releases at OpenJDK, Oracle makes binaries available to run Java programs on a few platforms that are supported at the OpenJDK community for 6 months. When Java 24 was released in March 2025, for example, Oracle produced builds for the Java 24 GA as well as later updates in that release for 24.0.1 and 24.0.2 (released in April and July 2025, respectively). Once a new release appears (for example, Java 25 was released in September 2025), however, no more binaries are produced for the older release.
Every two years, a feature release is designated as a Long Term Support (LTS) release. The OpenJDK community members take on the responsibility to manage the content for LTS releases and issue release tags every quarter. Binaries for these releases are produced by the Eclipse Adoptium working group under the distribution name "Eclipse Temurin".
But these aren't the only Java binaries available for running your Java workloads.
Vendors produce their own Java distributions from OpenJDK
Many different vendors also build some or all of the JDK source code from OpenJDK to produce their own Java distributions. Some vendors produce a binary for their own software products to bundle or for their own customer base to use so that the vendor can provide reliable service and include critical fixes whenever they want to address production issues that may come up between new releases.
Many vendors also offer much longer than 6 months availability for Long Term Supported (LTS) releases. In principle, any vendor can choose to make any Java version available for an extended period of time. Most vendors, however, only provide longer term support for some or all of the so-called LTS releases: Java 8, Java 11, Java 17, Java 21, and now Java 25. Some vendors also make older Java versions like Java 6 or Java 7 available, but most focus on Java 8 and forward.
Note that "support" is an overloaded term when it comes to Java distributions and vendors. In some cases, "support" means that security and bug fix update releases will be provided on the usual quarterly cadence established by the OpenJDK project. In other cases, "support" means providing help with usage, diagnosing problems that may require, in extreme cases, fixes to be made to the Java distribution. Not all distributions and vendors can provide this "hot fix" level of support. In virtually all cases, this kind of support, if available, is via a commercial offering with service level agreements.
Some vendors also introduce specific changes into their Java distributions to tune for their specific products, or for their specific platforms. Some vendors invest more substantially to implement new features or capabilities that aren't available in OpenJDK or that aren't available in an older version of OpenJDK. Some of these changes may be made in the JCL code, but usually in such a way that existing APIs are not changed (though in some cases new APIs may be introduced).
Some vendors choose to invest more heavily to differentiate their Java distribution. For example, while most vendors use the (possibly modified) HotSpot JVM implementation from OpenJDK, there is another open source JVM implementation called Eclipse OpenJ9 that can be used with the JCL from OpenJDK to run Java applications. Eclipse OpenJ9 provides different performance characteristics and typically consumes less memory as well as offering capabilities (like JIT code caching and remote JIT compilation) that aren't available in Hotspot. Currently, the only Java distribution that includes the Eclipse OpenJ9 JVM is the IBM Semeru Runtimes distribution.
How to choose a Java distribition
Choosing a Java distribution or a Java vendor is an individualized consideration: there is no single "best" decision that works for everyone. Let's look at some of the points to consider in making such a choice. The key inputs to this process characterize what it is that you require from a Java distribution. Some of these inputs may require some research or inventory assessment on your part:
- For which of your workloads do you need to provide a Java distribution?
- Which Java versions do you need and for how long?
- On which hardware/operating system/cloud platforms will your Java applications run?
- Do you have special performance or cost expectations?
- Do you care about open source versus proprietary JDK distributions?
- Do you expect to get hot fixes for production problems in mission critical workloads and where do those workloads run?
You may find, when you create an inventory of your full Java usage, that you have a number of 3rd party applications or services that bundle their own Java distribution. You may not need to worry about these uses of Java unless it is your goal to unify on a single (or small number of) Java distributions. Not all 3rd party applications and services will support you if you replace the Java distribution they have tested with, so if you want to consider that option it's best to have an up front conversation with the application's provider about any implications (support or license) if you were to change the Java distribution. Most Java vendors should be amenable to being included in that discussion, if there is a specific vendor you want to be supported.
Many vendors specialize on a particular platform or set of platforms and may have Java version limitations. For example, the Red Hat Build of OpenJDK is primarily available on (and optimized for) Red Hat Enterprise Linux platforms with Java version support that varies depending on the version of RHEL (8, 9, 10) you use. The Amazon Corretto distribution is primarily designed to run on AWS (Linux X86 and ARM64) though developer versions of Corretto are also available for Windows and MacOS desktops.
Be careful of some myths that persist in this area. If a vendor produces JDK binaries for a particular platform, it probably runs very well there. For example, IBM Semeru Runtimes has sometimes been portrayed as being primarily built for the IBM POWER and IBM Z (mainframe) platforms so, the story goes, if you're not using those platforms you shouldn't bother considering it. In fact, a large number of IBM software products are built and ship on the X86 platform, so this Java distribution runs very well there (as well as being the premium Java implementation on the POWER and Z platforms).
If you have broad platform requirements, that may rule out some distributions that simply aren't available everywhere you need to run Java. You may also have business continuity requirements to be able to run your Java services on multiple clouds.
While there are distributions customized for each cloud, you should consider the complexity of having different Java distributions tuned for different clouds or whether using a less cloud specialized vendor distribution may simplify, reduce cost, or result in more consistent operational or support experience across your full environment.
Running in the cloud can be expensive if you aren't using resources efficiently, which may lead you to consider Java distributions designed to reduce resource usage. For example, the IBM Semeru Runtimes distribution is well known for running workloads in roughly half the memory and, when properly configured, starting in half the time and ramping performance up to steady state more quickly, even when running in very small containers. You may be able to achieve a more cost effective solution by deploying services with two or more smaller instances rather than one larger one in a cloud. Some vendors also offer additional features targeted at improving performance in the cloud, like remote JIT servers often called "Cloud Compilers" (IBM Semeru Runtimes, Azul Platform Prime).
Sometimes these features are commercial features, but not all vendors charge for these features. Also, beware of reading too much into benchmark performance results especially in the early stages of your evaluation, since almost nobody runs actual benchmarks in production and the details of how the benchmarks were run can matter significantly but are rarely presented in sufficient detail alongside the results. For example, you may read "better by X%" but do you really understand what was measured, how it was measured, and what other metrics may have been impacted and by how much to achieve that value for X?
Most production workloads and environments have far more complicated requirements than most performance benchmarks consider and they vary a lot. Your final decision should involve conducting your own runs on workloads that matter to you or to your business, simulating the actual conditions of your workloads as closely as possible.
You may also need to consider the license under which the Java distribution is made available. Most Java distributions, because they derive from OpenJDK, have an open source license (GPLv2 plus the Classpath Exception). But there are a few distributions, for example OracleJDK or Azul's Platform Prime or IBM Semeru Runtimes Certified Edition that come with different (in some but not all cases, commercial) licenses. Several versions of OracleJDK, for example, are only available under a commercial license for production use, whereas IBM Semeru Runtimes Certified Edition has a proprietary IBM license but is still made available publicly for download at no cost and includes all the same features as the Semeru Runtimes Open Edition. Make sure you understand the license under which you acquire a Java distribution and if there are any important future dates where the licensing terms may change if you continue to use it past those dates.
An explicit statement of Java certification may be important to some users. Most Java distributions have been tested with Oracle's proprietary TCK tests to be able to say they have passed those tests. The IBM Semeru Runtime Open Edition distribution, however, has not been tested with the TCK so it cannot be said to have passed those tests (which is not to say it could not pass those tests if tested). If you are concerned about Java certification, you could look at other Java distributions or consider using the IBM Semeru Runtime Certified Edition which has feature parity and 100% functional compatibility with the IBM Semeru Runtime Open Edition.
If you are looking to purchase commercial support for the Java distribution you choose, you should consider what kind of support you need. Not all Java vendors and distributions will provide hot fix (an immediate fix outside of a regularly scheduled release) support for production issues, so you will want to pay careful attention to the "fine print". For example, the popular Eclipse Temurin Java distribution is produced and made available for free by the Eclipse Adoptium project on a wide variety of platforms for all the active LTS Java releases.
Several Java vendors, including Azul, IBM, Red Hat, and others, have commercial support offerings that can support your use of Eclipse Temurin, but none of these vendors can offer hot fix support because the community that builds Eclipse Temurin doesn't offer hot fix support. These offerings can promise workarounds for any bugs you encounter, which are probably good enough in most cases, but only you can decide if that's good enough for your mission critical workloads.
Only vendors that produce their own binary Java distribution (which represent most of the other options) can provide hot fix support. But just because they can doesn't mean they do and the details in the terms may be very different from one vendor to another. Make sure you understand what "support" really means before you commit to a commercial support vendor.
Finally, you should consider the vendor and their experience and investment in Java to make sure they can meet your needs as they are now and as your workloads grow. Vendors like Oracle and IBM have been heavily invested in the Java ecosystem running teams with decades of experience building JVMs supporting a wide variety of Java workloads from tiny microservices to massive monoliths that support the operations of the global economy. For many businesses, that heavy enterprise-caliber focus and independent investment into Java instills comfort and offers protection for their mission critical workloads, but it may not be right for everyone, particularly if you're in more niche areas interfacing with specialized devices or operating in unique industries. Other vendors, like Azul or Bellsoft, are entirely focused on monetizing Java support as a business, which may or may not be the right fit for you. Then there are vendors whose investment is primarily to support the use of Java in specific environments like clouds or platforms. These vendors may be specialized to handle support issues in those environments but possibly not as effective or willing to handle issues in all environments where you will be running your Java workloads.
Not any one distribution is right for everyone, just as there are no distributions that are bad for everyone. Think about what's important for you and then do your research to pick 2-3 distributions to do more comprehensive testing and, if needed, discuss your needs with those vendors directly. No article, not even this one, can tell you the right answer.
Wrapping up
The Java language has come a long way in its 30 year history. While its popularity has always remained constant, the deployment of Java has seen major changes occur over the past decade. With the widespread adoption of Java, a number of software vendors now distribute their own OpenJDK Java SE distributions.
In this article, we discussed a number of reasons why there are so many different distributions as well as some of the differences across those distributions. We also examined some of the topics you may want to consider to help you decide which Java distributions best meet your own needs.
More information about IBM Semeru Runtimes
IBM Semeru Runtimes is the only Java distribution that combines the standard OpenJDK class libraries with the Eclipse OpenJ9 Java Virtual Machine to run Java workloads in roughly half the memory and, when properly configured to cache classes and JIT compiled code, start in roughly half the time of other JDK distributions, whether you're running with Java 8, Java 11, Java 17, Java 21, or Java 25. IBM Semeru Runtimes is a drop-in replacement for any other Java distribution that includes the Semeru Cloud Compiler (remote JIT compilation service) and support for checkpointing and restoring Java processes in hundreds of milliseconds. It also bundles cryptography accelerated by OpenSSL, a cross platform FIPS 140-3 certified cryptography library with the OpenJCEPlusFIPS provider, and is the only Java distribution that bundles cross platform Post Quantum Cryptography support (ML-KEM and ML-DSA algorithms) in Java 17 and 21, in addition to Java 25.
IBM Semeru Runtimes come in 2 flavours: an Open Edition and a Certified Edition. Both editions are free to download and use in production. The only difference between the editions is the licensing and supported platforms.
Semeru Runtimes Open Edition:
- Open source license (GPLv2+CE)
- 100% functionally compatible with Semeru Runtimes Certified Edition
- Java versions: Java 8, 11, 17, 21, and 25
- Supported architectures: x64, x86, ppc64le, ppc64, s390x, aarch64
- Supported operating systems: Linux, Windows, macOS, AIX
- Download available from IBM
Semeru Runtimes Certified Edition:
- IBM license
- Java SE TCK certified.
- Java versions: Java 11, 17, 21, and 25
- Supported architectures: x64, ppc64le, ppc64, s390x, aarch64
- Supported operating systems: Linux, AIX, z/OS
- Download available from IBM and Adoptium - Marketplace
Commercial support for IBM Semeru Runtimes and Eclipse Temurin is available with IBM Runtimes for Business.