Corretto vs Temurin vs Zulu in 2026. Four things differ, and the license is not one of them.

All four builds are free and run the same code. Choose on the support window for your oldest Java release, who is contractually obliged when the JVM fails, how fast security builds ship, and whether a certified binary exists for your platforms.

What is the difference between Corretto, Temurin and Zulu?

The code is close to identical. Amazon Corretto, Eclipse Temurin, Azul Zulu and the Microsoft Build of OpenJDK are all compiled from the same upstream OpenJDK source, all free to run in production, and all run your code. None of them charges a license fee, so the price of the runtime cannot separate them.

Four things do differ, and they are the ones to decide on: 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. The rest of this page takes them in that order.

Most teams reach this choice while leaving the Oracle Java SE Universal Subscription, which Oracle prices from $15 per employee per month at list. If you have not yet settled whether to leave Oracle at all, start with our Oracle Java versus OpenJDK decision guide. This page assumes you have.

For a narrower comparison of Amazon's build against the plain upstream project, see Amazon Corretto versus OpenJDK.

Why do LTS end dates differ for the same Java version?

Because long term support is a promise each vendor makes, and the Java release itself carries no end date. Every provider decides how long it will keep shipping updates for a version, and those decisions diverge most on the older releases that dominate a migration off Oracle.

This is the largest difference between the builds and the one most likely to cost you a second project. Pick a short window on your most entrenched version and you will migrate again years before a peer who picked differently.

Each vendor frames its commitment differently, and each publishes it in a different place:

• Amazon Corretto. Long windows on the versions that matter in a migration. Confirm them in Amazon's Corretto support calendar.
• Azul Zulu, free builds. The broadest version range, including releases older than Java 8. Azul's published support roadmap also lists optional Legacy Production Support for Java 6 and 7 through December 2029.
• Eclipse Temurin. At least four years per long term support release, and builds for as long as the upstream source is maintained. The Adoptium support policy page carries the table.
• Microsoft Build of OpenJDK. Long term support releases only, under its lifecycle policy. Microsoft's OpenJDK documentation calls its dates initial targets that it may extend.

Treat every date above as a vendor statement to confirm on the day you decide. Vendors extend and occasionally shorten these windows. A decision recorded with a dated source holds up in front of an audit committee in a way that a decision recorded from an article does not.

How to read a vendor support window without being misled

• Read the floor. "At least four years" is a commitment to four years. Anything beyond it is goodwill, and goodwill does not belong in a plan.
• Check the version you are stuck on. The window that matters covers your oldest entrenched release. Your newest release will be upgraded anyway.
• Separate free from paid. Some vendors publish one window for community builds and a longer one behind a support contract. Confirm which column applies to you.
• Watch the platform footnotes. A window can apply to Linux on x64 and not to the architecture you actually run.
• Count the months left today. As of September 2026, Temurin 11 and 17 and Microsoft's builds of 11 and 17 have roughly 12 months of published cover remaining. A standard written now around those builds has a short shelf life.

Why the version tail sets your next migration date

Most migrations off Oracle carry a tail of Java 8 and Java 11 workloads that cannot move quickly. That tail should drive the distribution decision, because your modern applications will be refreshed on their own schedule.

If 30 percent of your applications sit on Java 11 and your chosen build commits to October 2027, you have set a date to migrate again whether you meant to or not. A build with a 2032 window on the same version buys four extra years for zero additional license cost.

The 8 person days for retesting and redeploying one application is illustrative, so replace it with your own figure. The effort is the same in both columns. What changes is whether you spend it next year or 51 months later.

Picking the shorter window costs nothing today and a full second project in a few years.

What does TCK certified actually mean, and how do you verify it?

It means a specific build passed the Java SE Technology Compatibility Kit, the conformance test suite that decides whether an implementation may be described as compatible with the Java specification. The claim is real and checkable. It is also narrower than most buyers assume.

What the compatibility kit tests, and what it leaves out

For builds derived from the upstream project, access to the kit runs through the OpenJDK community conformance program and its OpenJDK Community TCK License Agreement. That route is how independent vendors are able to test and publish conformance for their own builds.

• It tests specification conformance. The build implements the Java SE specification for that version correctly.
• It does not test performance. Garbage collector behavior, startup time and memory footprint sit outside it entirely.
• It does not test your application. Conformance is no substitute for your own regression run.
• It does not cover packaging. Fonts, container base images, installers and bundled components sit outside the specification.

The three questions that turn a claim into evidence

A vendor page saying "TCK certified" is marketing until it is tied to the artifact you deploy. Ask these three questions in writing and keep the answers with your decision record.

1. Which exact version? Conformance is claimed per feature release and per update, and a claim for the brand as a whole means little.
2. Which exact platform? A statement covering Linux on x64 does not automatically cover Windows, macOS on Apple silicon, or a musl based container image.
3. Which exact artifact? The certified build and the convenience container image are not always the same object. Confirm which one your pipeline pulls.

How to see which build you are actually running

Before comparing conformance statements, confirm what is deployed today. Most environments turn out to run more builds than the architecture diagram shows.

• Running JVMs. The command "java -XshowSettings:properties -version" prints the system properties. The java.vendor line reads Amazon.com Inc., Eclipse Adoptium, Azul Systems, Inc. or Microsoft, and on Java 11 and later java.vendor.version adds the distribution's own release string.
• Installed JDKs that are not running. The release file in each JDK home directory carries IMPLEMENTOR and JAVA_VERSION lines. An inventory script can collect them without starting Java.
• Container images. A software bill of materials generated at build time lists the JDK package and version in each base image. Scan again after every rebuild of an untagged image.
• Oracle binaries still in place. These need separating from the free builds before anything else, as set out in telling Oracle JDK apart from OpenJDK.

Why building OpenJDK yourself changes your position

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, a vendor build with a published conformance statement costs nothing and answers a question you would otherwise have to answer yourself.

Who is contractually obliged to fix your Java virtual machine?

Only Azul sells a standalone support contract for its own build that covers the JVM wherever it runs. Amazon and Microsoft fold support into their cloud support plans, and Adoptium sells none. The binaries are near identical, so this is the procurement variable that actually differs, and the one your risk function will ask about first.

Eclipse Temurin: an excellent binary with no first party contract

Adoptium publishes Eclipse Temurin under Eclipse Foundation governance, and it is the strongest vendor neutral default available. Adoptium does not sell support. Its own support page says so and points to a list of companies that do.

If you need a service level agreement, you buy it from a working group member such as Azul, Red Hat or IBM, on that supplier's own paper. The party producing your binary and the party obliged to you are then different organizations, which belongs in the risk register of any regulated company.

Amazon Corretto: support arrives inside the AWS relationship

There is no separate support product for Amazon Corretto. Amazon's FAQ says Corretto is covered by an AWS Support Plan on the same basis as its other services, and that it has no plans for a Corretto specific plan. That is efficient if you already hold a plan at a meaningful tier.

Two things decide whether it works for you: a response commitment at your plan tier that you can live with, and an entitlement that extends to Corretto running outside AWS compute. Amazon's FAQ is silent on the second, so get it confirmed in writing if any of your Java runs on premises or in another cloud.

Azul Zulu: first party terms with published units

Azul is the only one of the four selling its own support contract, Azul Platform Core, with publicly discussed per unit pricing. It is also the only one offering stabilized builds that carry security fixes with minimal other change. If you migrated specifically to reduce risk, price that stabilized option even if you end up not buying it.

Azul is also the only vendor of the four where the relationship is a real negotiation with terms to win. We work through those terms in the Azul Zulu versus Oracle Java comparison.

Microsoft Build of OpenJDK: long term support releases only

The Microsoft Build of OpenJDK covers long term support releases under Microsoft's lifecycle policy and does not build Java 8. For Java 8, Microsoft relies on Temurin, and it publishes Temurin based Java 8 container images in the Microsoft Container Registry.

Commercial support is limited to Azure customers with an active Azure Support Plan, for Java deployed to Azure services, Azure Stack and Azure Arc clusters. That makes it a clean fit for an Azure centric company on current releases, and a poor sole standard where a legacy tail or a large on premises footprint exists.

The clauses to read before you sign any support agreement

1. The licensable unit. Core, virtual core, server or desktop. Agree the definition before the rate, because the definition is the multiplier.
2. Build availability after a security release. A response time on tickets is a different promise from a commitment to publish a patched build.
3. Version coverage on the tail. Confirm the contract covers the oldest release you actually run as well as the current one.
4. Platform coverage. The contract should name the architectures and operating systems you run, including container base images.
5. The liability cap. Usually limited to fees paid. Read it before anyone cites indemnity in a risk paper.
6. A price hold. A multiyear term is only worth signing if the unit rate is fixed for all of it.
7. A reduction right. Workloads retire. The contract should let you lower the count at each anniversary without a penalty.

What does commercial support cost when you buy it?

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 vendors either bundle support into another relationship or do not sell it, Azul's published units are the market reference point.

Model these as a band and treat the published figures as a ceiling, because transacted pricing at scale sits meaningfully below list. The full cost comparison against the Oracle line, including internal effort, is in the three pattern cost model, and the version framed for finance is the CFO business case.

A worked example against the Oracle subscription

Say you employ 2,000 people and run Java in production on 20 virtual machines of 8 virtual cores each, with 150 developer desktops that need a supported JDK. Oracle's published tiers go as low as $5.25 per employee per month, so the table gives Oracle that lowest rate even though a company of 2,000 would not qualify for it.

The real gap is wider than the table shows, because the Oracle line uses a rate this company would not get. Even so, scope the Azul quote to the workloads that carry an external obligation. Servers with no such obligation are the first lines to cut, and the covered list is what the contract should name.

What the account teams will say, and how to answer

• "Cover the whole fleet so every JVM is supported." Answer that support is sized to the list of workloads with a contractual or regulatory obligation. Everything else runs the same binary on the free build.
• "Our rate is per physical core." Ask for the quote in both units, and have the order form state whether a hyperthreaded physical core counts as two virtual cores.
• "Corretto is already covered by your support plan." Ask AWS to confirm in writing the response time at your tier and whether coverage extends to Corretto outside AWS.
• "The Microsoft build is supported under your Azure plan." Correct for Java deployed to Azure, Azure Stack or Azure Arc. Ask what covers the same build on your own servers, because Microsoft's support terms do not.
• "Sign for three years and the rate drops." Accept only with the price hold and reduction right from the clause list above.

How fast does each build ship the quarterly security update?

All four publish within hours to days of the upstream release. OpenJDK security updates follow the same quarterly calendar as Oracle's Critical Patch Updates, in January, April, July and October, so the difference between vendors is small. The difference between any vendor and your own pipeline is enormous.

The three components of patch lag, and which one is yours

Read the ownership column. A distribution choice shortens the first row and nothing else, which is why an eight year support window is worthless on a server fleet two quarters behind on updates.

What to put in the standard so cadence is measured

• A named owner for patch currency, with a reporting date each quarter instead of a shared inbox.
• A measured metric. The percentage of running JVMs within one quarter of the current security build, reported alongside your other operational controls.
• Explicit image tags. Container base images change their underlying operating system between releases, so untagged references move underneath you.
• A blocked path back. If the old binary is still reachable internally, it returns. The CI/CD and workstation cleanup guide covers how to close it.

Which builds cover the platforms you actually run?

Zulu has the broadest platform and version matrix, Corretto and Temurin cover the mainstream platforms well, and Microsoft builds only long term support releases from Java 11 onward. 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 purpose of standardizing.

The coverage questions to ask before you standardize

• Architectures. Does a build exist for every architecture you run, including the ARM instances someone adopted for cost reasons last year?
• Containers. Is there a musl based image for the container platform your applications actually deploy into?
• Desktops. Does the desktop story work, including any application that still needs a browser plugin replacement or a Java Web Start substitute?
• Operating system versions. Is anything running on an operating system version your candidate build no longer publishes for?

How do you choose one primary build and one fallback?

Decide once, at program level, and publish it as a standard. The target is one primary build covering 80 percent or more of your Java workloads, plus one named exception build for what the primary cannot cover: legacy versions, unusual platforms or cryptography constraints.

Write the standard as a specification rather than a brand

The reason to standardize is governance. Write the standard so that any build qualifies by meeting criteria, and you stay portable between suppliers at the same feature release.

• Named feature releases the standard covers, with the support window each requires.
• Named platforms and architectures, including container base images.
• A published conformance statement for each version and platform combination in use.
• A stated commitment on build availability after each quarterly security release.
• One named exception build, with the specific reason it exists written next to it.

How the choice changes with company size

A 500 person company on one cloud, running a few dozen Java services on current releases, can usually take its cloud provider's build as primary, skip paid support and spend its effort on patch currency. The exception build may never be needed.

A 20,000 person group with on premises data centers, two clouds and a Java 8 tail has a different problem. Platform coverage and the legacy window dominate, a first party contract often becomes a requirement from the risk function, and the exception build is certain to be used.

Why matching your cloud provider should break the tie, and only that

The usual guidance is to pick the build that matches your cloud provider and treat that as decisive. We disagree, because your Java applications will outlive your cloud strategy, your support plan tier and quite possibly your current cloud vendor.

What strands a company is the version tail and the support window attached to it, because that sets the date you do all of this again. Rank the criteria in this order:

1. The support window covering your oldest entrenched release.
2. Who is contractually obliged when the virtual machine misbehaves.
3. Platform coverage across everything you run.
4. Cloud alignment, used only to settle a tie.

A choice made in that order usually survives a change of cloud provider or support tier. A choice made on cloud alignment alone tends to be reopened at the next platform review.

What have we seen in OpenJDK distribution decisions in 2024 and 2025?

Across roughly 30 to 45 Oracle Java engagements I ran or reviewed in 2024 and 2025, the distribution decision was made badly far more often than it was made wrongly. The build itself was rarely the problem. The process around it usually was, and three patterns came up again and again.

• Teams chose for themselves. The decision was delegated to individual teams, and the company ended with three builds in production and no single vendor accountable for anything.
• The oldest version was ignored. No one checked the support window on the oldest Java release in use, which is the version that decides when the work has to be done again.
• Support was bought without scope. Procurement asked for a support contract and got one, without ever writing down which workloads the contract was supposed to cover.

Each of these is cheap to prevent at the start and expensive to unwind later. A one page standard, a version inventory and a written list of covered workloads would have avoided all three.

How far ahead should you plan a switch between OpenJDK builds?

Start at least 12 months before the published end date on the build you run today. Anyone standardized on Temurin 11 or 17, or on Microsoft's builds of those versions, is already inside that window, unless the vendor extends its date.

What to do next

1. Map your versions. List your Java feature releases with the share of applications on each, and identify the oldest release you cannot move within two years.
2. Map your platforms. List every target platform, including architectures, container base images, desktop operating systems and anything unusual.
3. Check the windows. Compare the published support window for that oldest release across each candidate build, and record the date and source for each.
4. Collect conformance evidence. Ask each candidate for a conformance statement covering the exact version and platform you will deploy, and file it with the decision record.
5. Scope any support contract. Decide which workloads carry an external obligation that requires a contract, and size support to that list.
6. Publish the standard. Choose one primary and one named exception build, and publish them as a specification with criteria.
7. Own patch currency. Appoint a named owner and start reporting the percentage of JVMs within one quarter of the current security build.
8. Wire it in. Build the standard into base images, provisioning templates and pipelines, and confirm the rollback path using the support and rollback risk analysis.

Frequently asked questions