SapMachine is SAP's OpenJDK build with a support statement behind it

A downstream fork with a vendor behind it

SapMachine is a downstream fork of the OpenJDK project, aimed at providing a binary distribution of OpenJDK for SAP customers and partners. The word downstream does most of the work here. SapMachine does not invent a JVM, it takes the OpenJDK source tree and produces builds from it, and the README says so plainly: SAP is committed to the ongoing success of the Java platform and the OpenJDK project, maintaining SapMachine in an OpenJDK-upstream-first model. What SAP adds over a self-compiled OpenJDK is not a different runtime, it is the packaging, the release cadence and, most importantly, a support relationship with a named vendor. The homepage is sapmachine.io, and the README directs readers to the documentation pages there for installation instructions, frequently asked questions and, notably, the maintenance and support statement. For a team that has to answer the question of who patches this JDK in three years, that document is the actual product.

The upstream-first model and what it means for a fix

The synchronisation policy is stated in one sentence and it determines most of the operational behaviour. Since SapMachine tracks the OpenJDK, every SapMachine release contains all the fixes and changes of the corresponding OpenJDK release on which it is based. That is a strong guarantee, and it is also the constraint. A SapMachine build cannot contain a fix that upstream has not shipped, and a fix that upstream ships reaches you on SapMachine's own release schedule rather than immediately. The issue handling reflects the same structure. General JVM and JDK bugs are managed in the OpenJDK Bug System, and a SapMachine issue can be opened with reference to an existing OpenJDK bug for requesting resolution or backporting the fix to a specific SapMachine version. If a general JVM or JDK bug is found in SapMachine without editor access to the OpenJDK Bug System, an issue can be opened in the SapMachine repository and a corresponding OpenJDK bug will be filed. In practice that means your bug reports for a JVM defect end up upstream, and what comes back to you is a SapMachine release carrying the upstream fix.

Contributions are redirected upstream on purpose

This is the part of the project most likely to surprise an open source contributor, and it is stated without ambiguity. External contributions to this project are currently not accepted. For code improvements or bug fixes, contributions should be directed to the upstream OpenJDK project. The reason given is structural rather than a policy whim: repositories are regularly synced with OpenJDK, ensuring that upstream improvements are realized in SapMachine. That is a coherent argument. In a downstream binary distribution, a local patch creates a merge burden on every subsequent sync, and a fork that accumulates its own commits is exactly the thing the upstream-first model is designed to prevent. The practical effect for a team is that they cannot fix a SapMachine-specific defect by patching the repository. They file an issue, and the fix has to come from upstream or be delivered as a SapMachine build change. The repository layout reflects the upstream heritage directly, with the standard OpenJDK build structure including make/, src/, test/, bin/, configure and doc/ directories, plus a .jcheck directory for the jcheck style tooling.

The release line, and what the version numbers mean

The recent releases show a project shipping multiple version lines in parallel, which is what a support commitment looks like in practice. The listed releases include sapmachine-28+19 dated 2026-10-16, sapmachine-28+18 dated 2026-10-07, and sapmachine-21.0.13+8 dated 2026-10-05. The naming convention itself carries information. The 28 line and the 21.0 line are being updated at the same time, within about two weeks of each other, and the build suffix increments on each patch, so 28+18 followed by 28+19 is the monthly or similar patch cadence on the newer feature line, while 21.0.13+8 is a maintenance update on an older line that customers have not finished migrating from. The last push to the repository was on 2026-10-20, and the repository is not archived. If you are evaluating this for a fleet, the two things to look at are which feature line you sit on and how long each line is intended to receive updates, and both live in the maintenance and support statement rather than in the repository.

Where to get the builds, and what the repository is for

The repository is not where you install from, and the README is explicit that installation instructions live elsewhere. Builds are distributed through the project's own site, and the release badge in the README points at sapmachine.io for downloads, while a Docker pulls badge points at the sapmachine image on Docker Hub, which is a useful signal that container images are part of the distribution story. The site carries the SAP OpenJDK Engagement page, which documents SAP's engagement in OpenJDK, and the documentation pages carry the installation instructions, the frequently asked questions and the maintenance and support statement. So the division of labour is clean. sapmachine.io is where you get a JDK, GitHub is where you read the README, file SapMachine-specific issues and follow the source, and the OpenJDK project is where JVM and JDK bugs live. The Docker Hub image is worth a second look for anyone running Java in containers, since it means the same supported build is available in the form most deployments need.

Licensing, and the difference between the project and the build

The licensing picture has two layers and the distinction matters for anyone who reads a licence header. The project is run under the same licensing terms as the upstream OpenJDK project, and the README points at the LICENSE file in the top-level directory for additional information. The Makefile header in the repository shows the detail, and it is the standard OpenJDK arrangement rather than something SAP invented. The code is free software under the GNU General Public License version 2 only, published by the Free Software Foundation, and Oracle designates that particular file as subject to the Classpath exception as provided by Oracle in the LICENSE file that accompanied the code. The effect of the Classpath exception is that linking your own code with the library does not force that code under the GPL. Alongside that, the repository carries an ASSEMBLY_EXCEPTION file, an ADDITIONAL_LICENSE_INFO file and a SECURITY.md, the last of which is where a distribution of this kind normally points for coordinated vulnerability disclosure. Read the LICENSE file rather than relying on the summary above, since the terms of the exception are what matter for your own use.

Where SapMachine is the wrong choice

There are clear cases where this distribution is the wrong answer. If you have no SAP footprint and no need for a vendor support statement, then a general OpenJDK build or a long term support distribution from another vendor covers the same ground, and the point of SapMachine, which is a support relationship, does not apply. If your organisation's policy is to track the OpenJDK feature line exactly, the extra layer of a downstream release schedule means you are not tracking upstream directly, and the fixes arrive on SapMachine's timing instead of upstream's. And if you intend to carry patches of your own, the project will not take them, so the practical alternative is to maintain your own downstream of OpenJDK, which means accepting the sync burden the upstream-first model was designed to avoid. For deployments inside SAP systems the trade is usually worth it, because a named support statement and a defined maintenance window for a JDK is harder to obtain elsewhere than the build itself.

Editorial conclusion

Adopt SapMachine if your organisation runs Java inside SAP systems and wants a JDK built from OpenJDK that comes with a published maintenance and support statement instead of a self-compiled build. Do not adopt it to contribute code, because external contributions are currently not accepted and are directed to upstream OpenJDK, and do not adopt it as a fork you intend to diverge from, because the model is upstream-first and repositories are regularly synced with OpenJDK. Verify two things before you standardise on it: that the version line you need has a published support statement covering the period you intend to run, and that the fix level you need has landed upstream, since a SapMachine release contains all the fixes and changes of the corresponding OpenJDK release it is based on. The practical first step is to read the documentation pages at sapmachine.io/docs, where the installation instructions, the frequently asked questions and the maintenance and support statement are published.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. SAP/SapMachine on GitHub