OpenJDK Vendors, in depth: what differs between Temurin, Corretto, Zulu, Oracle JDK and the rest, licensing, support horizons, and how to choose and switch

Where a vendor build comes from

New features land in the OpenJDK mainline repository and ship every six months as a feature release. When a release ships, maintenance continues in an update project (for example jdk21u and jdk25u), where fixes are backported and released quarterly, typically on the third Tuesday of January, April, July and October; the October 2026 update is due on the third Tuesday, 20 October. Vendors take those update tags, apply their own build configuration and sometimes extra patches, test, and publish binaries. The release train itself is covered in Java LTS releases.

Long-term support is a vendor promise, not an OpenJDK property. After the first months of an update project, maintenance is led by vendor engineers, and each vendor decides how long it will keep publishing builds for a release. That is why two vendors can support the same LTS version for different lengths of time.

What genuinely differs

Two more points. First, the VM is not always HotSpot: IBM Semeru Runtimes use the Eclipse OpenJ9 VM, which has different tuning flags and memory behaviour, so treat it as a different runtime, not just a different vendor. Second, GraalVM distributions add an alternative JIT and native-image tooling on top of a JDK; see GraalVM architecture. Everything else on this page is about HotSpot-based builds.

Optional components are where surprises hide. Shenandoah is built into most OpenJDK distributions but Oracle's JDK builds have not included it, so a flag that works on Temurin can stop the JVM from starting on Oracle JDK. JavaFX is separate from the JDK, but some vendors ship bundles that include it; Amazon ended JavaFX support in Corretto 8 on 31 March 2026. CRaC support for fast startup ships in specific builds from vendors such as Azul and BellSoft rather than in every distribution; see CRaC.

Licensing, and why October 2026 matters

Most vendor builds are free to use in production under the OpenJDK licence, GPLv2 with the Classpath Exception, which does not affect your application's licence. Oracle is different in two ways. Oracle's OpenJDK builds on jdk.java.net are GPL but are updated only for the six months of each feature release, so they are not an LTS option. Oracle JDK, the commercial-branded build, ships under the Oracle No-Fee Terms and Conditions (NFTC) for a limited window and then under the Java SE OTN licence, which requires a paid subscription for most production use.

For JDK 21, Oracle states that updates through the September 2026 release are under NFTC and updates from the October 2026 Critical Patch Update are planned under OTN. If you run Oracle JDK 21 and simply apply the next quarterly patch, you move onto licence terms that may require a subscription. JDK 25 updates are under NFTC until September 2028. The practical options are: buy the subscription, move to JDK 25 and plan the next hop before 2028, or switch to another vendor's 21 build, which for most applications is the cheapest and least disruptive.

Support horizons you can plan against

Each vendor publishes its own calendar. These are the dates listed on 2026-10-03 for the two most common free builds; check the vendor pages again before planning, as they are extended from time to time.

Azul, Microsoft, Red Hat, BellSoft and SAP publish their own roadmaps, and paid tiers can extend coverage. The pattern to notice is that horizons differ by years for the same version, so the vendor choice for an old version like 11 or 17 is mostly a choice of how long you can postpone the upgrade. Non-LTS releases get roughly six months from everyone; run them only if you will upgrade every six months.

A horizon only helps if you actually take the updates. Treat each quarterly release as a routine change: subscribe to your vendor's release announcements, let a scheduled job rebuild base images when the new tag appears, run the test suite and a canary, and roll the fleet within a week or two. Security fixes in a quarterly update are public the day it ships, so a runtime that lags by months is exposed whatever its vendor promises. Measure lag as a number, such as days since the newest available update, rather than as a feeling.

Know what you run

Fleets drift. Base images, developer laptops, build agents and vendor appliances each bring their own JDK, and the java -version banner alone does not always name the vendor clearly. Two sources are reliable. The system properties report the vendor and full runtime version, and every modern JDK image carries a release file whose IMPLEMENTOR and JAVA_VERSION_DATE fields tell you who built it and how old its patch level is.

# What is this runtime, really?
java -XshowSettings:properties -version 2>&1 | grep -E 'java\.(vendor|vm\.vendor|runtime\.version|vm\.name) '
cat "$JAVA_HOME/release"            # IMPLEMENTOR, IMPLEMENTOR_VERSION, JAVA_VERSION, JAVA_VERSION_DATE

# Does this build include an optional feature you rely on?
java -XX:+UseShenandoahGC -version  # fails at startup if the collector was not built in
java --list-modules | grep javafx   # only "full" or FX-bundled builds include JavaFX

# Pin the vendor in builds as well as at runtime
#   Gradle toolchain:   vendor = JvmVendorSpec.ADOPTIUM   (or AMAZON, AZUL, ...)
#   actions/setup-java: distribution: 'temurin'           (or 'corretto', 'zulu', ...)
#   Dockerfile:         FROM eclipse-temurin:21-jre@sha256:<digest>

To audit many hosts or images, read the release files rather than starting a JVM per install. The script below flags runtimes more than about one quarter behind and every Oracle-built runtime for a licence check. Oracle's GPL builds also report Oracle Corporation, which is why it flags rather than concludes.

#!/usr/bin/env python3
"""Inventory JDKs: vendor, version and patch age from each $JAVA_HOME/release file."""
import datetime, pathlib, sys

def read_release(java_home):
    info = {}
    for line in (pathlib.Path(java_home) / "release").read_text().splitlines():
        if "=" in line:
            key, value = line.split("=", 1)
            info[key] = value.strip().strip('"')
    return info

def assess(java_home, today=None):
    today = today or datetime.date.today()
    r = read_release(java_home)
    vendor = r.get("IMPLEMENTOR", "unknown")
    version = r.get("JAVA_VERSION", "?")
    built = r.get("JAVA_VERSION_DATE")
    age = (today - datetime.date.fromisoformat(built)).days if built else None
    flags = []
    if age is None or age > 100:            # older than one quarterly update plus slack
        flags.append("behind on quarterly updates")
    if vendor == "Oracle Corporation":
        flags.append("Oracle build: check licence (NFTC, OTN or jdk.java.net GPL)")
    return f"{java_home}: {vendor} {version} built {built} -> {', '.join(flags) or 'ok'}"

for home in sys.argv[1:]:
    print(assess(home))

Worked example: leaving Oracle JDK 21 before the October update

A team runs forty services on Oracle JDK 21, last patched with the July 2026 update, in containers and wants to keep free updates without changing Java version. They choose Temurin 21 because their base images already use Ubuntu and the official eclipse-temurin images fit their build. The plan has five steps.

1. Inventory: run the release-file audit over every image and host; find the few that use Oracle-only paths or flags.
2. Swap the base image in one low-risk service, pinned by digest, keeping the same 21 update level so only the vendor changes.
3. Diff behaviour: compare startup flags, the default trust store (vendors maintain their own CA certificate sets, so test outbound TLS), fonts for any server-side rendering, and time-zone data.
4. Compare performance with the same heap and GC settings over a full load test; expect differences within noise, and investigate anything larger.
5. Roll out by service, then make the vendor explicit in Gradle or Maven toolchains and CI so it cannot drift back.

The work is mostly verification, not code change. The real risk is the long tail: a forgotten build agent or vendor appliance still pulling Oracle JDK updates. Container specifics, including memory sizing, are in Java containerization.

How to choose

Above all, choose one per estate. A single vendor with a known calendar is worth more than the best vendor chosen differently by every team.

Failure modes

• Accidental licence change: an automated update moves Oracle JDK onto OTN terms.
• Silent end of updates: a vendor's horizon passes and images keep building on an unpatched JDK.
• Missing feature: a GC, JavaFX or CRaC flag fails on a different build.
• Trust store drift: outbound TLS breaks because CA sets differ between vendors.
• Floating tags: latest or major-only image tags change vendor patch level without review.
• Mixed fleets: bug reports cannot be reproduced because laptops, CI and production run different builds.

What to do next

1. Inventory every JDK in images, hosts and CI, recording vendor, version and build date.
2. List every Oracle JDK install and decide, before the October 2026 update, whether to subscribe, move to JDK 25 or switch vendor.
3. Choose one default vendor and record its support dates for each Java version you run.
4. Pin images by digest and toolchains by vendor so builds cannot drift.
5. Add a CI check that fails when a runtime is more than one quarterly update behind.
6. Test GC flags, optional modules and outbound TLS whenever you change vendor.
7. Trim the runtime you ship with jlink once the vendor is fixed.