Java 25 buys you free updates only until October 2028, so the real choice in 2026 is whether to accept a permanent two-year upgrade treadmill or exit Oracle once
Oracle's NFTC grants free use of the current LTS until one year after the next LTS ships, which means JDK 25 falls off in October 2028 and Java 29 (planned September 2027) starts the same clock again. Staying free is not a licensing decision, it is a commitment to a mandatory major-version upgrade every 24 months, funded by your engineering budget. If your organization cannot reliably clear a full estate upgrade inside a 24-month window, the free path is a deferred subscription bill at $15 per employee per month list.
Prepared by Redress Compliance · August 27, 2026 · Oracle Java advisory. Java audit defense and renewal engagements, 2024 to 2026.
Executive summary
The Java 25 free window closes in October 2026 for JDK 21 and in October 2028 for JDK 25, so you are choosing an upgrade cadence, not a license.
All Oracle JDK 21 updates through September 2026 remain under the NFTC, and from the October 2026 Critical Patch Update JDK 21 moves to the Java SE OTN license, the same paid-for-production terms that already govern Java 8, 11 and 17.
Treating the free tier as free ignores that a failed 24-month upgrade converts instantly into a headcount-priced subscription with no relationship to your Java footprint.
A 12,000-employee enterprise pays roughly $1,188,000 per year at list whether it runs four Oracle JDK installs or four thousand, and a 5,000-employee company on 40 servers pays $630,000, or $15,750 per server.
The migration path is the only option that ends the treadmill permanently, and it also happens to be the strongest price lever if you stay.
Benchmark data across 80-plus contracts shows organizations with a credible OpenJDK migration plan achieved 28 to 44 percent price reductions, while the average move from pre-2023 processor licensing to the employee metric ran 340 percent higher.
Do nothing and you inherit Oracle's 2026 enforcement machinery rather than a quiet grace period.
Oracle has three years of download telemetry (IP addresses, corporate domain associations, timestamps, auto-update check-ins), soft outreach is now converting into formal GLAS notices under the audit clause with roughly 45 days' notice.
And initial compliance claims are reported at 3 to 10 times what organizations actually owe.
How the NFTC clock actually works, version by version
The No-Fee Terms and Conditions license, introduced in September 2021, is not a grant of free Java. It is a rolling grant tied to release cadence: the current LTS is free from its release date until one year after the next LTS ships. Everything else follows mechanically from that one sentence.
JDK 17 lost the grant in September 2024, with build 17.0.12 (July 2024) as the last free update, and every JDK 17 patch since then has required a paid subscription for production use.
JDK 21 is now at the same point: the July 2026 update was the last free NFTC-licensed Oracle JDK 21 build, java.com builds remain free to use until September 16, 2026, and updates from the October 2026 Critical Patch Update forward are planned under the Java SE OTN license.
The same license already governing Java 8, 11, and 17.
JDK 25, released September 2025, is planned to stay under NFTC until October 2028, which follows from Oracle's own FAQ dating Java 29 to September 2027. That is the whole product: a 24-month free window that resets only if you complete a full estate upgrade inside it.
Our 2026 version support cliff guide tracks the same dates against installed estates.
| Version | Free under NFTC until | Last free build / event | What lands after |
|---|---|---|---|
| JDK 17 (LTS) | September 2024 | 17.0.12, July 2024 | OTN license, subscription for production patches |
| JDK 21 (LTS) | September 2026 | July 2026 CPU; java.com use to Sep 16, 2026 | OTN from the October 2026 CPU; paid support to at least Sep 2031 |
| JDK 22, 23, 24 (non-LTS) | September 2026 | 6 months of patches each after release | No further patches; 12-month window from release to reach an LTS |
| JDK 25 (LTS) | Planned October 2028 | Tied to Java 29, planned September 2027 | Same OTN transition, one cycle later |
| GraalVM for JDK 21 | October 2026 CPU | Last NFTC-equivalent CPU | GraalVM OTN License |
Two rows in that table get missed in almost every estate review we run. First, the non-LTS versions: 22, 23, and 24 do not get their own two-year runway.
They inherit JDK 21's September 2026 cliff, they only ever received six months of patches each, and the NFTC grant assumes you move to an LTS within twelve months of the non-LTS release. A team that "stayed current" on 24 is closer to the cliff than a team that parked on 21.
Second, GraalVM for JDK 21 moves to the GraalVM OTN License at the October 2026 CPU, which is a separate exposure that native-image users rarely track alongside the JDK itself.
Be precise about the legal effect, because vendor messaging routinely overstates it. The cliff stops the forward flow of free patches. It does not retroactively make an installed copy unlicensed.
A JDK 21 build downloaded and deployed under NFTC before the cutover remains lawfully installed under the terms it was obtained under.
Your exposure begins the moment someone downloads or applies an OTN-licensed patch in production, and Oracle's download telemetry is precisely what makes that moment visible.
The two paths priced side by side, with the numbers that decide it
Three branches, not two. Path A, chase the free LTS forever: zero license spend, and a non-negotiable estate-wide major-version upgrade every 24 months, plus non-LTS discipline for any team that wanders off the LTS line.
The cost is real, it is just booked as engineering time, application recertification, vendor-supplied middleware compatibility waits, and regression testing on the long tail of applications nobody wants to touch. Path B, subscribe: the Java SE Universal Subscription on the Employee metric.
Listed at $15 per employee per month down to $5.25 in published tiering, one-year standard term. Path C, migrate to a non-Oracle build: a one-time engineering event plus optional third-party support, and it is the only path that terminates the clock rather than resetting it.
Our migration decision gate works through the qualification criteria in detail.
| Dimension | Path A: chase free LTS | Path B: Oracle subscription | Path C: migrate off Oracle |
|---|---|---|---|
| Annual license cost | $0 | $15 to $5.25 per employee per month, list | $0 to Oracle |
| Oracle worked example | n/a | 28,000 (23,000 staff + 5,000 agents/contractors) x $6.75 x 12 = $2,268,000/yr | n/a |
| Support uplift | n/a | None. No separate 22% line; rate is all-in | Optional third-party support |
| Credit for legacy Java SE Advanced perpetuals | n/a | None | n/a |
| Deployment ceiling | n/a | 50,000 processors, excluding desktops and laptops | None |
| Recurring obligation | Full estate upgrade every 24 months | Annual renewal at headcount | One-time engineering, then done |
| Cost driver | Engineering capacity | Total headcount, not Java footprint | Application count and complexity |
The row that decides most cases is "cost driver." Path B prices your payroll, not your Java estate.
A 12,000-employee enterprise pays roughly $1,188,000 a year at list whether it runs four Oracle JDK installs or four thousand, and a 5,000-employee company running Oracle Java on 40 servers pays $630,000, which is $15,750 per server.
If your Java footprint is small relative to headcount, Path B is structurally the worst deal on the table and Path C pays for itself inside a single renewal.
The trap in Path A is that it looks free on the ledger and is not free on the calendar.
You are underwriting a mandatory upgrade every 24 months, forever, with no allowance for an acquisition, a hiring freeze, or a vendor application that lags two LTS versions behind. If you cannot demonstrate that you cleared the JDK 17 to 21 upgrade inside its window.
Treat the free path as a deferred subscription bill and price it accordingly.
Defend an Oracle Java audit without overpaying
Oracle now audits Java SE on employee count, not installs, which can multiply the bill several times over. How to defend the notice and exit to OpenJDK.
Get the white paper →The real question is not which JDK, it is whether your organization can upgrade on a 24-month beat
Every conversation I have had with a CIO about Java 25 since September 2025 opens as a technical question and ends as an operating question.
The technical part is nearly trivial: Oracle JDK 25 and a well-maintained OpenJDK build of the same version pass the same TCK, run the same bytecode, and differ in ways most application teams will never observe.
The licensing part is also simple on paper: the NFTC gives you free use of the current LTS until one year after the next LTS ships, so JDK 25 stays free until October 2028, with Java 29 planned for September 2027 restarting the clock.
What neither of those framings captures is the actual commitment you are signing. Accepting the free tier is not choosing a product.
It is entering a standing internal SLA to complete a major-version upgrade across the entire estate, every 24 months, indefinitely, with no contractual counterparty other than yourself and no penalty clause other than a subscription invoice.
Read the free tier as a financial instrument and it becomes clearer. Oracle has written a call option on your engineering velocity. If you clear each upgrade inside the window, the option expires worthless and Oracle collects nothing.
If you miss, Oracle exercises, and the strike price is set by the Java SE Universal Subscription at $15 per employee per month list, tiering down to $5.25 in the published bands. Oracle did not price that instrument casually.
The employee metric counts all full-time, part-time and temporary staff plus the employees of agents, contractors, outsourcers and consultants who support your internal business operations, and the required quantity is the number of Employees, not the number who use the programs.
Oracle's own worked example on the price list runs 28,000 people at $6.75 per month to $2,268,000 a year. That is the payoff profile of the option you just wrote.
The second structural feature is the one that catches boards off guard: the cost of missing is completely uncorrelated with the size of your Java footprint. A 12,000-employee enterprise pays roughly $1,188,000 a year at list whether it runs four Oracle JDK installs or four thousand.
A 5,000-employee company that needs Oracle Java on 40 servers pays $630,000 a year, which works out to $15,750 per server.
So the risk you are managing is not "how much Java do we run," it is "is there any single deployment we cannot move in time." One unpatched legacy application, one appliance nobody owns, one vendor-supplied JRE inside a middleware install.
And a seven-figure obligation attaches to an estate whose Java footprint would have cost five figures under any rational per-unit metric.
This is a step function, not a slope, and step functions are not manageable through incremental effort.
That leads to the part of the 24-month window that is not yours to schedule.
Most enterprise estates contain packaged software the customer does not control: ISV appliances shipped with an embedded JRE, middleware that certifies against a specific JDK, monitoring agents, build tooling, ETL platforms.
Your upgrade window is bounded by the slowest third party in the chain, and in my experience the tail vendors routinely certify a new LTS 12 to 18 months after GA.
Subtract that from 24 months and you are asked to plan, test, remediate and cut over the remainder in the residual window while your own release calendar continues.
Note also that GraalVM travels on the same schedule, so teams running native-image have a second license surface moving to the GraalVM OTN license on the same clock.
We already have observed evidence on who clears this beat, and it is the 17-to-21 cycle. NFTC expired for Oracle JDK 17 in September 2024, with build 17.0.12 the last free update.
The organizations that were fully off 17 before that date had two characteristics in common: a single owner accountable for JDK version across the estate, and an inventory good enough to name every host before the project started.
The organizations that missed it did not miss by weeks, they missed by years, and many are still running unpatched Java 17 in production today while negotiating under audit pressure. The pattern repeated at the Java 21 boundary in September 2026.
Nothing in the current cycle suggests the outcome distribution changes for 25.
So the honest test is empirical, not aspirational. Look at your last two completed major-version Java upgrades and measure elapsed time from kickoff to the last production host retired, not effort or story points.
If either took more than 18 months, the 24-month window has no margin, because the next one will be harder: the estate grew, the people who did the last one moved on, and the ISV tail lengthened. In that case the free path is not free.
It is a subscription with a delayed invoice, and you should model it as one, at list, from 2028 forward.
The closing asymmetry is what should force the decision into 2026 rather than 2028. Migration cost is bounded, one-time and largely knowable in advance: inventory, replace binaries, retest, retire, document.
Treadmill risk is unbounded and recurring, priced on headcount you do not control, enforced by a vendor that logs download IPs, corporate domains and auto-update check-ins, and now converts unanswered soft outreach into formal GLAS notices.
Bounded and once beats unbounded and forever at almost any reasonable discount rate.
Deciding in 2026 also preserves the only leverage that reliably moves Oracle's price: benchmark data across 80-plus contracts shows organizations with credible OpenJDK migration plans achieving 28 to 44 percent reductions. Deciding in 2028 means negotiating with the cliff behind you.
The uncomfortable read is that the Java decision is a diagnostic for something larger. An organization that can move its entire JDK estate inside 24 months can also patch quickly, retire legacy predictably, and hold ISVs to certification commitments.
If you cannot do it for Java, the same constraint is priced into every other renewal you face, Oracle or otherwise. Treat the upgrade-cadence test as the finding, not the Java version.
Practical consequence: run the 18-month test before you run any pricing model. If you fail it, the correct 2026 posture is a funded exit program with a subscription as the bridge, negotiated on migration credibility.
If you pass it, take the free tier but put the next two upgrade windows on the executive calendar with a named owner, because the second miss is the expensive one.
What migration actually removes, and what it does not
Migration removes exactly one thing: the requirement to hold a Java SE Universal Subscription going forward. It does that only when every Oracle JDK and Oracle JRE deployment is gone and replaced, on servers, desktops, build agents, containers, images and appliances.
Partial migration removes almost nothing from a licensing standpoint, because the metric is headcount. Ninety percent migrated with 40 hosts remaining still produces a full employee count obligation at list, which is why the exit decision has to be scoped as complete or not attempted.
The second point buyers underestimate is retrospective. When Oracle establishes that Java became paid for your organization, it typically backdates the claim to that point, commonly January 2019 or your first non-free download, and unpaid historical use is where audit claims inflate.
The only defense that consistently reduces that window is evidence that you stopped earlier than Oracle asserts.
That evidence has to be built per host, not per program.
What works in an audit is a retirement record for each machine: hostname, the Oracle binary and version string removed, the replacement build installed, the date, and who performed it, exported from your configuration management or endpoint tooling rather than assembled by hand afterward.
Absent that, Oracle's telemetry (download IPs, corporate domain associations, timestamps, auto-update check-ins) becomes the only dated record in the room, and it always reads against you.
Treat per-host retirement evidence as a deliverable of the migration project with the same weight as the technical cutover, and preserve it for the full look-back period, not one budget year.
If a clean break is not achievable, entity scoping is the strongest remaining lever.
Rather than licensing the group, license only the legal entities that still run Oracle Java after the migration, which we have modeled at up to 78 percent off a group baseline and which is the closest thing to an exit short of full removal.
It requires the contract to be signed at entity level and the residual footprint to be genuinely contained inside those entities, so plan the corporate boundary before the technical work, not after. Finally, check GraalVM.
A naive JDK swap leaves native-image builds and the GraalVM toolchain on Oracle terms, moving to the GraalVM OTN license on the October 2026 cadence, and that exposure survives every OpenJDK replacement you make.
The pattern we see repeatedly is a technically successful migration that fails as an audit defense because nobody dated it. Removal is cheap; provable removal is what caps the retrospective claim.
Build the evidence trail on day one of the project, and involve audit defense before Oracle asks, not after the formal notice lands.
Evidence base: what we see in audits, renewals and benchmarks
The 2026 shift is not a change in Oracle's licensing text, it is a change in what Oracle can prove.
Oracle has logged binary download events (IP address, corporate domain association, timestamp, account detail) plus auto-update check-ins from installed copies since the NFTC arrived in 2021, and three years of that telemetry now functions as an audit foundation.
The organizations receiving formal letters in 2026 are not selected at random.
The mechanical detail that decides your first 45 days: a soft outreach email from a sales or license consulting contact is not a contractual event, while a formal notice from GLAS under the master agreement audit clause starts obligations typically at 45 days' notice.
Treat the two differently or you concede scope before the audit formally exists. Our engagement pattern, and the wider dataset, puts a typical Java audit at 8 to 14 months from notice to close letter, with initial claims landing at 3 to 10 times the defensible liability.
Opening Java audit findings routinely overstate defensible exposure by this multiple before any entity, metric or retirement evidence is applied.
Raw HR headcount submitted to Oracle typically includes temps and non-supporting contractors that the Employee definition does not reach.
| Data point | What the dataset shows | Buyer-side implication |
|---|---|---|
| Negotiated employee rate, 1,000 to 10,000 employees | $9.50 to $12.80 per employee per month against $15 list | Roughly 15 to 37 percent off list is achievable without heroics |
| Credible OpenJDK migration plan on the table | 28 to 44 percent price reduction (80+ contracts) | The exit plan is the discount, not the volume |
| Move from pre-2023 processor licensing to Employee metric | Average cost increase of 340 percent | Any pre-2023 paper still in force is a material asset |
| Band boundary at 10,000 employees | 9,999 employees = $1,259,874; 10,000 = $990,000 | One additional employee removes $269,874 of annual list |
| Partial migration with entity scoping | Modeled at 78 percent off a group baseline | Strongest lever short of a full exit |
Four patterns recur often enough to plan against.
First, the counted population is almost never the correct population: the Employee definition covers agents, contractors, outsourcers and consultants that support your internal business operations, which is narrower than a payroll extract.
And we routinely strip 18 to 28 percent before the first submission.
Second, band boundaries reward arithmetic, and the 9,999 versus 10,000 inversion is the clearest case.
Third, pre-2023 contracts matter: usage-based pricing survives inside them, and Oracle will describe that paper as obsolete long before it actually is, which is why keeping the legacy Java metric is worth more than most renewal discounts.
Fourth, and most quantified, buyers who arrive with a costed, dated OpenJDK migration plan take 28 to 44 percent off the price, which means the migration analysis pays for itself even when you decide to stay.
If a formal notice has already landed, the sequence in our end-to-end Oracle Java audit walkthrough is the one to follow rather than improvising against a 45-day clock.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
Your first five moves
- Inventory every Oracle JDK and GraalVM binary by host before the October 2026 CPU, with download provenance where you have it, because GraalVM for JDK 21 moves to the GraalVM OTN License on the same date and is the exposure teams miss.
- Score your last two major-version upgrades in elapsed months and put the 24-month capability test in writing, pass or fail, signed by the platform owner: if your last JDK 8 to 11 or 11 to 17 program took 30 months, the free path is a deferred subscription bill and the board should read that sentence, not infer it.
- Rebuild the employee count from HR data rather than a payroll extract, stripping temps and non-supporting contractors (typically an 18 to 28 percent overcount), then check your position against the nearest band boundary, because at 9,999 versus 10,000 employees the arithmetic inverts by $269,874 a year.
- If you are migrating, capture per-host retirement evidence with dates as you go, so retired hosts are demonstrably out of scope in any later audit, and stage entity scoping as the fallback: licensing only the legal entities still running Oracle Java has modeled at 78 percent off a group baseline.
- Route every Oracle contact through one named channel and answer nothing informally, treating a soft letter as marketing rather than an obligation and reserving the 45-day clock for a formal GLAS notice under the audit clause.
The five moves above are sequenced deliberately: three of them (inventory, headcount rebuild, retirement evidence) produce artifacts that serve both outcomes.
Whether you stay on Oracle or leave, the same host-level inventory and the same corrected employee number are what you negotiate with, and the dataset says buyers holding a costed migration plan take 28 to 44 percent off the subscription price.
You are not choosing a path in month one, you are buying optionality cheaply. Two mistakes cost more than any pricing error. The first is answering a soft letter with a spreadsheet, which converts an informal inquiry into a scoped data set Oracle did not have to ask for.
The second is treating the 24-month upgrade beat as an engineering aspiration rather than a funded, staffed commitment with a named owner. Both failures are organizational, not contractual, and both are visible in the 2026 migration decision gate before you sign anything.
Frequently asked questions
When exactly do free Oracle JDK 25 updates end?
Oracle plans to keep JDK 25 updates under the NFTC until October 2028, which is one year after the next planned LTS, Java 29, dated September 2027 in Oracle's JDK License FAQ.
From the first Critical Patch Update after that point, JDK 25 updates are expected to move to the Java SE OTN license, meaning production use requires a subscription. Treat October 2028 as a planning date rather than a guarantee, because the trigger is the Java 29 ship date, which can move.
Does the NFTC cliff make my installed Java deployment illegal?
No. The license change stops the free flow of new patches going forward; it does not retroactively invalidate the copies you already installed and used under the NFTC.
What you lose is the right to install and run the post-cliff updates in production without a subscription, which is a security problem rather than an immediate compliance breach. Vendor and reseller messaging routinely overstates this, so hold them to the precise wording.
Is upgrading to Java 25 cheaper than migrating to OpenJDK?
On paper yes, because Java 25 costs nothing in license fees until October 2028 while migration costs engineering time now. But upgrading to Java 25 buys only 24 months and commits you to repeating the exercise for Java 29, Java 33 and onward, whereas migration is a one-time cost that ends the cycle.
The comparison you should run is migration cost once against the discounted cost of an upgrade every two years plus the probability-weighted cost of missing one, priced at $15 per employee per month list.
What does Oracle actually charge if we miss the window?
The Java SE Universal Subscription is priced per employee per month, starting at $15 for 1 to 999 employees and falling to $5.25 in the 40,000 to 49,999 band, with no published rate above 50,000.
Employee means all full-time, part-time and temporary employees plus those of agents, contractors, outsourcers and consultants supporting your internal business operations, not just Java users. Oracle's own worked example puts 28,000 employees at $6.75 per month at $2,268,000 per year.
Do non-LTS versions like Java 23 or 24 give us any extra runway?
No, they shorten it. Non-LTS releases receive patches for only six months after release, and the NFTC grant depends on moving to an LTS within twelve months of that release.
Versions 21, 22, 23 and 24 all sit inside the same September 2026 free-use boundary created by the September 2025 arrival of JDK 25. Anything on a non-LTS build should be treated as already out of runway.
Does having a migration plan actually reduwhat Oracle charges?
Yes, measurably.
Across a benchmark set of more than 80 contracts, organizations that could present a credible OpenJDK migration plan achieved 28 to 44 percent price reductions, and negotiated rates of $9.50 to $12.80 per employee per month were observed for 1,000 to 10,000-employee organizations against $15 list.
The word doing the work is credible: named target distribution, host counts, per-application owners and dates. A stated intention with no artifacts moves nothing.
If we migrate off Oracle Java, can Oracle still claim back fees?
It can try. Oracle typically looks back to the point Java became paid for your organization, often January 2019 or your first non-free download, and calculates fees to the present unless you can prove you stopped earlier.
That proof is per-host retirement evidence with dates, because hosts retired before the audit date are out of scope. Build that evidence during the migration, not after a notice arrives, and keep the download provenance records that connect each binary to a license grant.
