Staying legal on Oracle Java 8 or 11 now costs $630,000 a year for a 5,000-employee company, even if only 40 servers run it
Oracle Java 8 and 11 never fell under the free NFTC license, so every production instance requires the Employee-metric Universal Subscription at $5.25 to $15.00 per employee per month. Because the metric counts headcount rather than installs, the cost per server can exceed $15,750, which is why the decision is almost never "pay Oracle" but "which OpenJDK build patches Java 8 through December 2030 for free."
Prepared by Redress Compliance · August 27, 2026 · Oracle Java advisory. Java SE audit and renewal engagements, 2023 to 2026.
Executive summary
Java 8 and 11 were never covered by the No-Fee Terms and Conditions, so there is no free Oracle path for them at any patch level: only Java 17 (through 17.0.12), 21 and 25 ever launched under NFTC.
That means any Oracle-branded JDK 8 or 11 build in production after the public update dates (January 2019 for 8, and standard support already closed for 11) sits under OTN terms and requires a paid subscription, retroactively for the period of use.
The bill is set by total employee count, not by Java footprint, so a 5,000-employee company running Oracle Java on 40 servers pays $630,000 per year at list, equal to $15,750 per server.
Oracle's price list counts all full-time, part-time and temporary employees plus the employees of agents, contractors, outsourcers and consultants supporting internal operations, whether or not any of them touch Java.
Free security patches for Java 8 through December 31, 2030 are available from Eclipse Temurin, Azul Zulu and Amazon Corretto, which removes Oracle's central argument that a subscription is the only route to updates.
The trap is vendor-specific: Red Hat's build of OpenJDK 8 and BellSoft Liberica 8 both end included support on November 30, 2026, and Red Hat's OpenJDK 11 standard support ended October 31, 2024.
Where a full exit is not feasible, entity-scoping the subscription to only the legal entities still running Oracle Java modeled at 78 percent below a group-wide baseline, and negotiated rates of $9.50 to $12.80 against a $15.00 list are documented in the 1,000 to 10,000 employee band.
Organizations arriving with a credible OpenJDK migration plan achieved 28 to 44 percent reductions, so the migration work is itself the pricing lever.
The move from processor-based to employee-based licensing raised average Java cost by 340 percent across benchmarked estates, and band boundaries create absurd cliffs where one extra headcount saves $269,874.
At 9,999 employees the annual list is $1,259,874; at 10,000 it drops to $990,000, which makes headcount definition and band arithmetic the first two negotiation moves, ahead of any discount conversation.
What Oracle actually charges for Java 8 and 11 in 2026
Since January 2023 there is exactly one commercial vehicle for Oracle Java 8 and 11 in production: the Java SE Universal Subscription, sold on a single Employee metric. Named User Plus and Processor metrics are gone from the new-business price list.
The rate is banded across seven published tiers, from $15.00 per employee per month at 1 to 999 employees down to $5.25 at 40,000 to 49,999, with no published rate above 50,000 (Oracle negotiates those individually, which means you are quoting blind).
The standard term is one year, which strips out the multi-year renewal protections most buyers assume they hold.
The rate is all-in: there is no separate 22 percent support line on the Universal Subscription, so any budget that adds a support uplift on top of the per-employee rate is double-counting by roughly a fifth.
Buried in the price list is a ceiling almost nobody models: the Employee metric permits installation on up to 50,000 processors, exclusive of desktops and laptops, beyond which additional licensing is required. Large estates with heavy virtualization should test that number before signing.
| Employees (band) | Rate /employee/month | Annual list at band edge | Cost per server if 40 servers run Java |
|---|---|---|---|
| 1 to 999 | $15.00 | $179,820 at 999 | $4,496 |
| 1,000 to 2,999 | $12.00 | $431,856 at 2,999 | $10,796 |
| 3,000 to 9,999 | $10.50 | $1,259,874 at 9,999 | $31,497 |
| 10,000 to 19,999 | $8.25 | $990,000 at 10,000 | $24,750 |
| 20,000 to 29,999 | $6.75 | $2,268,000 at 28,000 (Oracle's own example) | $56,700 |
| 30,000 to 39,999 | $5.70 | $2,735,932 at 39,999 | $68,398 |
| 40,000 to 49,999 | $5.25 | $3,149,937 at 49,999 | $78,748 |
Two things the table cannot show. First, the count is not your HR headcount.
Oracle's price list defines Employee as all full-time, part-time and temporary staff plus the equivalent staff of your agents, contractors, outsourcers and consultants who support your internal business operations, and it states plainly that the quantity is determined by total Employees.
Not by who touches Java.
Oracle's own worked example is 23,000 staff plus 5,000 third-party personnel equals 28,000 counted, at $2,268,000 per year. A managed-services contract with a 4,000-seat offshore delivery centre can push you across a band edge without a single new install.
Second, the band arithmetic inverts at boundaries. At 9,999 employees the list is $1,259,874; at 10,000 it is $990,000. One additional counted employee removes $269,874 of annual cost.
That is not a rounding artifact, it is a negotiation lever, and it argues for auditing your count in both directions. And note what earns you nothing: legacy perpetual Java SE Advanced licenses give zero credit against the subscription price.
They remain useful as audit cover for historical deployments and as migration runway, but they do not reduce a single dollar of the renewal quote.
Why Java 8 and 11 never had a free option, and why that matters more than the version numbers
The most expensive internal misconception we correct in Java engagements is this one: a platform team reads about the October 2026 cliff, assumes it is a new restriction, and concludes their Java 8 estate was fine until now. It was not.
Java 8 and Java 11 through 16 were never published under the No-Fee Terms and Conditions license. Only Java 17, 21 and later LTS releases launched under NFTC. Java 8 and 11 have always shipped under OTN terms, which prohibit production use without a subscription.
There was no free window to fall off. If you have been patching Oracle JDK 8 since 2019 without a subscription, you have been accruing exposure for seven years, not seven months.
Read our 2026 Java version support cliff guide for what genuinely changes this year, and keep it separate from what has been true since 2019.
The dates matter for scoping, not for entitlement. Java 8 public updates ended January 2019. Premier Support ended March 2022.
Extended Support runs to December 2030, and Oracle waived the Extended Support uplift fee for the March 2022 to December 2030 window, which flatters the headline rate but does not create an entitlement.
Java 11 reaches Oracle EOL in September 2026, with the uplift waived from October 2023 to January 2032. None of that turns OTN binaries into free binaries.
The clause that costs the most money is the NFTC override. If you have any Java subscription agreement in force, for any version, NFTC cannot be applied to any version in your estate.
Buying a small subscription to cover 40 Java 8 servers therefore re-licenses your Java 25 desktop and container fleet under commercial terms too.
That is the single strongest argument for a clean OpenJDK exit rather than a token Oracle purchase, and it is why the Java 17 position is worth checking before you sign anything.
One downstream item for database teams: Oracle Database 19c stops receiving Java updates after December 2030, so the Java 8 end date is also a 19c planning date.
What Oracle ERP Cloud really costs per employee
Oracle prices Fusion ERP Cloud per employee, not per user, which inflates true cost. The buyer side guide to module economics and the modernization discount.
Get the white paper →Getting Java 8 and 11 patches without Oracle: the dates that decide your build
The question is not whether free Java 8 patches exist, it is which vendor's calendar matches your application's remaining life. Three builds carry Java 8 to December 31, 2030 at zero cost: Eclipse Temurin, Amazon Corretto and Azul Zulu.
Two builds that enterprises assume are equivalent, Red Hat's build of OpenJDK 8 and BellSoft Liberica JDK 8, end included support on November 30, 2026 and then move to a paid extension.
That distinction matters most if your container base images are RHEL or UBI, because "OpenJDK 8" in a Dockerfile usually means the Red Hat build, and the free window closes in months, not years.
Java 11 is tighter still: standard support from both Red Hat and BellSoft ended October 31, 2024, so a Java 11 estate on those builds has already been unpatched for over a year unless someone bought the extension.
Read this alongside the 2026 Java version support cliff before you standardize, because the same team that picks the Java 8 build usually owns the 17 and 21 decisions too.
| Build | Java 8 free/included support ends | Java 8 paid extension | Java 11 position |
|---|---|---|---|
| Eclipse Temurin | Dec 31, 2030 | Not required | At least Oct 2027 |
| Amazon Corretto | Dec 31, 2030 (disputed, see below) | Not required | Confirm on AWS lifecycle page |
| Azul Zulu | Dec 31, 2030 | Commercial tiers beyond | Commercial tiers available |
| Red Hat build of OpenJDK | Nov 30, 2026 | ELS-1 to Dec 31, 2030 | Standard ended Oct 31, 2024; ELS-1 to Oct 31, 2027 |
| BellSoft Liberica | Nov 30, 2026 | To Mar 31, 2031 | Standard ended Oct 31, 2024 |
| Microsoft Build of OpenJDK | n/a for 8 | n/a | At least Oct 2027 |
| Oracle JDK (OTN) | Dec 31, 2030 | Subscription mandatory | Sep 2026 |
One row in that table is contested and you should treat it as unresolved rather than settled. Published sources disagree on Amazon Corretto 8: OpenLogic's lifecycle data shows support ending May 2026, while HeroDevs places Corretto 8 in the December 31, 2030 group.
Both cannot be right, and the gap is four and a half years of patching for a JDK that many AWS-native shops have already standardized on by default.
Do not resolve this from a blog post, including ours. Pull Amazon's own Corretto lifecycle page, screenshot it with a date stamp, and file it with your build standard decision record.
If Corretto 8 genuinely ends in 2026 and your estate is large, Temurin is the lower-risk default because its 2030 date is stated consistently across sources and its provenance is easy to evidence in an audit.
The wrong answer here does not cost you money in 2026, it costs you an emergency migration in the middle of an Oracle inventory request.
The analysis: Oracle is no longer selling patches, it is selling the cost of proving you removed its binaries
Under the pre-2023 Named User Plus and Processor models, price tracked footprint. If you ran Oracle Java on 200 cores and decommissioned 160 of them, your renewal quote fell roughly in proportion.
That relationship made the product legible: Oracle sold security patches, you bought them for the machines that needed them, and every removal was a savings event you could book.
Procurement teams built their whole Java strategy on that arithmetic, and it worked, because the meter and the deliverable were measuring the same thing.
The Employee metric severed that link deliberately. Footprint is now priced out of the equation entirely, capped only by an obscure 50,000-processor ceiling that almost no one hits.
A 5,000-employee company running Oracle Java on 40 servers pays $630,000 a year at list, which is $15,750 per server, and it pays exactly the same $630,000 if the count drops to four servers.
The consequence is that a single forgotten Oracle JDK 8 install on a decommissioned test box, or one buried inside an ISV appliance, exposes the entire group-wide liability. What Oracle is actually selling at that point is not patches. It is the elimination of discovery risk.
This inverts the economics of remediation. Partial migration, the standard corporate response to any licensing problem, yields zero savings here. Ninety-five percent removal and zero percent removal produce identical invoices unless the remaining five percent is fenced into a scoped legal entity.
That is precisely why entity-scoping, licensing only the entities that still run Oracle Java rather than the whole group, models at 78 percent off a group baseline and is the strongest exit short of full migration. It is the only structure that lets incomplete work translate into money.
It also explains audit behavior that otherwise looks irrational. Oracle's teams do not chase volume in Java engagements, because volume is irrelevant to the number.
They chase inventory completeness: download logs tied to your domains, `java -version` sweeps, ISV-bundled runtimes, developer laptops, CI runners.
In our experience the buyers who end up paying full list are not the ones with the largest estates, they are the ones who cannot produce defensible evidence that the last binary is gone.
The counter-strategy follows directly. Removal proof is a negotiation asset, not just a compliance chore. The benchmark data is unambiguous: organizations arriving with credible OpenJDK migration plans achieved 28 to 44 percent reductions, while pure discount asks landed at 20 to 40 percent.
A migration plan with dated milestones, a named build standard and per-application owners tells Oracle its renewal is a wasting asset. A discount request tells Oracle only that you have budget pressure, which is not leverage.
For legacy Java 8 and 11 specifically, this is where the work is hardest and therefore worth the most. These applications are old, sparsely documented, often maintained by people who left, and frequently wrapped inside third-party products where the vendor, not you, chose the runtime.
Proving full removal across that estate is genuinely difficult, which is exactly why doing it converts into the largest concessions.
Start the inventory before Oracle asks, and treat the resulting evidence pack as the commercial instrument it is, as covered in our analysis of Java 17's expired free window.
Where the money actually lands: benchmarks, bands and headcount defense
Oracle publishes $15.00 per employee per month for the 1 to 999 band, but the VendorBenchmark dataset (published December 2025, updated May 2026) puts negotiated rates for 1,000 to 10,000-employee organizations at $9.50 to $12.80.
Advisor-assisted negotiation typically lands 20 to 40 percent below list through multi-year terms, bundling and metric or headcount carve-outs, and the same dataset shows organizations arriving with a credible OpenJDK migration plan achieving 28 to 44 percent reductions.
Read that pairing carefully: the discount is not a reward for volume, it is priced off your demonstrated ability to leave. In our negotiation experience the customer who cannot name a target JDK, a build vendor and a cutover quarter gets list minus a token 10 percent and a three-year lock.
Before you argue rate, argue quantity. The Oracle price list counts every full-time, part-time and temporary employee plus every employee of agents, contractors, outsourcers and consultants who support your internal business operations. It does not count contractors who support something else.
In our audit-defense work the count HR first hands over runs 18 to 28 percent high, mostly separated temps still carried in the HRIS, offshore delivery staff on unrelated client work, and duplicated records across acquired entities.
Then work the band boundaries, because they invert: 9,999 employees at $10.50 lists at $1,259,874 while 10,000 at $8.25 lists at $990,000, a $269,874 swing in your favor for one more person. If your defended count sits just under a boundary, price both sides and make Oracle explain the arithmetic.
| Lever | Arithmetic on a 5,000-employee estate | What it moves |
|---|---|---|
| List, 1,000 to 4,999 band | 5,000 x $10.50 x 12 = $630,000 per year | Baseline, $15,750 per server on 40 servers |
| Strip 22% overcount | 3,900 counted employees, $491,400 | Saves $138,600 before any discount |
| Negotiated rate $9.50 | 3,900 x $9.50 x 12 = $444,600 | Further $46,800, benchmark floor not list |
| Band boundary test at 9,999 vs 10,000 | $1,259,874 vs $990,000 | $269,874, relevant to any group-wide count |
| Entity scoping after partial migration | Modeled at 78% off a group baseline | Largest single lever short of full exit |
Sequence matters: defend the count, then the band, then the rate. Reversing that order concedes the quantity permanently in exchange for a discount Oracle can claw back at renewal.
Two further levers: Oracle's fiscal year-end is May 31, so quarter-four quotes carry the most flex.
And any pre-2023 agreement should be read before Oracle characterizes it as obsolete, because processor or Named User Plus pricing may still be enforceable in it and the average move to the Employee metric ran 340 percent higher across the benchmark dataset.
If you are simultaneously deciding which JDK to land on, price the negotiation against the free options mapped in the 2026 Java version support cliff rather than against Oracle's renewal quote.
Evidence base and the patterns we see repeatedly
The pricing figures come from the Oracle Java SE Universal Subscription global price list and its FAQ, including Oracle's own worked 28,000-employee example at $2,268,000 per year.
Support dates come from the Oracle Lifetime Support Policy for Technology Products and the Java SE Support Roadmap, including the waived Extended Support uplift for Java 8 (March 2022 to December 2030) and Java 11 (October 2023 to January 2032).
License-transition mechanics come from Oracle's own JDK blog posts on the NFTC-to-OTN moves. Third-party lifecycle dates come from HeroDevs and OpenLogic trackers, and negotiated-rate benchmarks from the VendorBenchmark dataset.
One item stays open: reported Corretto 8 end dates conflict across sources, so confirm it in writing with AWS before you commit a migration plan to it.
The HR extract handed to Oracle routinely includes separated temps and non-supporting contractor staff.
VendorBenchmark shows the reduction tracks provable exit capability, not spend volume.
Four patterns account for most of the surprise exposure we find. First, Oracle JDK 8 embedded inside ISV appliances and container base images that no internal team owns, where the ISV's own license does not extend to your production use.
Second, images labeled "OpenJDK 8" that are actually the Red Hat or UBI build, inheriting a November 30, 2026 standard support end rather than the December 2030 date teams assume. Third, headcount pulled straight from the HRIS and submitted without stripping non-supporting contractors.
Fourth, download telemetry from java.com used as the audit trigger, which means a developer's laptop install can start a conversation about your entire employee base.
The common thread is that none of these are pricing problems. They are inventory and attribution problems that only become pricing problems once Oracle opens a file.
Fix the inventory, name the owner of every JDK binary, and confirm each build's real end date in writing before you negotiate anything.
- 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 JDK by vendor and build string within 30 days, not just by major version, because "Java 8" tells you nothing about whether the binary is Oracle OTN, Temurin, Corretto, Zulu, Red Hat or Liberica, and only the build string proves which license you are actually running.
- Classify each install against the free-patch matrix and set November 30, 2026 as your internal deadline, since Red Hat's build of OpenJDK 8 and BellSoft Liberica JDK 8 both end standard support that day, which means any RHEL or UBI base image labeled "OpenJDK 8" has roughly a year of runway before it needs replacing or a paid extension, and the same review should cover the 2026 version support cliff across 11, 17 and 21.
- Standardize Java 8 on Temurin, Zulu or a confirmed Corretto build, all three of which patch through December 31, 2030 at no cost, giving you four more years than Oracle's own Java 11 EOL of September 2026 and removing the subscription question entirely for the largest part of most legacy estates.
- If Oracle has already made contact, defend the employee count and your pre-2023 contract before you discuss rate, stripping temps and non-supporting contractors from a typical 18 to 28 percent overcount, running the band arithmetic at every boundary, and modeling entity-scoping, which benchmarks at 78 percent off a group baseline when only some legal entities still run Oracle binaries.
- If a subscription is genuinely unavoidable, time signature to Oracle's May 31 fiscal year-end with a documented OpenJDK migration plan on the table, because credible migration evidence is what moves organizations into the observed 28 to 44 percent reduction band rather than the 20 percent floor.
Frequently asked questions
Do I need a paid subscription to run Oracle Java 8 in production in 2026?
Yes, if the binary is Oracle's own JDK 8 build. Java 8 public updates ended in January 2019 and Java 8 was never released under the No-Fee Terms and Conditions, so any Oracle JDK 8 update taken after that point requires the Java SE Universal Subscription.
Running an OpenJDK 8 build from Eclipse Temurin, Azul Zulu or Amazon Corretto instead carries no Oracle license obligation.
How much does Oracle Java cost for a 5,000-employee company?
At list, roughly $630,000 per year. The Universal Subscription is priced per total employee, and the 1,000 to 9,999 band sits well above the floor rate, so footprint is irrelevant.
If that company runs Oracle Java on only 40 servers, the effective cost is about $15,750 per server per year, which is why most organizations of that size migrate rather than subscribe.
Who counts as an employee under Oracle's Java metric?
Oracle's price list counts all full-time, part-time and temporary employees of your organization, plus all full-time, part-time and temporary employees of your agents, contractors, outsourcers and consultants who support your internal business operations.
The quantity is determined by headcount, not by the number of people who actually use Java. In practice we see 18 to 28 percent overcounts when HR data is submitted without stripping non-supporting contractors.
When do free Java 8 security updates actually stop?
It depends entirely on which vendor's build you run. Eclipse Temurin, Azul Zulu and Amazon Corretto are documented as supporting Java 8 through December 31, 2030 at no cost, though the Corretto date is disputed in some trackers and should be confirmed with Amazon.
Red Hat's build of OpenJDK 8 and BellSoft Liberica JDK 8 both end included support on November 30, 2026, with paid extensions beyond that.
Is Java 11 in a better or worse position than Java 8?
Worse, in most estates. Oracle Java 11 reaches end of life in September 2026, and on the OpenJDK side Red Hat and BellSoft standard support for OpenJDK 11 already ended on October 31, 2024.
Red Hat's paid ELS-1 phase runs to October 31, 2027 and Temurin 11 runs to at least the same date, so the free runway on 11 is roughly three years shorter than on 8.
Can I just upgrade to Java 25 to stay free instead of paying for 8 or 11?
You can, but understand the window. Oracle JDK 25 updates are planned to remain under the NFTC until October 2028, so the free period is about two years, and the pattern of Java 17 and 21 shows Oracle reverting each LTS release to OTN terms roughly a year after the next-next LTS ships.
Upgrading also means an application-level code and dependency effort that a straight OpenJDK 8 build swap does not, so compare both paths on total engineering cost.
Does having a Java subscription affect my ability to use free NFTC versions?
Yes, and this catches buyers out. The NFTC states that if you currently have a subscription agreement in place for any version of Java, that agreement is in force and the NFTC license cannot be applied.
So a single legacy Java SE subscription can pull otherwise free Java 21 or 25 installs under paid terms, which is a reason to audit and terminate residual subscription agreements deliberately rather than letting them auto-renew.
