A mixed Java estate now carries four separate cliff dates between October 2024 and October 2028, and the JDK 21 one already passed when Oracle shipped its last free binary in July 2026

Oracle no longer runs one Java licence deadline. JDK 17 flipped to paid terms in October 2024, JDK 21 flips with the October 2026 CPU (last free binary shipped July 2026), JDK 26 hits end of life on 18 September 2026, and JDK 25 runs out in September or October 2028 depending on which Oracle page you read. If your remediation calendar has one row instead of four, you are already exposed on at least one version, and the Employee metric means a single unremediated host prices the entire workforce at $5.25 to $15 per employee per month.

Prepared by Redress Compliance · August 27, 2026 · Oracle Java advisory. Java audit defense and renewal engagements, 2024 to 2026.

Every Oracle Java conversation goes wrong in the same place: the customer builds one calendar when Oracle maintains two, and the two have nothing to do with each other.

The first column is the licence terms date, the point at which a given JDK version stops being available under the No-Fee Terms and Conditions (NFTC) and moves to the Java SE OTN licence, which is free only for personal, development, and a handful of other named uses.

The second column is the paid support date, the Premier, Extended, and Sustaining windows set by Oracle's Lifetime Support Policy: Premier runs a minimum of five years from general availability, Extended adds three more for LTS releases only.

And Sustaining runs indefinitely with no bug or security fixes at all.

A version can be fully supported and commercially licensable long after its free grant has closed (Java 8 and 11 are the obvious cases), and a version can be free today with its paid tail expiring years before your hardware refresh.

In 25 years of negotiating this vendor, the single most common budgeting error I see is a remediation plan sequenced against Premier end dates, which are commercial availability dates, rather than against the licence flip, which is the only date that creates a compliance liability.

Partial remediation is a rational strategy under a Processor metric and an entirely irrational one under the Employee metric that governs the Java SE Universal Subscription.

Oracle's definition counts all of your full-time, part-time, and temporary employees, plus all full-time, part-time, and temporary employees of your agents, contractors, outsourcers, and consultants that support your internal business operations.

The definitive sentence is the one that removes any deployment linkage: the quantity of the licences required is determined by the number of employees and not just the actual number of users of the programs. Read that literally, because Oracle does.

One Windows host with an Oracle JDK 21 October 2026 CPU applied, one build agent that never dropped its GraalVM 21 toolchain, one forgotten JDK 17 appliance, and the subscription that cures it is priced against your entire headcount plus your contractor and outsourcer population.

A 90 percent remediated estate carries 100 percent of the cost.

The arithmetic is unforgiving at the small and mid end.

List bands run across seven tiers from $15.00 per employee per month at 1 to 999 employees down to $5.25 at 40,000 to 49,999, so a 4,000-employee organisation with one non-compliant host is looking at a seven-figure annual list exposure created by a single line in an inventory report.

Large estates should also note the 50,000 Processor ceiling buried inside the Employee metric definition, which caps deployment rights rather than cost and quietly matters in heavily virtualised environments.

The practical conclusion is that remediation is binary, not proportional: the upgrade versus migrate decision must be taken estate-wide, with a named owner for every last host, because the tail is where the whole price sits.

In 25 years of negotiating with this vendor, I have almost never seen a Java exposure caused by an engineering team that could not upgrade.

Application teams move faster than CIOs assume: a Spring Boot service on JDK 17 goes to JDK 21 in a sprint, and JDK 21 to 25 in less than that, because the language and JVM changes between LTS releases are modest and the tooling ecosystem is already there.

The binding constraint is not capacity, it is knowing what you have. When the October 2024 JDK 17 cliff arrived, the customers who paid were not the ones with hard upgrade problems.

They were the ones whose inventory was six to twelve months stale on the day the licence terms changed, and who therefore could not tell Oracle, with evidence, what had already been removed.

The failure modes repeat with almost tedious consistency.

First, bundled JVMs inside third-party appliances and vendor middleware that nobody in the organisation owns: a backup product, a storage controller, a network management console, a healthcare integration engine, each shipping an Oracle JDK inside its install tree.

Each covered by a supplier contract that nobody has read closely enough to know whether the supplier holds a distribution right or is simply passing your licence obligation through to you.

Second, developer laptops with java.com downloads, which is the single largest source of unlicensed Oracle installs I encounter, because the download is trivially available and the Employee metric does not care whether the machine is a production server or a contractor's Mac.

Third, container base images that pin an old JDK tag, so a pipeline that nobody has touched in two years quietly rebuilds Oracle JDK 17 into fifty new images every week.

Fourth, and the most corrosive to inventory confidence, is the co-installation problem: an Oracle JDK sitting on the same host as an Eclipse Temurin or Amazon Corretto build, where the CMDB records the OpenJDK path, marks the host green.

And misses the Oracle binary in a second directory that a legacy agent still points at.

Fifth is the version-string problem. Oracle and non-Oracle builds report almost identically under java -version. Distinguishing them reliably requires reading the release file, the vendor property, the installation path, and in disputed cases the binary signature.

Most discovery tooling, and virtually every general-purpose SAM platform I have reviewed on the buy side, does not do all four consistently, which means the report you are relying on is a probability, not a fact.

That matters more than it should, because it inverts the usual audit power balance. Oracle has telemetry that most customers do not have about themselves: java.com download records tied to corporate IP ranges and email domains, plus the auto-update channel that phones home from installed JREs.

When an Oracle LMS or Java sales conversation opens with a list of your download activity, the vendor is frequently better informed about your estate than your own asset register is. In a normal audit, the customer holds the ground truth and the vendor is reconstructing it.

In Java, that is reversed, and it is why so many Java conversations start from a number you cannot immediately refute.

Our read of the [2026 version support cliff](redress-oracle-java-2026-version-support-cliff-guide) is that this asymmetry, not the price per employee, is what actually converts a cliff date into a signed subscription.

The practical conclusion is uncomfortable for anyone who has just built a tidy remediation plan. A calendar of four cliff dates is worth nothing on its own, because the calendar assumes the estate is knowable on demand. It is not.

It has to be reconciled on a fixed cadence, monthly, by a named individual, against three independent sources: endpoint discovery, container registry scanning, and procurement or download records.

Anything that appears in one source and not the others is an exception, and exceptions are the whole game.

Which sets the lead time. Thirty days before a cliff is enough to schedule work you already know about.

It is nowhere near enough to find a bundled JVM inside a third-party appliance, get the supplier to confirm in writing whether their licence covers you, and either replace the component or negotiate an indemnity.

That process runs eight to twelve weeks in my experience even with a cooperative vendor. Discovery should therefore run 90 days ahead of every cliff, and the reconciliation that feeds it should be running continuously, not started when the date appears on someone's dashboard.

The sequencing rule is the one thing most plans get backwards. Do not remediate in order of host count, because that puts the biggest, easiest, best-owned population first and leaves the awkward stragglers against the deadline.

Remediate in order of cliff proximity, then by ownership ambiguity within each cliff. A hundred well-owned JDK 17 containers are a scheduling problem. Eight JDK 21 hosts inside a third-party appliance with no named owner are the thing that will still be unresolved in November.

Every cliff needs three artefacts: a version-to-owner map that names an individual per version and per environment, a per-cliff freeze date (no new installs of that version after that day, enforced in the pipeline).

And an exception register where every entry carries an expiry date and a named approver.

Per workload, the fork has exactly three prongs and you should force a decision on each one rather than letting it drift. Upgrade to JDK 25 buys you a free-in-production window to 2028 and puts you back on the treadmill.

Swap to a non-Oracle OpenJDK build (Temurin, Corretto, Zulu.

Liberica) removes the version from the calendar permanently and is the right answer for the large majority of standard server workloads, which is the calculation we work through in the [upgrade versus migrate decision](redress-oracle-java-upgrade-vs-migrate-decision-2026).

Accepting subscription cost is defensible only for a deliberately bounded set, typically workloads with a vendor-certified Oracle JDK requirement.

And only when you have first shrunk that set as far as it will go, because the Employee metric prices the whole workforce regardless of how small the set is.

Non-LTS hosts on 22, 23 and 24 should not appear in a schedule at all. Their support life was six months, they are outside the no-fee grant from September 2026, and the only correct calendar entry is this week.

JDK 8 estates that genuinely will not move before December 2030 need the opposite treatment: stop trying to schedule them, ring-fence them, document the business justification, log them in the exception register with a 2030 expiry.

And price them into the budget explicitly rather than discovering them during a negotiation.

The factual spine here comes from four sources, and it matters that they disagree with each other.

Oracle's own publications supply the cliff dates: the Java SE Support Roadmap puts JDK 17 on OTN terms from 15 October 2024, the August 2026 Java blog puts JDK 21 on OTN terms from the October 2026 CPU.

And the JDK License General FAQs put JDK 25's NFTC window closing in September 2028 while the blog says October 2028.

That is a one month contradiction between two live Oracle pages on the same version. Azul dates the practical JDK 21 cliff earlier still: java.com builds free to 16 September 2026, with the last free NFTC update shipped in July 2026.

The Universal Subscription price list supplies the exposure math, seven bands from $15.00 per employee per month at 1 to 999 down to $5.25 at 40,000 to 49,999, with Oracle's own 28,000 employee worked example as the unarguable illustration.

Against that, Redress pricing reviews of 70 to 90 signed Java order documents from 2024 to 2025 supply the behavioural pattern.

The recurring pattern is consistent enough to plan against. Outreach is soft and friendly, arrives a quarter or two after the cliff, and opens with download history rather than with a licence claim, because download history is evidence Oracle already holds and you cannot easily contest.

From there the conversation moves straight to the Employee metric, and a quote lands that prices the entire workforce off a handful of hosts. The buyer's instinct is to argue about the hosts. Oracle's position does not depend on host count.

Related advisory: the full topic guide.

When exactly do free Java 21 updates end?

Oracle's published position is that Oracle JDK 21 updates through and including September 2026 remain under the No Fee Terms and Conditions licence, and the October 2026 Critical Patch Update moves to the Java SE OTN licence.

In practice the last free NFTC binary shipped in July 2026, and Azul dates the java.com free-use window to 16 September 2026. Plan to July 2026 as the operational deadline, not September.

Is Java 25 free in production, and until when?

Yes, JDK 25 is currently available under the NFTC for production use. Oracle's Java blog says NFTC coverage runs to October 2028, while Oracle's own JDK Licence FAQ says September 2028, one year after Java 29 in September 2027.

The two pages conflict, so build your calendar to September 2028 and treat any later date as a bonus, not an assumption.

Do I need a subscription if only a few hosts still run Oracle JDK 17 or 21?

Yes, and that is the core problem. The Java SE Universal Subscription is priced per Employee, defined to include full-time, part-time and temporary staff plus the staff of agents, contractors, outsourcers and consultants supporting internal operations.

Licensed quantity is set by headcount, not by how many people use Java, so a handful of hosts prices the whole workforce.

What happens to Java 8 and 11 in a mixed estate?

Both sit on OTN terms already, so commercial production use requires a subscription. Oracle has committed to supporting Java SE 8 until at least December 2030 and Java SE 11 until at least January 2032, and it waived Extended Support fees for Java 11.

Long paid tails are a scheduling convenience, not a licensing reprieve.

Are non-LTS versions like Java 22, 23 and 24 safe to keep running?

No. Non-LTS releases are free under the NFTC only for their planned six-month support life, so hosts left on 22, 23 or 24 after that window fall outside the no-fee grant and receive no further updates. Oracle JDK 26 reaches end of life on 18 September 2026.

Treat every non-LTS host as immediate remediation, not scheduled work.

Does GraalVM have its own cliff date?

Yes, and it is the row most estates miss. Beginning with the October 2026 CPU, GraalVM for JDK 21 updates move to the GraalVM OTN Licence Including Licence for Early Adopter Versions, and Oracle is directing users to Oracle JDK or Oracle OpenJDK builds instead.

Include GraalVM installs in the same discovery sweep as the JDK inventory.

How far ahead of a cliff should discovery run?

Ninety days minimum. Inventories in mixed estates are routinely six to twelve months stale by the time a cliff lands, mostly because of bundled JVMs inside third-party products, container base images and developer laptop downloads.

A 30-day sweep finds the easy hosts and leaves the expensive ones, which is exactly the population Oracle's download telemetry already knows about.