All four builds are free, so the license is never the variable. Choose on the support window covering your oldest entrenched release, on who is contractually obliged when the virtual machine misbehaves, on how fast the security build appears, and on whether a certified binary exists for your platform.
Every build here is free and every build here runs your code, so the license is never the variable. Four things genuinely differ: the support window on the version you run, who is contractually obliged when the virtual machine misbehaves, how fast the security build appears, and whether a certified binary exists for your platform.
Because long term support is a vendor commitment, not a property of the Java release. Each provider decides how long it will keep producing updates for a version, and those decisions diverge sharply on the older versions that dominate a migration off Oracle.
This is the single largest difference between the builds, and it is the one most likely to cost you a second project. Choosing a short window on your most entrenched version means re migrating years earlier than a peer who chose differently.
Published support windows, as stated by each vendor. Verify before you standardize.
| Distribution | Java 8 | Java 11 | Stated commitment | Where to confirm |
|---|---|---|---|---|
| Amazon Corretto | To December 2030 | To January 2032 | Long windows on the versions that matter in a migration | Amazon's Corretto support calendar |
| Azul Zulu, free builds | To December 2030 | To January 2032 | Broadest version range, including releases older than Java 8 | Azul's published support roadmap |
| Eclipse Temurin | To December 2030 | At least October 2027 | At least four years per long term support release | The Adoptium support policy page |
| Microsoft Build of OpenJDK | Not built, defers to Temurin | Not the focus | Long term support releases only, under its lifecycle policy | Microsoft's OpenJDK documentation |
Treat every date in that table as a vendor statement to confirm on the day you decide, not as a fixed fact. Vendors extend and occasionally shorten these windows, and a decision recorded with a dated source is defensible in a way that a decision recorded from an article is not.
Most migrations off Oracle carry a tail of Java 8 and Java 11 workloads that cannot move quickly. That tail, not the modern estate, should drive the distribution decision, because the modern estate will be refreshed anyway.
If 30 percent of your applications sit on Java 11 and your chosen build commits to October 2027, you have set a re migration date whether you meant to or not. Choosing a build with a 2032 window on the same version buys four extra years for zero additional license cost.
Picking the shorter window costs nothing today and a full second project in a few years. The license is free. The re migration is not.
It means a specific build passed the Java SE Technology Compatibility Kit, the conformance test suite that determines whether an implementation may be described as compatible with the Java specification. It is a real, checkable claim, and it is narrower than most buyers assume.
Access to the kit for builds derived from the upstream project runs through the OpenJDK community conformance program, which is how independent vendors are able to test and publish conformance for their builds.
A vendor page saying "TCK certified" is marketing until it is tied to the artifact you are deploying. Ask three questions, in writing, and keep the answers with your decision record.
If your team compiles the upstream source itself, the resulting binary carries no conformance statement from anyone. That is legal and technically fine, and it removes the evidence an auditor or a software vendor may ask for.
Do it only where you have a specific reason and a specific owner. For everyone else, taking a vendor build with a published conformance statement costs nothing and answers a question you would otherwise have to answer yourself.
Only one of these four vendors will sign a document that puts that obligation on itself directly. The binaries are near identical, so the support relationship is the procurement variable that actually differs, and it is the one your risk function will ask about.
Adoptium publishes Eclipse Temurin under Eclipse Foundation governance, and it is the strongest vendor neutral default in the market. What it does not do is sell support.
If you need a service level agreement, you buy it from a working group member such as Azul, Red Hat or IBM, under that supplier's own paper. That is workable, and it means the party producing your binary and the party contractually obliged to you are different organizations.
Say that out loud in a regulated environment, before somebody discovers it during an incident.
There is no separate support product for Amazon Corretto. Commercial support runs through your existing AWS Support Plan, which is efficient if you already hold one at a meaningful tier.
Two questions decide whether that works for you. Does your plan tier carry a response commitment you can live with, and does your support entitlement extend to Corretto running outside AWS compute. Confirm the second in writing if any part of the estate is on premises.
Azul is the only one of the four selling its own support contract with publicly discussed per unit pricing, and the only one offering stabilized builds that carry security fixes with minimal other change. For an estate that migrated specifically to reduce risk, that stabilized option is worth pricing even if you do not buy it.
It is also the only one of the four where the vendor relationship is a genuine negotiation with terms to win. We work through those mechanics in the Azul Zulu versus Oracle Java comparison.
The Microsoft Build of OpenJDK covers long term support releases under Microsoft's lifecycle policy and does not build Java 8, pointing customers to Temurin for it. That makes it a clean fit for an Azure centric estate on current releases and a poor sole standard for an estate with a legacy tail.
Low four figures per hundred cores at published starting points, which is a small fraction of a per employee subscription at the same scale. Because three of the four either bundle support into another relationship or do not sell it, one vendor's published units are the market reference point.
Published starting points, useful as a ceiling rather than a price
| Unit | Published starting point | What to check |
|---|---|---|
| Per virtual core, per year | About $20 | How virtual cores are counted on your hypervisor |
| Per physical core, per year | About $40 | Whether it maps to two virtual cores in your contract |
| Per desktop, per year | About $25 | Whether developer machines are in or out of scope |
Model these as a band and treat published figures as a ceiling, because transacted pricing at scale sits meaningfully below list. The full cost comparison against the Oracle line, including the internal effort, is built out in the three pattern cost model and framed for finance in the CFO business case.
All four track the same quarterly upstream security cycle and publish within hours to days of the upstream release. The difference between vendors here is small. The difference between vendors and your own pipeline is enormous.
Where the time actually goes between a security release and a patched production system
| Stage | Typical elapsed | Who owns it |
|---|---|---|
| Upstream fix to vendor build published | Hours to a few days | Your distribution vendor |
| Vendor build to your approved base image | Days to weeks | Your platform team |
| Approved image to production everywhere | Weeks to a quarter | Application owners and change governance |
Read the ownership column. A distribution choice moves the first row and nothing else, which is why an eight year support window is worthless on an estate two quarters behind on updates.
Coverage is where a good decision quietly fails. Standardize on a build that does not ship for one of your target platforms and you force a second distribution back in, which defeats the point of standardizing at all.
Platform coverage at a glance, to be confirmed against the current download matrix
| Distribution | Mainstream coverage | Alpine and musl | Legacy versions |
|---|---|---|---|
| Amazon Corretto | Linux on x64 and aarch64, Windows, macOS including Apple silicon | Yes | Java 8 and 11 covered, nothing older |
| Azul Zulu | Broadest matrix of the four across Linux, Windows and macOS | Yes | Builds available for releases older than Java 8 |
| Eclipse Temurin | Strong mainstream coverage across the common platforms | Yes, on current releases | Java 8 and 11 covered |
| Microsoft Build of OpenJDK | Cross platform on the releases it supports | Limited | Does not build Java 8 |
Decide once, at program level, and write it down as a standard rather than a preference. The target is one primary covering 80 percent or more of the estate, and one named exception build for the cases the primary genuinely cannot cover.
Primary and fallback by estate profile
| If your estate is | Primary | Fallback | The reason |
|---|---|---|---|
| Heavily on AWS with an active support plan | Corretto | Zulu | Support inside a relationship you already pay for, long windows on Java 8 and 11 |
| Azure centric, current releases only | Microsoft Build | Temurin | Aligned lifecycle, with Temurin covering the Java 8 gap Microsoft does not build |
| Long lived applications or a rule requiring one accountable supplier | Zulu | Temurin | Longest published windows, broadest platform matrix, first party contract available |
| Cloud neutral with disciplined version refresh | Temurin | Corretto | Vendor neutral governance, with Corretto covering the longer version tail |
| A significant Java 8 estate that cannot move yet | Zulu or Corretto | Temurin | The version tail decides it, and the tail is where the risk sits |
The reason to standardize is governance, not loyalty. Write the standard so that a build qualifies by meeting criteria, and the estate stays portable between suppliers at the same feature release.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
The usual guidance is to pick the build that matches your cloud provider, and to treat that as the decisive criterion. We disagree. Cloud alignment is a convenience, and your estate will outlive your cloud strategy, your support plan tier and quite possibly your current cloud vendor. What strands an estate is the version tail and the support window attached to it, because that is what sets the date you have to do all of this again. Choose on the support window covering your oldest entrenched release, then on who is contractually obliged when the virtual machine misbehaves, then on platform coverage. Let cloud alignment break the tie. Decided in that order the answer is stable for years. Decided cloud first it lasts until the next platform strategy.
Decide on your oldest entrenched Java release first. Corretto and Zulu publish materially longer windows on Java 8 and 11 than Temurin does, so an estate with a large legacy tail should start there. Temurin is the strongest vendor neutral choice for a cloud neutral estate that refreshes versions on a disciplined cadence.
Because long term support is a vendor commitment rather than a property of the release. Each provider decides how long it will keep producing updates, and on Java 11 the published windows differ by more than four years across these builds. Your effective window is whatever the vendor whose binary you run has committed to.
That a specific build passed the Java SE compatibility test suite for a specific version on a specific platform. It confirms specification conformance, not performance, not packaging, and not that your application works. Ask for the conformance statement covering the exact version, platform and artifact you are deploying.
No. Adoptium publishes the binaries and lists third party providers, so a support contract comes from a working group member such as Azul, Red Hat or IBM under their own paper. That means the organization producing your binary and the organization contractually obliged to you are different parties, which is worth stating explicitly in a regulated environment.
Through your existing AWS Support Plan rather than a separate product. If you already hold a plan at a meaningful tier the support arrives inside a relationship you pay for anyway. Confirm in writing whether the entitlement extends to Corretto running outside AWS compute if any part of your estate is on premises.
No. Microsoft does not build Java 8 and directs customers to Eclipse Temurin for it, and it supports long term support releases only under its lifecycle policy. That makes it a clean primary for an Azure centric estate on current releases and a poor sole standard where a legacy tail exists.
Within hours to a few days of the upstream release for all four, so the difference between vendors is small. The weeks that follow are your own pipeline and change governance, which is where almost all real patch lag lives. Measure the percentage of running JVMs within one quarter of the current build and report it as a control.
Write the standard as a specification rather than a brand. Name the feature releases, the platforms, the conformance evidence required and the build availability commitment expected. Builds meeting that specification are interchangeable at the same feature release, which keeps a future switch a procurement decision rather than a project.
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.
