All four builds are free under GPLv2 with Classpath Exception, so the decision is never about license cost. It is about support ownership, LTS end dates, and platform coverage, and this guide gives you the criteria to standardize on the right one before you migrate 10,000 JVMs.
All four builds are free under GPLv2 with Classpath Exception, so the decision is never about license cost. It is about support ownership, LTS end dates, and platform coverage, and this guide gives you the criteria to standardize on the right one before you migrate 10,000 JVMs.
If you are running an Oracle Java exit, the distribution question arrives fast and gets answered badly. Teams pick whatever their cloud provider ships, or whatever a developer already had on a laptop, and six months later you have three distributions in production, none of them patched on schedule, and no single vendor accountable for a security escalation. In 25 years negotiating with this vendor and its ecosystem, the recurring pattern is the same: buyers treat the OpenJDK build as a commodity download and then discover the differences the hard way, during an incident or an audit.
The good news is that the license is not the variable. Amazon Corretto, Eclipse Temurin, Azul Zulu (the free Community builds), and the Microsoft Build of OpenJDK are all distributed under GPLv2 with the Classpath Exception. That means free commercial production use, no per-JVM fee, no audit exposure of the kind Oracle Java SE carries. Amazon states plainly that it does not charge for Corretto's use or distribution. So the money question is not "which is cheaper to run." All four are zero. The money and risk questions are: whose support window covers your version long enough, who owns the escalation, and who ships patches on a cadence your governance can enforce. This page compares the four on exactly those axes so a migration program can standardize on one primary distribution and one fallback.
Here is the trap that catches most programs. "LTS" is not a fixed industry date. Your support window is whatever the vendor whose binary you downloaded says it is, and the four vendors publish different end dates for the identical Java version. TuxCare put it precisely: Microsoft, Corretto, Zulu, and Temurin all have different end dates for the same version. If you standardize on Temurin 11 assuming you have coverage to 2032 because Corretto says so, you are wrong by nearly five years.
The gap is real and it is large. For Java 11, Eclipse Temurin commits to at least October 31, 2027, while Amazon Corretto 11 and Azul Zulu 11 run to January 31, 2032. That is a 4-year, 3-month difference on the same version. For a large estate, choosing Temurin 11 and then being forced to re-migrate to Java 17 or 21 four years earlier than a Corretto shop is a full second project you did not budget.
| Distribution | Java 8 EOL | Java 11 EOL | Newest LTS stance | Stated LTS commitment |
|---|---|---|---|---|
| Amazon Corretto | Dec 31, 2030 | Jan 31, 2032 | New LTS every 2 years | LTS supported long, ~8 yr windows in practice |
| Azul Zulu (Community) | Dec 31, 2030 | Jan 31, 2032 | Every LTS + current | At least 8 years per LTS; builds from Java 6+ |
| Eclipse Temurin | Dec 31, 2030 | Oct 31, 2027 (at least) | Java 25 to Sep 30, 2031 | At least 4 years per LTS |
| Microsoft Build of OpenJDK | Defers to Temurin | Not the focus | Java 25 LTS to Sep 30, 2030; Java 21 to Sep 30, 2028 | LTS only under Modern Lifecycle Policy |
Read the table as a buyer, not an engineer. Azul Zulu's Community builds carry the longest published windows (at least 8 years per LTS, plus legacy builds back to Java 6) and Corretto matches it on the older versions that matter most in a migration off Oracle. Temurin's 4-year floor is the shortest of the four, which is fine if your program refreshes JDK versions aggressively but a liability if you have long-lived, hard-to-recertify applications. Microsoft is the narrowest by design: LTS only, and it does not even build Java 8 itself, deferring to Temurin for it.
Choosing Temurin 11 over Corretto 11 costs you nothing today and a full re-migration in 2027. The license is free. The re-migration is not.
The binaries are technically near-identical. They all descend from the same upstream OpenJDK, they all ship quarterly security updates aligned to Oracle's January, April, July, October Critical Patch Update cycle. What genuinely differs, and what your risk team should care about, is who you call at 2 a.m. and what contract binds them.
Eclipse Temurin has a structural gap here. Adoptium does not sell commercial support. It publishes binaries and lists third-party providers. If your procurement standard requires a single vendor accountable for both the binary and an SLA-backed support agreement, Temurin does not qualify on its own. You would buy support separately from a Working Group member such as Azul, Red Hat, or IBM, each under its own agreement, its own pricing, and with no guaranteed consistency in patch cadence or escalation between the binary you run and the support you bought. For a regulated estate that is a real audit and continuity finding, not a theoretical one.
Corretto ties support to AWS. There is no separate Corretto support product. Commercial support runs through your existing AWS Support Plan. If you are already an AWS customer with an active plan, the JDK support comes inside a relationship you already pay for, which is efficient. If you are not on AWS, or your AWS spend is small, Corretto commercial support is effectively unavailable to you. That is the constraint to weigh.
Microsoft supports only LTS releases, under its Modern Lifecycle Policy, and explicitly reserves the right not to ship quarterly updates for non-LTS versions. It also does not build Java 8, pointing customers to Temurin instead. So Microsoft is a clean fit for an Azure-centric estate running current LTS versions, and a poor fit for anything on Java 8 or on non-LTS builds.
Azul is the only one of the four selling first-party commercial support with published per-unit pricing, and it is the only non-Oracle vendor offering stabilized security-only builds that let you apply quarterly fixes while minimizing regression risk. For an estate migrating off Oracle Java specifically to reduce cost and risk, that stabilized-build option is a genuine differentiator worth pricing. We cover the contract mechanics in depth in our Azul Zulu vs Oracle Java comparison.
Because three of the four either bundle support into another relationship (Corretto into AWS, Microsoft into Azure) or do not sell it at all (Temurin), Azul is the only distribution with a public per-unit list price you can model against. Those numbers are useful even if you do not choose Azul, because they give you a benchmark for what SLA-backed OpenJDK support is worth.
| Azul support unit | List starting price | Notes |
|---|---|---|
| Per vcore | $20 / year | Volume and tier discounts apply |
| Per physical core | $40 / year | Equals two vcores |
| Per desktop | $25 / year | Standard and Premium tiers |
Model this honestly. For a server estate of, say, 1,000 physical cores, Azul list is around $40,000 per year before volume discount. Compare that against the fully loaded internal cost of running Temurin unsupported plus buying separate third-party support, or against the AWS Support Plan uplift you are already paying if you go Corretto. In our experience negotiating these, Azul's real transacted price sits meaningfully below list at scale, so treat the published figures as a ceiling, not the number you should sign. Whatever you choose, the point stands: SLA-backed OpenJDK support is a low four-figures-per-hundred-cores line item, a fraction of Oracle Java SE's per-employee Universal Subscription. That cost delta is the heart of the CFO business case for leaving Oracle Java.
Coverage matters when your estate is heterogeneous: mixed x64 and ARM, Alpine or musl-based containers, older macOS or Windows. Get this wrong and you standardize on a distribution that does not ship a build for one of your target platforms, forcing a second distribution back into your estate and defeating the whole point of standardizing.
The Temurin base-image change is exactly the kind of silent drift that breaks a migration mid-flight. If you are cleaning JDKs out of build systems, govern image tags explicitly. We walk through this in cleaning Oracle JDK out of CI/CD pipelines and developer workstations.
This is the operational risk that no distribution choice solves for you. All four ship quarterly Critical Patch Updates on Oracle's cycle. But "we're on a supported version" routinely means "we downloaded a build six months ago and never updated it." If your patch level is more than 90 days old, you are running known, published vulnerabilities regardless of how long your vendor's LTS window runs. The LTS end date tells you when patches stop being produced. It says nothing about whether you actually applied the last one.
An 8-year LTS window is worthless if your JVMs are two quarters behind on patches. Governance beats distribution choice every time.
Whatever you standardize on, build the quarterly update into your release cadence and measure patch-level currency as a control, not an aspiration. This is where a migration program either succeeds or quietly reintroduces the risk it was meant to remove. We treat this as a first-order concern in OpenJDK support and rollback risk after leaving Oracle Java.
Do not run a beauty contest across all four. Standardize on one primary distribution and name one approved fallback for the edge cases the primary cannot cover. Here is the buyer-side logic we apply.
The one combination to avoid is the accidental one: three distributions in production because nobody chose. That is where you end up when the distribution decision is delegated to individual teams instead of made once at program level. Make it once, document the primary and the fallback, and enforce it. For how this decision sits inside the wider migration, see the Oracle Java to OpenJDK migration decision and execution guide and the cost-modeled three Java migration patterns.
Inventory your Java versions and target platforms first, because the distribution choice is downstream of that. Once you know you are, for example, 60 percent on Java 11 and 30 percent on Java 8 with a chunk on Alpine containers, the Temurin 11 short window and the platform coverage differences stop being abstract and start narrowing your options for you. Then decide primary and fallback using the logic above, write the standard down, and wire quarterly patching into your release process as a measured control. Do that and the free license, which is the whole reason you are leaving Oracle Java, actually delivers the risk reduction it promises rather than trading one problem for three quieter ones.
Yes. Corretto, Temurin, Zulu Community builds, and the Microsoft Build of OpenJDK are all licensed under GPLv2 with the Classpath Exception, which permits free commercial use with no per-JVM fee and no license audit exposure. Amazon states explicitly that it does not charge for Corretto's use or distribution. Cost only enters if you buy optional commercial support.
If you already run an AWS Support Plan, Corretto is efficient because support comes inside a relationship you already pay for, and its LTS windows on older versions are long. Temurin has no first-party commercial support and a shorter 4-year LTS floor, so it suits cloud-neutral estates with aggressive version refresh and no single-vendor support requirement. On Java 11 specifically, Corretto's window runs to January 2032 versus Temurin's October 2027, a 4-year-plus difference.
Both offer long LTS windows and cover Java 8 and 11 to 2030 and 2032 respectively. Zulu offers the broadest platform matrix and legacy builds back to Java 6, plus first-party commercial support with public pricing and stabilized security-only builds. Corretto ties support to AWS and covers mainstream platforms including Alpine, making it the better fit if you are already an AWS shop.
No. Microsoft does not build Java 8 itself and directs customers to Eclipse Temurin builds for it. Microsoft only provides commercial support for LTS releases under its Modern Lifecycle Policy and reserves the right not to ship quarterly updates for non-LTS versions. It fits Azure-centric estates on current LTS versions, not legacy Java 8 workloads.
There is no single industry-wide LTS date. Each vendor sets its own support window for the identical version, so Temurin, Corretto, Zulu, and Microsoft publish different end dates for the same Java release. Your effective window is whatever the vendor whose binary you downloaded commits to, which is why the distribution choice materially affects when you must re-migrate.
Azul is the only distribution with public per-unit pricing: list starts around $20 per vcore per year, $40 per physical core, and $25 per desktop, all before volume and tier discounts. At scale, transacted prices sit well below list. Corretto and Microsoft fold support into AWS and Azure relationships, and Temurin requires buying support separately from a Working Group member such as Azul, Red Hat, or IBM.
Workday vs Oracle HCM in 2026. Licensing models, total cost of ownership, implementation realities, and the buyer side decision framework that beats the.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
