Choosing a JDK in 2026 — an honest guide

The choice matters less than it feels

All major OpenJDK distributions — Temurin, Corretto, Zulu, Liberica, Microsoft Build, Red Hat OpenJDK, SapMachine, Eliya — build from the same upstream source and pass the same Technology Compatibility Kit. Swapping between them is an operational task, not an application-code task. If your app runs on one, it runs on all of them.

The real differences are:

• How long each vendor promises to patch each LTS
• What licence they ship under (almost all are GPLv2+CE; Oracle JDK is the exception)
• Which platforms and architectures they publish binaries for
• Whether commercial support is available, and from whom
• Whether the vendor bundles extras (JavaFX, native image kit, crypto provider, tuned defaults)
• How aligned the vendor is with your existing infrastructure (AWS / Azure / RHEL / SAP / etc.)

Tom Gregory summed it up well: "don't spend too long deliberating over which JDK vendor to go with."

Decision dimensions

Which version? LTS 21 or LTS 25 in 2026

Stay on LTS. In 2026 that's JDK 21 LTS (released Sep 2023, most deployed in production) or JDK 25 LTS (released Sep 2025, current-latest). Non-LTS releases (JDK 22, 23, 24, 26) stop receiving security patches six months after release — never run them in production.

• New project, greenfield: pick JDK 25. Virtual threads are mature, structured concurrency is stable, pattern matching is complete, the FFM API is final.
• Existing project on JDK 21: stay on 21 until you need a 25 feature. Upgrading is cheap; urgency is low. JDK 21 is patched through at least September 2028 by most vendors.
• Legacy on JDK 8 or 11: plan a migration. Most vendors still patch these but you're on borrowed time. Temurin commits 8 through 2026; Corretto 8 through 2026; Zulu and Liberica offer commercial 8/11 support for longer.

Vendor-by-vendor assessment

Eclipse Temurin (Adoptium)

When to pick: default for almost everything. If you don't have a specific reason to pick otherwise, pick this.

• Backed by the Eclipse Foundation — the only foundation-governed (non-single-vendor) distribution.
• Members include IBM, Microsoft, Red Hat, Alibaba, Azul, Huawei — broad industry investment.
• SDKman's stamped default. whichjdk.com's primary recommendation.
• GPLv2+CE. TCK-verified. Regular quarterly CPUs aligned with upstream.
• LTS support: at least 4 years per LTS, with most LTS lines extending further via third-party collaboration.
• Main caveat: the project itself does not sell commercial support. Adoptium maintains a list of third-party support providers. If procurement requires a single vendor for binaries AND support, Temurin is not the answer.

Amazon Corretto

When to pick: anything running on AWS. Still a solid default everywhere else.

• AWS-maintained. Linux, Windows, macOS, Alpine, Amazon Linux 2 binaries.
• Bundled Corretto Crypto Provider optimised for AWS services.
• AWS Lambda SnapStart reduces Java cold-start latency up to 10×.
• Commercial assistance covered through AWS Support plans — no separate Corretto SKU.
• Main caveat: single-vendor dependency. If you exit AWS your JDK decision is inherited, not chosen.

Azul Zulu

When to pick: you want a Java-focused vendor with long LTS windows and a real commercial support option.

• Azul is a Java-specialist company — Java is the business, not a side project.
• 8-year LTS support (longer than most competitors). Commercial support for Java 6 and 7 available.
• Tiered commercial support: Standard (business hours) vs Premium (24×7×365).
• Also ships Azul Platform Prime — an alternative JVM with C4 pauseless GC, Falcon JIT, and cloud-native compilation. Different product; benchmark before committing.
• Extras: Zulu Mission Control, JVM Inventory / Discovery, OpenJFX builds, applet support.

BellSoft Liberica

When to pick: Spring Boot workloads (Paketo default), applications needing JavaFX bundled, container-heavy deployments, or when you want the widest platform matrix.

• Default JDK in Paketo Buildpacks — meaning every Spring Boot app built with spring-boot:build-image runs on Liberica out of the box.
• Recommended by VMware for the Spring Framework.
• Broadest platform matrix: Linux (x64, aarch64, aarch32, ppc64le, riscv), Alpine, Windows, macOS. Only major vendor covering 32-bit ARM and RISC-V.
• 8.5 years LTS support — longest among majors.
• Commercial support for Java 6/7 available.
• Product family: Liberica Standard, Liberica Full (with JavaFX + OpenWebStart), Liberica NIK (GraalVM Community-based native image kit), Alpaquita Linux (Alpine fork optimised for Java), Liberica Mission Control, Hardened Container Images (near-zero-CVE).

Oracle JDK

When to pick: you have a specific reason tied to Oracle support contracts. Otherwise, read the licence carefully before defaulting to it.

• Oracle JDK 17+ is distributed under the No-Fee Terms and Conditions (NFTC) — free for production, including commercial use.
• NFTC patch window is narrow: one year after the subsequent LTS release. Third-party vendors offer years longer.
• Java SE Universal Subscription for longer support and indemnification is priced per-employee (not per-JVM) — this has driven many enterprises to third-party distributions.
• Oracle JDK 8 and 11 require a paid subscription for production use.
• Bottom line: unless you're already paying Oracle for something, third-party distributions are the safer choice.

Oracle OpenJDK (jdk.java.net)

When to pick: don't, for production. Use it for exploring early-access builds and evaluating non-LTS features.

• Oracle only provides updates to each release for six months, even for LTS versions.
• Not a long-term-support distribution by any definition that matters in production.

Microsoft Build of OpenJDK

When to pick: running Java workloads on Azure.

• Free and open-source. Linux, Windows, macOS binaries.
• Quarterly updates for LTS, not JDK 8.
• Commercial support only for Azure customers with an active Azure support plan, and only for workloads on Azure services.
• Binaries may contain Microsoft fixes not yet integrated upstream — migration away from Microsoft Build may encounter minor behavioural differences.

Red Hat build of OpenJDK

When to pick: already standardised on Red Hat Enterprise Linux, OpenShift, or Red Hat Middleware.

• Binaries only on Windows and RHEL.
• OpenJDK entitlement is included in the RHEL subscription — if RHEL retires before the JDK, JDK support ends with it.
• As of July 2025, Red Hat's JDK 8 builds are no longer TCK verified (per their own published policy). Other versions remain TCK-verified.

SAP SapMachine

When to pick: SAP ecosystem. SapMachine is the default runtime for many SAP applications and SAP Business Technology Platform.

• Free, TCK-verified. Linux, Windows, macOS. All LTS except Java 8.
• 4+ years LTS support.
• Commercial support tied to SAP customer contracts in the context of SAP-supported products.
• Patches that don't make it upstream may still land in SapMachine — migration away could hit divergence.

IBM Semeru Runtimes

When to pick: you specifically want OpenJ9 (lower memory footprint than HotSpot) or you're on IBM z / Power / AIX / z/OS.

• Built around OpenJ9, an alternative JVM to HotSpot. This is the defining choice — not "vanilla OpenJDK."
• Open edition (GPLv2+CE) and certified edition (IBM licence).
• IBM Runtimes for Business is the commercial support offering.
• Excellent enterprise platform coverage.

Regional / specialist builds

• Alibaba Dragonwell — Alibaba Cloud workloads; strong in China-region deployments; includes performance patches for large-scale Alibaba use cases.
• Tencent Kona — Tencent Cloud workloads; similar regional profile.
• Huawei BiSheng — Huawei-maintained, strong aarch64 and Kunpeng server support.

GraalVM (Oracle) & GraalVM Community

When to pick: you need Ahead-of-Time native compilation (small binary, fast cold start), or polyglot interop.

• GraalVM is a different category of product — it bundles a JDK with a native-image compiler and polyglot runtime.
• Oracle GraalVM ships under a non-free licence for some features; GraalVM Community is Apache/GPL.
• For native image without GraalVM itself, consider BellSoft Liberica NIK (GraalVM CE-based, integrates with Liberica JDK) or Red Hat Mandrel (used by Quarkus).

JetBrains Runtime (JBR)

When to pick: running IntelliJ IDEA, Android Studio, or other JetBrains IDEs. Not a general-purpose server JDK.

• Fork of OpenJDK with fixes specific to running the IntelliJ platform.
• Google explicitly recommends using JBR to run Android Studio (don't set STUDIO_JDK to override it).
• Can technically run other Java applications, but the target use case is the IDE itself.

Eliya JDK

When to pick: a narrow, honest niche. You should choose Eliya only if one or more of these apply:

• You're running low-latency request-processing workloads (telecom API gateways, BSS components, request-heavy services) where the bundled -XX:+UseEliyaDefaults profile (G1GC with 50 ms pause target, string deduplication, compressed oops, tiered compilation) saves you the work of curating equivalent flags yourself.
• You want always-on TLS/security hardening in java.security without having to manage it separately.
• You're building with Dial and want the recommended (but not required) runtime.
• You want to run an OpenJDK on FreeBSD — Eliya ships a Research Preview (community-supported, no CVE SLA); no other major vendor ships FreeBSD binaries at all.

You should not pick Eliya if:

• You need Windows or macOS binaries — Eliya is Linux-first.
• You need commercial support with an SLA — Eliya is community-distributed today; commercial support is a Phase 2 consideration.
• You need paid indemnification — use Azul, BellSoft, or Oracle.
• You need JavaFX bundled — use Liberica Full.
• You need a JDK for running generic Java applications where Eliya's telecom optimisations are irrelevant — Temurin, Corretto, Zulu, or Liberica will all do the job and have larger operational track records.

Honest summary: Eliya is a new (2026) distribution from a solo-founder company. It builds from upstream OpenJDK 25u with one flag-gated source patch and hardened configuration overlays. The telecom tuning is genuinely useful for the workloads it's tuned for — the credibility is not yet earned for general workloads. If you're in the niche, we'd love to have you. If not, one of the vendors above is a better fit.

Platform and framework defaults

Switching is cheap — benchmark, don't debate

Every major distribution is installable side-by-side via SDKman in seconds:

Run your workload under each with production-representative load. Measure tail latency, throughput, allocation rate, and GC pause distribution. Pick the one that wins on your actual workload, not the one that sounds best on the vendor's marketing page.

In our own internal benchmarking for telecom API gateway workloads, the choice between major vendors on the same underlying HotSpot usually matters less than 5% — within noise for many deployments. The tuning flags matter far more than the vendor brand.

References

• whichjdk.com — the canonical independent JDK recommendation site
• sdkman.io/jdks — full list of distributions on SDKman with suffix references
• Tom Gregory: Which JDK version and vendor
• Eclipse Adoptium (Temurin)
• Amazon Corretto
• Azul Zulu (Platform Core)
• BellSoft Liberica JDK
• Paketo Buildpacks — Java howto
• Eliya JDK (Asymm Systems)