Oracle Java free versions in 2026, release by release. JDK 21's free window has closed, and the next patch starts the bill.

OpenJDK and every mainstream non Oracle build are free in production with no end date. Oracle JDK is free only inside its No Fee Terms window, which among long term support releases now covers only JDK 25, and a paid build prices your whole headcount.

Which versions of Oracle Java are free today?

Java the language is free, OpenJDK is free, and every mainstream OpenJDK build from a vendor other than Oracle is free in production with no end date. Oracle JDK is free only inside its No Fee Terms window, and among long term support releases only JDK 25 still qualifies, until September 2028.

Oracle JDK 21 left that window on September 16, 2026. The July 2026 quarterly update, 21.0.12, released on July 21, was the last quarterly build under the free terms. Oracle also shipped 21.0.12.1 on August 18, 2026 under its new monthly security patch cycle, and that build still carries the free license.

Each row changed status on a specific date. Whether a build is free depends on the license file that shipped with that binary, so two installs of the same major version can sit on opposite sides of the line.

Which non Oracle builds are free in production?

All the mainstream OpenJDK distributions are free for commercial production use permanently. None of them uses an employee metric, and none gives Oracle anything to audit:

• Eclipse Temurin from the Adoptium project.
• Amazon Corretto, the default on many AWS images.
• Azul Zulu, with paid support available from Azul if you want it.
• BellSoft Liberica.
• The Microsoft Build of OpenJDK.
• The Red Hat build of OpenJDK, SAP's SapMachine and Alibaba's Dragonwell.

Choosing between them is a question of support windows, patch cadence and platform coverage. Our comparison of Corretto, Temurin and Zulu covers that choice in detail.

What about Oracle's own OpenJDK builds?

Oracle also publishes OpenJDK builds on jdk.java.net under the open source GPL. They are free for any purpose, including commercial production, and carry no license risk. The drawback is the update tail: Oracle updates each one for only about six months, so a standard built on them means a new release every six months.

Which license covers the Java build you are running?

Four licenses have governed Oracle Java in seven years, and a typical company still has installs under all four. Which one binds a given install depends on the exact build and the day it was downloaded. Identify the license before anyone argues about the version.

Why the version number alone does not settle it

A Java 8 install reports its version as 1.8 whether it is 8u202 and free, or 8u211 and licensable. The same holds at the 17.0.12 and 17.0.13 boundary. Only the exact build number and the distributor answer the question, so an inventory that stops at the major version tells you nothing about licensing.

What changed when the Oracle JDK 21 free window closed?

Nothing changed on the day itself. No build stopped working on September 17, no license check fired, and no server behaved differently. The exposure starts when someone installs the next Oracle JDK 21 update, and the first one under the paid terms is the October 20, 2026 Critical Patch Update.

Why the next patch is the trigger

Oracle does not need you to buy anything on the day a window shuts. It needs your security team to apply the next patch, which they will, because closing vulnerabilities is their job. Applying that build converts a free install into a licensable one.

The same thing happened twice before. Java 8 installs were patched past 8u202 and Java 17 installs past 17.0.12, in most cases by a security team closing a vulnerability ticket.

Why monthly security patches raise the risk

Oracle now adds monthly Critical Security Patch Updates, released on the third Tuesday, between its quarterly Critical Patch Updates. The August 18, 2026 update included Java SE, the September one did not, and Oracle is targeting a Java update for November 17, 2026.

Each extra Oracle JDK 21 release is another chance for patch automation to pull a paid build onto a server.

What choices remain for a team still on Oracle JDK 21?

A typical move to a non Oracle build takes 3 to 9 months. A team that had not started by early 2026 could not finish before September 16, and a team starting now will still have Oracle JDK 21 in production when the October update lands. The option to be clean before the paid build is gone for most companies.

What remains is a choice between three routes, each with its own cost. The CIO and the CISO should make it together, in writing:

• Freeze and migrate. Hold at the last free build and accept an unpatched runtime while the migration runs.
• Subscribe for the migration period. Budget for the subscription until the last Oracle JDK 21 install is gone, and treat it as the price of a late start.
• Upgrade to Oracle JDK 25. That keeps you free until September 2028, and it means repeating this exercise in two years unless you change distributor.

What does one unlicensed Oracle JDK install cost?

It costs the same as a thousand installs, because the Java SE Universal Subscription is priced per employee. The number of Java installs does not enter the calculation. List pricing starts at $15 per employee per month for the smallest band, and Oracle's published tiers go as low as $5.25 for the largest companies.

Take two hypothetical companies, each with one application still on a paid Oracle JDK 21 build after October 20.

That is how the per employee subscription ends up costing 3 to 10x the value of the workload it is meant to cover. For who counts as an employee, including contractors, see our guide to the employee metric.

Why isolating one application does not reduce the bill

Isolating a stubborn application on an old build contains the technical risk. It leaves the commercial exposure untouched, because one Oracle workload on a paid build still prices the whole workforce. Use isolation to buy weeks for a migration, and plan to remove the build.

What do personal use and development use actually cover?

Both are narrower than most teams assume. Under the OTN license, personal use is defined by the purpose of the activity, and development use ends where the software starts running the business.

• Personal use depends on the purpose. Oracle's own examples are homework and a personal tax return. Business accounting is not personal use, and a finance analyst running a Java tool at home for company work is commercial use.
• A corporate laptop is commercial use in practice. The laptop exists for company work, so the personal use grant does not travel with the person.
• Development use covers building the thing. Writing code, unit tests, prototypes and demonstrations are covered.
• Production support is not development. A build agent producing a production artifact is outside the grant. So is a staging environment that mirrors production for release validation, and a performance test environment that certifies a production change.
• Desktops are the least governed installs. They are also the easiest for Oracle to evidence, because the update check phones home.

Where development use stops on a developer laptop

The developer laptop is argued in every review. Oracle's position in the reviews we have sat in is that a machine which exists to support a production system is not covered. You can win that argument for some machines, but losing it on even a few brings the whole employee count into play.

The cheaper course is to put OpenJDK on developer machines and remove the question. Our note on non production and test licensing covers the gray cases.

What have we seen in Oracle Java license reviews in 2024 and 2025?

Across roughly 30 to 40 Java licensing reviews we advised in 2024 and 2025, almost no company had chosen to be exposed. They had lost track of which license a given install arrived under. Three patterns came up again and again:

1. The 8u202 boundary. The most frequent single finding was a Java 8 install patched past that build.
2. Expired free windows. Teams that believed the No Fee Terms covered them were often running an older release that had already left its window, because no one owned the window as a calendar date.
3. No evidence of the terms. Not one client had archived the license text or the download page as it read on the day they downloaded, which is the document that settles the argument later.

Why we do not recommend chasing each new LTS to keep Oracle JDK free

The common advice is to stay inside the No Fee Terms by upgrading to each new long term support release. The grant is real, and we still advise against relying on it. It hands your upgrade calendar to a supplier, and in those 30 to 40 reviews not one client moved every install inside a window whose dates Oracle sets.

The failure follows a consistent shape. About 90 percent of the servers move, and the last 10 percent slip past the date for ordinary reasons: a vendor certification, a frozen platform, a team with other priorities. Then someone applies a patch, and the part of the organization least likely to watch license terms creates the bill while acting correctly.

The security control that protects the business is the same control that creates the Java bill.

The better course is to standardize on an OpenJDK build whose free status has no end date. Keep Oracle JDK only where a vendor certification demands it, and track each of those installs against its window as a dated change item.

How do you check which of your Java installs are not free?

Check by distributor and exact build. Four fields decide each install, and version number is not one of them:

1. Distributor. Read the IMPLEMENTOR field in the release file at the top of JAVA_HOME. Older Java 8 builds may not carry that field, so use the java -version output for those.
2. Exact build number. 8u202 against 8u211 and 17.0.12 against 17.0.13 are the boundaries, and 21.0.12.1 against the October 2026 build is the newest one.
3. Install date and installing account. These bound how far back a retroactive claim can reach.
4. Host purpose. Production, staging, build agent and developer machine each carry a different argument.

Running java -version prints the build, and Oracle JDK identifies itself as "Java(TM) SE Runtime Environment" where OpenJDK builds print "OpenJDK Runtime Environment". Add java -XshowSettings:properties -version to see the java.vendor property. Our guide to telling Oracle JDK from OpenJDK covers Windows installs and container images.

Mistakes that turn a free install into a paid one

• Trusting the vendor field alone. Oracle's free OpenJDK builds also name Oracle as the implementor, so pair that field with the runtime name before you classify anything.
• Deleting before recording. Removing a binary destroys the evidence that limits how far back a claim can go. Capture all four fields first.
• Leaving intake open. Build agents, container base images and developer machines keep reintroducing Oracle builds after a cleanup. See our note on Oracle Java in Docker base images.
• Skipping the archive. Read the LICENSE file inside the build you actually run, screenshot the current terms with a visible date, and record the install date and downloading account for every Oracle build.

Oracle's audit position keys off download and update records tied to your corporate domain. If your security team has been patching past the boundary builds, assume Oracle already knows. The metric change itself is covered in the Java licensing pillar, the audit sequence in Java audit defense, and the wider library in the Oracle practice.

What will Oracle say about expired free builds, and how should you answer?

Oracle's Java team usually opens softly and works toward a subscription quote. These are the lines that come up most often, with replies that keep the facts on your side:

What to put in writing if you do subscribe

If a subscription is the right answer for the migration period, negotiate it as a bridge. Ask for these terms in the order document:

• A term that matches the migration. The subscription should end when the last Oracle JDK 21 install is due to go, with no automatic renewal.
• A fixed employee count. State the number, the date it was taken and the HR source, so the renewal cannot start from a larger figure.
• A release of past use. Name the period before the start date that the subscription settles, so the purchase closes retroactive claims as well as covering the future.
• A priced extension. Agree now what three or six more months would cost, in case the last applications slip.

Our Java practice handles these negotiations and maps the exit from Oracle's build with you.

What to do next

1. This week. Put the October 20, 2026 update in the change calendar as a dated gate for every Oracle JDK 21 install, and decide whether you will freeze at the last free build or leave Oracle's build entirely.
2. Before contacting anyone. Archive the license text and download page as they read today, with a visible date, and store them with the migration file.
3. By early October. Scan every install and record distributor, exact build number, install date and host purpose. Sort the Oracle rows against the boundary builds.
4. Before October 20. Tell the security and patching teams which Oracle JDK 21 hosts must not receive Oracle updates, including the one planned for November 17, and block unmanaged Oracle downloads at the proxy.
5. Within the quarter. Standardize on one non Oracle HotSpot build and one fallback, written as a specification based on support windows and patch cadence.
6. During migration. Seal the intake points first: build agents, container base images and developer machines. Then work through the servers in order of exposure.

Frequently asked questions