Azul Zulu JDK vs Oracle Java in 2026. Same runtime, a different bill.

Azul Zulu and Oracle Java SE are built from the same OpenJDK source and certified against the same compatibility kit, so the runtime question is close to settled. The contract, the counting metric and the audit exposure are where the money is.

Is the Zulu JDK as good as Oracle Java?

At the runtime level, yes. Azul Zulu and Oracle Java SE are both production grade JDK distributions built from the same upstream OpenJDK source, and both are certified against the same Java SE Technology Compatibility Kit (TCK). Your applications see the same Java SE platform on either one.

Both ship security fixes on the quarterly OpenJDK schedule each January, April, July and October. The two diverge on the contract: the pricing metric, the annual uplift, the audit exposure and what it costs to leave.

Which Java versions does Azul support that Oracle no longer does?

Azul tracks the same long term support lines as Oracle (Java 8, 11, 17, 21 and 25) and still supports Java 6 and 7 commercially. Oracle's Extended Support for both has ended, which leaves Sustaining Support with no new fixes. For a company carrying a 2011 application that cannot retire before 2028, that legacy coverage can decide the whole case.

Where does the real risk sit in a Zulu migration?

Production scale is not the risk. Azul has shipped certified builds for over a decade and has public references in banking and trading. The risk sits in two places: application vendor support matrices and your own operational assumptions, such as scripts, installers and monitoring agents that look for an Oracle JDK path.

Validate them in that order, vendor matrices first and operations second, because that is the order in which projects fail. A packaged application whose vendor certifies only Oracle JDK can stall a migration that is otherwise finished.

How does Azul pricing compare with Oracle's per employee model?

Azul prices what you run and Oracle prices who you employ. Azul Platform Core is licensed per JVM or per core, while the Oracle Java SE Universal Subscription counts every employee, contractor and agent, Java user or not. On the same workloads, the per employee subscription priced 2 to 5 times a per core support build.

The employee metric hurts most in two situations. The first is where Java is a minority workload, because you pay for the whole workforce to cover a handful of servers. The second is where contractor ratios run high: counted populations landed 20 to 30 percent above badged headcount in engineering firms, utilities and public sector bodies.

On the Azul side, the server metric Azul has published since June 2021 is the vCore. A physical core with hyperthreading enabled counts as two vCores, and a cloud instance counts the vCPUs it is sold with. Container quotes are often written per JVM instead, and the order should say which basis applies to which workload.

Why does the Oracle volume ladder not reduce your exposure?

The ladder lowers the rate per employee, but it never lowers the number of people counted. Volume steps the rate down from $15.00 toward $5.25 per employee per month, with lower rates negotiated above 50,000 employees. The arithmetic, including when ordering above headcount wins, is in the band table worked example.

The counted population grows with the business and not with your Java footprint. A 5,000 employee manufacturer running 30 Java applications pays for 5,000 employees, and outsourcing, project contractors or an acquisition all raise the bill with no new Java deployed. See how Oracle counts contractors and consultants.

What does the comparison look like for a 5,000 employee company?

Say you employ 5,000 people, run those 30 Java applications on 40 production virtual machines of 8 vCores each, and Oracle offers $9.00 per employee per month after discount. The $9.00 rate is hypothetical, chosen from inside the published range. Development and test run on free Zulu Builds in this example.

Any Azul quote below the last line saves money at the 6,000 count. Ask Azul for a per vCore price on the same footprint and rerun the Oracle rows at your real band. The Java calculator does the Oracle side for your own numbers.

Which Azul product should you price: Zulu Builds, Platform Core or Platform Prime?

Price Azul Platform Core. Azul sells three things, and buyers are often quoted the wrong one:

• Zulu Builds of OpenJDK. Free, certified and downloadable, with no SLA. Reasonable for development, test and workloads no one pages you about at 3am.
• Azul Platform Core. The commercial support subscription for the same Zulu builds, and the Oracle Java SE replacement in almost every case. This is the product to price.
• Azul Platform Prime. A performance runtime with the Falcon JIT compiler, the C4 pauseless garbage collector and ReadyNow warmup acceleration. It solves latency problems, not licensing ones, at several times the Core price.

Ask for every quote to name the product line on each line item, and send back any Prime pricing you did not request. A Prime line buys a different JVM, and it can multiply the total for support you never scoped.

When is Platform Prime worth paying for?

Prime earns its price when you have a measured latency or throughput problem, such as garbage collection pauses on a trading or payments service, or slow warmup after every deployment. Run it as a separate business case with a load test on your own application. Keep it out of the Oracle replacement decision, which Core alone settles.

How long does a migration from Oracle Java to Zulu take?

Technical migration to a certified OpenJDK build took 2 to 8 weeks per organization in our benchmarks, far less than the quarters buyers feared. Support parity held in 9 of 10 cases. In the exception, the cause was always an application vendor's certification matrix, never the JVM.

Most of that time goes on inventory and testing. Swapping the binary is quick; confirming every packaged application, build pipeline and container base image takes the weeks.

What has to stay on Oracle Java?

WebLogic and most Oracle product stacks stay on Oracle Java, because Oracle supports them on its own JDK and many carry restricted use Java SE rights. Separate them early. The carve outs set the size of the saving but rarely the decision on the rest, and the WebLogic and Java SE coupling page shows where those rights end.

How do you check which Java you are running today?

Start with an inventory you control, before Oracle asks for one. These sources cover most environments:

• The runtime itself. java -version prints "Java(TM) SE Runtime Environment" for Oracle JDK and names Zulu in the OpenJDK runtime line for Azul builds. java -XshowSettings:properties -version shows the java.vendor property.
• Endpoint management. Software inventory from Microsoft Configuration Manager, Intune or your equivalent tool, filtered on Oracle Java publisher entries.
• Container images. A scan of your registry for base images that ship Oracle JDK, covered in Oracle Java in Docker base images.
• Vendor statements. Written confirmation from each application vendor that it supports an OpenJDK build such as Zulu.

The guide to telling Oracle JDK from OpenJDK lists the file paths and registry keys to check on each platform.

What should you negotiate in an Azul contract?

Negotiate the counting rules before you sign. The Azul terms deserve the same care as the Oracle exit, because a per JVM metric on an autoscaling platform can multiply overnight. Fix the container counting basis and a growth band in the order form, instead of leaving an open meter.

Say a service runs 12 pods at baseline and scales to 48 at peak. If the contract counts peak JVMs, you pay for 48, four times the steady state. A band that counts average concurrent JVMs over a month, or a fixed allowance per cluster, keeps that bill predictable.

Which terms should you ask Azul for?

• Counting basis. Name the metric per workload type (vCore for servers, JVM for containers) and define how autoscaled instances count.
• Growth band. A range of vCores or JVMs covered at the signed price, so normal growth does not trigger a new order mid term.
• Uplift cap. A written cap on the annual increase. Azul negotiates this in a way Oracle does not.
• Scope. Cover the workloads that carry external obligations, such as regulated or customer facing systems, and leave internal tools on free builds.
• Verification. Compliance through a self declared count, with a contractual verification right and a stated notice period.
• Version coverage. The Java versions supported through the full term, including Java 6 or 7 if you depend on them.

That self declared count is far less work than Oracle's formal review of installs and downloads. Eclipse Temurin, free, certified and a swap away, keeps every Azul renewal honest.

The wider distribution field, Corretto and Temurin included, is compared in the OpenJDK alternatives comparison, and the full six option view in the Java options guide.

Does an Azul quote lower Oracle's Java price?

It lowers the rate, sometimes by a lot, and leaves the metric alone. Oracle discounts the per employee number against a credible alternative, but it almost never redefines who counts as an employee.

Is an Azul quote enough to fix an Oracle Java renewal?

The common advice is to show Oracle an Azul quote and take the discount. We think that stops halfway, because a rate discount leaves the counted population growing with every hire and contractor. If the numbers favor Azul, migrate the movable workloads and keep Oracle Java for the carve outs only.

Use the quote purely as a bargaining tool when a documented reason keeps you on Oracle for everything.

What will the Oracle account team say, and how should you reply?

Contract language that caps headcount is covered in capping the headcount in the Oracle Java contract.

What have we seen in Oracle Java to Azul decisions?

Across roughly 30 to 40 Java environments Fredrik Filipsson benchmarked between 2024 and 2025, the switch from Oracle Java to a supported OpenJDK build was rarely a technical decision. The metric gap drove it, and the runtime itself almost never held a migration back.

Oracle discounts numbers and defends definitions, so the Azul quote changes your rate and leaves the employee count where it was.

The audit exposure that shadows the whole comparison is covered in the Java audit defense sequence and the audit triggers analysis. Read both before you remove Oracle JDK, because the removal itself needs a record you can show later.

What to do next

1. Price Platform Core explicitly. Send back any Prime quote you did not scope, because the product line decides the number.
2. Carve out the Oracle product stacks first. Separate WebLogic and similar products so the model prices only the workloads you can move.
3. Count your real Oracle population. Rebuild the employee number with contractors and agents included, and run it through the band table before Oracle does.
4. Fix the container counting basis and growth band. Put both in the Azul order form, with the autoscaling rule written out per cluster.
5. Cap the Azul uplift in writing. Record a costed Temurin swap plan, so the first Azul renewal has a priced alternative on the table.
6. Validate vendor matrices before runtimes. Collect the written support statements before any binary changes. The Java calculator and the Oracle practice run the comparison with you.

Frequently asked questions