Eclipse OpenJ9 is a JVM you assemble rather than download

Independent means built from the spec, not forked from HotSpot

The README is unusually precise about what independent implementation means here: OpenJ9 was built using the Java Virtual Machine specification without using any code from any other Java Virtual Machine. That is the whole positioning, and it is a legal and architectural claim at the same time. You are not choosing between two forks of the same lineage, you are choosing between independent implementations of one specification.

The pedigree explains why it exists at all. The original source contribution came from the IBM J9 JVM, which the README says has been used in production by thousands of Java applications for the last two decades. In September 2017 IBM completed open sourcing it as Eclipse OpenJ9 at the Eclipse Foundation, with significant parts of J9 also open at the Eclipse OMR project.

What you get is not a whole JDK. The OpenJ9 JVM combines with the Java Class libraries from OpenJDK to create a complete JDK tuned for footprint, performance and reliability that is well suited for cloud deployments. OpenJ9 is the virtual machine; OpenJDK supplies the libraries; you assemble the pair.

The description line on the repository gives the three optimisation targets in order: small footprint, fast start-up and high throughput. That ordering is the project pitch compressed into a sentence, and it is a different ordering from the one most JVMs lead with.

The licensing is what lets OpenJDK use it

The README spends a paragraph on licensing because the choice is load-bearing. OpenJ9 has a permissive licence, Apache License 2.0 or Eclipse Public License 2.0, with a secondary compatibility licence for the OpenJDK project's GPLv2 licence. The README states the purpose plainly: it is designed to allow OpenJDK to be built with the OpenJ9 JVM.

That secondary compatibility clause is the piece that makes the whole arrangement possible. OpenJDK is GPLv2 with a classpath exception. Without a licence that is compatible with that, an Apache or EPL JVM could not be linked into the class libraries. The `LICENSE` file in the tree carries the full terms, and `NOTICES.md` sits next to it.

The header comment at the top of the README spells out the four-way SPDX expression: EPL-2.0 OR Apache-2.0 OR GPL-2.0-only WITH Classpath-exception-2.0 OR GPL-2.0-only WITH OpenJDK-assembly-exception-1.0. Both the Classpath exception and the OpenJDK assembly exception have their URLs in the comment, which tells you both were considered load-bearing enough to cite.

The repository language on GitHub is Java, but `Java` there is a fraction of the project. Most of what people mean by writing a JVM is C, C++ and assembly, and the tree reflects that with `runtime/`, `jcl/` and `buildenv/` at the top level rather than a `src/` directory.

Five repositories and what each one is for

The README has a short section listing the repositories that make up the project, and the parenthetical in the OMR entry is the interesting part. The `openj9` repository is the main code base. `openj9-omr` is described as an Eclipse OMR clone to stage temporary OMR changes, and the README adds, in parentheses, that there are none so far.

That single comment is worth pausing on. The staging repository exists so that a change needing to land in OMR can be pushed to a location the OpenJ9 build can consume immediately, rather than waiting for the OMR project to review and merge it. The fact that it has stayed empty says more about the state of the upstream relationship than any status report would.

The other three are `openj9-systemtest` for OpenJ9-specific system tests, `openj9-website-publish` for the website, and one further repository entry that the copy available here cuts off where the listing ends. In other words the README's own repository list arrives incomplete, which is a fair illustration of how much of this project's structure lives in linked documents rather than in any single file.

Within the main repository the top level is twenty-five entries: `CMakeLists.txt`, `CODEOWNERS`, `CONTRIBUTING.md`, `SECURITY.md`, `artwork/`, `buildenv/`, `cdsadapter/`, `debugtools/`, `doc/`, `jcl/`, `runtime/`, `sourcetools/` and `test/`. `doc/` is where the build instructions and per-release known-issue notes live, and it is the directory you will spend the most time in.

A release every four weeks against a shifting set of JDK builds

The release cadence is the clearest signal of how this project is run. Three releases are recorded: 0.60.0 on 2026-07-30, 0.61.0 on 2026-08-27 and 0.62.0 on 2026-09-15. That is roughly every four weeks, and it is the cadence of a project shipping against an upstream that moves underneath it.

The `Works with:` line in each release body is the part to watch. Version 0.61.0 lists jdk8u504, 11.0.32.1, 17.0.20.1, 21.0.12.1, 25.0.4.1 and 26.0.2.1. Version 0.60.0 lists jdk8u502, 11.0.32, 17.0.20, 21.0.12, 25.0.4 and 26.0.2. So OpenJ9 supports JDK 8 through the current releases, it tracks the 25 and 26 feature releases, and the patch numbers move with every upstream security update. If you pin an OpenJ9 build you are pinning a specific combination of VM and JDK.

The security section is a useful signal of process. Version 0.60.0 lists three resolved vulnerabilities, CVE-2026-16243, CVE-2026-16439 and CVE-2026-16441. Version 0.61.0 lists one, CVE-2026-16440. Version 0.62.0 says N/A. A project that resolves CVEs at its own release boundaries rather than only when upstream does is one with a working process behind it.

Each release body also pins exact commit SHAs for both repositories, which tells you a release is reproducible at the commit level: 0.62.0 records an OpenJ9 SHA and an OMR SHA, with branch name v0.62.0-release. The full known-issue notes are not in the release body; they live at `doc/release-notes/0.62/0.62.md` in the repository.

JITServer is the feature that changes the deployment model

Every release body in this material carries the same pointer, which is unusual: a JITServer Helm Chart for easier deployment of JITServer technology in a Kubernetes or OpenShift cluster, hosted in the openj9-utils repository. A recurring line in every release means the feature is treated as an ongoing operational concern rather than a one-off.

The idea is that compilation, which is CPU-intensive and unpredictable in duration, moves off the application process into a service that applications connect to at start-up. For a fleet of short-lived containers this matters, because each container no longer has to warm its own JIT. For a long-running server it matters less, since the compilation cost amortises.

That the chart lives outside the main repository, in `openj9-utils`, is itself informative. The VM, the tests and the documentation live in `openj9`; the packaging that puts JITServer into a cluster lives somewhere a cluster operator will look.

There is also `debugtools/` at the top level of the main repository, which is where you would expect a debugger integration for a VM that people actually run in production, and `cdsadapter/`, which relates to class data sharing, one of the mechanisms most associated with fast start-up.

The distribution constraint that shapes everything else

The most consequential paragraph in the README is the one about what the project cannot do. Eclipse Foundation projects are not permitted to distribute, market or promote JDK binaries unless they have passed a Java SE Technology Compatibility Kit licensed from Oracle, to which the OpenJ9 project does not currently have access. The README links the Eclipse Adoptium Project Charter as the relevant governance document.

So the repository is a source code project that can be built alongside Java class libraries, and the build instructions are the deliverable rather than a download link. The README links separate build instructions for JDK8, JDK11 and more, each a document in `doc/build-instructions/`.

This explains the relationship with Adoptium: the binaries you can install for OpenJ9 come from the Adoptium project rather than from Eclipse OpenJ9 directly. It also explains the `buildenv/` directory, which is the scripted environment for assembling a build rather than a directory of application source.

The contribution path is also spelled out with unusual bluntness. Since this is an Eclipse Foundation project, each contributor needs to sign an Eclipse Contributor Agreement, and the README points at `CONTRIBUTING.md` and the Eclipse Code of Conduct. For anyone not ready to sign, it suggests joining the weekly updates in the #planning channel on the project's Slack workspace, where they do lightning talks on features and functions of the VM. The repository has 3547 stars, 795 forks and 3261 open issues, and the last recorded push is 2026-09-23.

Editorial conclusion

OpenJ9 is the rare case where the interesting question is not whether the code is good but whether you are allowed to ship the result. The Eclipse Foundation cannot distribute or promote JDK binaries because it does not hold a Java SE Technology Compatibility Kit licence from Oracle, which is why the repository is a source project you build yourself and why the Adoptium project exists downstream to do the shipping. If your interest is a smaller runtime for cloud workloads, read the build instructions for the JDK version you care about, then measure against your own workload. If your interest is the compiler, the garbage collector or JITServer, the repository tree is well organised enough to read directly.

Frequently asked questions

Official sources

1. eclipse-openj9/openj9 on GitHub
2. Issues
3. README
4. Releases