Oracle prices Java for the whole payroll, not for the people who run it. This report models the per employee metric at real headcounts, separates the count Oracle quotes from the count you can defend, and shows what an OpenJDK move actually saves.
Oracle prices Java for the whole payroll, not for the people who run it. This report reads the per employee metric at real headcounts, separates the count Oracle quotes from the count a buyer can defend, and models what an OpenJDK move actually saves.
This report blends two sources. The first is Oracle's published Java SE Universal Subscription list schedule and Oracle's own licensing documents. The second is the Redress Compliance advisory engagement file for 2024 to 2025.
Every number here is a defensible band, not a single point. Real estates vary by headcount, tier, and how much Oracle JDK is genuinely in use. Treat the bands as a planning range and size your own estate before you respond to any quote.
We update the bands as Oracle revises its schedule and as our engagement data grows. Treat this report as a current read, not a fixed table, and confirm the live Oracle list before you model a specific deal.
At list, the Oracle Java SE Universal Subscription costs more as your headcount rises, because the meter is the headcount. A 1,000 staff employer pays roughly into six figures a year. A 25,000 staff employer pays into seven figures.
The per employee rate falls as you move up the volume tiers, but total spend still climbs steeply, because the rate falls slower than the headcount rises. Volume tiering softens the curve. It does not flatten it.
These are list figures before any negotiated discount. The point is the shape, not the cent. The bill tracks the size of the workforce, even though only part of that workforce ever touches Oracle Java.
The subscription does bundle support and updates for all covered Java SE use, which Oracle presents as the value. The catch is that the value is priced against everyone, not against the workloads that use it. You pay for breadth you did not ask for.
Read the table below as planning ranges. The per employee rate sits at the published tier for that band. The annual figure is the rate times twelve times the headcount, before discount.
Oracle Java SE Universal Subscription, list cost by headcount (planning ranges)
| Headcount band | List rate per employee per month | Annual list cost | What usually runs Oracle Java |
|---|---|---|---|
| 1,000 staff | about 12 dollars | about 0.14 million dollars | 10 to 30 percent of servers |
| 5,000 staff | about 10.50 dollars | about 0.63 million dollars | 10 to 30 percent of servers |
| 25,000 staff | about 6.75 dollars | about 2.0 million dollars | 10 to 30 percent of servers |
| 50,000 staff plus | negotiated | multiple millions | 10 to 30 percent of servers |
The right hand column is the whole argument. Oracle meters the entire workforce. The work that genuinely needs Oracle Java support usually sits on a small slice of the estate. That gap is where the cost lives, and where the defense lives.
List is the opening position, not the bill. Oracle discounts the Java subscription like everything else, and the discount tends to widen with headcount, term length, and the presence of a credible alternative on the table.
In our engagement file, first quotes for large estates were rarely the final number. A documented count, a multi year prepay, and a visible OpenJDK plan moved the realized rate well below the opening rate. The leverage was the alternative, not the negotiation skill.
The trap is treating a discount as a win. A large discount on a count you should never have agreed to is still an overpayment. Fix the count and the footprint first. Negotiate the rate second.
Oracle's published schedule steps the rate down as the employee band rises. The steps look generous, but because the meter is the whole workforce, the total still climbs with headcount. The table maps the published bands.
Oracle Java SE Universal Subscription, published per employee monthly bands
| Employee band | List rate per employee per month | Where it bites hardest |
|---|---|---|
| 1 to 999 | about 15.00 dollars | Small firms with a single Java workload |
| 1,000 to 2,999 | about 12.00 dollars | Mid market with broad headcount |
| 3,000 to 9,999 | about 10.50 dollars | Large employers, modest Java use |
| 10,000 to 19,999 | about 8.25 dollars | Enterprises with diverse workforces |
| 20,000 to 29,999 | about 6.75 dollars | Global employers, narrow Java footprint |
| 40,000 plus | about 5.25 dollars and below | Headcount dwarfs the Java estate |
Read the bottom band carefully. A rate near five dollars sounds small, until you multiply it by forty thousand people and twelve months. The headline rate falls. The cheque does not.
In January 2023 Oracle replaced the older named user and processor Java metrics with a single employee metric. The new Java SE Universal Subscription counts your employees, not your Java installs.
Oracle's definition of employee is broad. It reaches full time and part time staff, plus temporary workers, agents, contractors, and consultants who support internal operations. One person running one Java application can pull the whole company into the count.
The metric breaks the link between cost and use. Under the old model you paid for the processors or named users running Oracle Java. Under the new model you pay for people who may never open a Java application.
That is why the subscription is expensive by design. It is not a usage meter. It is a headcount meter wearing a software badge. The larger your workforce relative to your Java footprint, the worse the math gets.
This is the single most important thing to understand about the 2023 change. The price did not rise because Oracle Java got better or because you deployed more. It rose because Oracle moved the meter from your servers to your staff.
The chart shows the structural problem. Oracle prices the full bar. Only the gold slice runs Oracle Java. Every employee outside that slice is pure margin for Oracle and pure waste for the buyer.
Oracle Java was effectively free for production use for years. That changed in 2019, when Oracle moved Java SE behind a paid subscription and ended free public updates for commercial use of the older releases.
The 2019 model was still usage based. It priced named users and processors, so the bill tracked the deployment. A buyer with a small Java footprint paid a small fee. The link between cost and use was intact.
In January 2023 Oracle replaced that with the employee metric. The same software now costs a multiple of the old price for many buyers, not because they deployed more, but because the meter switched from installs to people. Understanding this shift is the start of the defense.
Buyers still on a legacy named user or processor agreement should think hard before converting. Oracle pushes the employee model as simpler. For most estates it is simply more expensive, because it widens the base from installs to the entire payroll.
The most common dispute is the count itself. Oracle's opening employee number is almost always higher than the number a buyer can defend, because Oracle reads its definition as broadly as it can.
In our engagement file the quoted count ran 18 to 28 percent above the defensible count. The difference came from contractors counted twice, dormant accounts, acquired entities not yet integrated, and subsidiaries that run no Oracle Java.
Contractors are the sharpest edge of the dispute. Oracle's definition includes contractors and consultants who support internal operations. Buyers often have no clean number for this population, so Oracle's estimate becomes the default.
The defense is evidence. Bring a documented headcount, a clear scope of which entities are in the agreement, and a record of which workers actually support the relevant systems. A number you can source beats a number Oracle assumed.
Assemble the evidence pack before you need it.
Where the quoted count and the defensible count usually diverge
| Count driver | How Oracle tends to read it | The buyer side position |
|---|---|---|
| Contractors and agents | All included, estimated high | Only those supporting in scope systems, documented |
| Acquired entities | Folded in at once | Excluded until contractually in scope |
| Dormant or duplicate accounts | Counted as headcount | Removed against an HR system of record |
| Subsidiaries with no Oracle Java | Swept into the org count | Carved out where the agreement allows |
Each line is a few percentage points. Together they are the 18 to 28 percent gap. Closing it before you respond to a quote is the single highest return hour in the whole exercise.
Corporate change drives the second wave of count disputes. An acquisition can double a headcount overnight, and Oracle will fold the new entity into the count at the next true up if the contract language allows it.
Divestitures cut the other way. When you sell a business unit, the employees should leave the count, but the reduction is not automatic. You have to assert it, with evidence, against a vendor that has no incentive to lower the meter.
The protection is in the contract scope. Define which legal entities the agreement covers, set how acquisitions and disposals are treated, and fix the date the count is measured. Without that language, every corporate event becomes a negotiation Oracle starts ahead.
Get this language into the agreement at signing, not at renewal. Once the contract is silent on corporate change, every acquisition becomes Oracle's argument and every disposal becomes your uphill claim.
The usual trigger is a download record. Oracle can see downloads of Oracle JDK tied to a company domain, and a download of a release that needs a subscription is enough to start a conversation. A lapsed legacy subscription is another trigger.
The first contact is rarely a formal audit. It is soft outreach from Oracle's Software Investment Advisor function asking about your employee count and Java estate. A vague or generous answer invites the formal review.
The defense starts before the letter arrives. Run an internal estate sweep so you know exactly where Oracle JDK is installed and where free OpenJDK builds already run. Surprises in an audit are expensive. Surprises you found first are free.
For the framing on versions and free use, Oracle publishes its support roadmap and the terms that separate free builds from paid ones. Read Oracle's own Java SE support roadmap before you accept any claim about what you owe.
Treat the soft outreach as the start of a commercial process, because it is. The Software Investment Advisor contact is friendly and informal. The data you hand over still becomes the basis for a quote, or for the formal License Management Services review if the soft step stalls.
Control the data flow. Acknowledge promptly, route every request through one owner, and answer with a sourced position rather than a quick estimate. Volunteering an unverified employee number is the most common way buyers hand Oracle the high count.
The difference between the soft and the formal path is leverage. Resolve it at the Software Investment Advisor stage with clean evidence and you rarely see a formal audit. Stumble there and the License Management Services review starts with Oracle already holding your loose numbers.
A short list keeps the response disciplined under pressure.
The estate sweep is the foundation of the whole defense. Until you know where Oracle JDK actually runs, every number you give Oracle is a guess, and guesses favor the vendor. The sweep turns the guess into evidence.
The goal is a clean inventory. Every server, every container image, and every developer machine that carries a Java runtime, tagged by vendor, version, and the application it supports. The split between Oracle JDK and free OpenJDK builds is the key output.
Use the tools you already own. Software asset management agents, configuration databases, and simple scripted scans across the fleet all find Java installs. The point is coverage, not a new product. Most estates can complete a first pass in weeks, not months.
Once the inventory is clean, classify every runtime as keep on Oracle or move to OpenJDK. The keep pile is usually small, a handful of vendor applications that certify against Oracle JDK. Everything else is a migration candidate.
That classification is your negotiating position and your migration plan at once. It tells Oracle exactly how small the residual is, and it tells your own teams exactly what to move and in what order. One artifact, two uses.
Keep the inventory current after the first pass. A sweep that is refreshed each quarter means the next renewal, or the next audit letter, finds you ready rather than scrambling. The standing inventory is the cheapest insurance in the estate.
OpenJDK is the same open source codebase Oracle JDK is built from. For the large majority of enterprise workloads, a free OpenJDK build is a drop in replacement that removes the Oracle subscription entirely.
The reason is simple. Oracle JDK and OpenJDK share the same source for the long term support releases. The differences are branding, a few commercial tools, and the support contract, not the runtime your applications depend on.
Several vendors ship production grade OpenJDK builds at no license cost. Eclipse Temurin is the most widely deployed. Amazon Corretto suits AWS estates. The Microsoft build of OpenJDK fits Azure and Microsoft shops. Azul offers a free build plus a paid support option.
The ranking below reflects which build our clients landed on across the migrations we supported. The right choice usually follows the cloud the estate already runs on, not a feature gap, because the runtimes are functionally equivalent.
The savings are large and fast. In our engagement file, moving the non critical estate to a free build removed 60 to 85 percent of the proposed subscription cost within one renewal cycle. The residual was a small Oracle footprint where Oracle support was genuinely needed.
The migration is mostly process, not engineering. Because the runtimes share a codebase, standard applications run on a free build without code changes. The effort goes into inventory, testing, and change control across the estate.
Start by mapping every Oracle JDK install and the version it runs. Match each to a long term support release of your chosen build, validate the application against it, then roll out through your normal change process. The risk lives in a small number of edge cases, not the bulk.
The edge cases are worth naming. Tools that shipped only with Oracle's commercial JDK, very old releases, and a handful of vendor applications that certify against Oracle JDK specifically need attention. These are the workloads you may keep on a paid Oracle footprint.
Free OpenJDK builds, by best fit and support option
| Distribution | Best fit | Paid support available | Long term support cadence |
|---|---|---|---|
| Eclipse Temurin | Most estates, vendor neutral | Yes, via partners | Tracks the OpenJDK LTS releases |
| Amazon Corretto | AWS heavy estates | Included for AWS users | Tracks the OpenJDK LTS releases |
| Microsoft build of OpenJDK | Azure and Microsoft estates | Via Microsoft support plans | Tracks the OpenJDK LTS releases |
| Azul Zulu | Where a vendor backstop is wanted | Yes, commercial option | Extended support beyond standard |
| Red Hat build of OpenJDK | RHEL estates | Via RHEL subscription | Aligned to the RHEL lifecycle |
Notice the pattern. The build is free in every case. Support is an optional paid add on, not a license fee, and it costs a fraction of the Oracle subscription. You buy support where you want a backstop, not because the runtime requires it.
A few myths slow buyers down. They are worth retiring before they cost a year of overpayment.
Security is the question buyers ask first, and the answer is reassuring. The major free builds ship the same security fixes Oracle does for the long term support releases, on a comparable cadence, because they draw from the same upstream project.
Pick a long term support release, such as the current and prior LTS versions, and you get years of patches without a license fee. Where you want a contractual backstop, a paid support plan from Azul or Red Hat provides it at a fraction of the subscription.
The honest comparison is not free against paid. It is the Oracle subscription against an OpenJDK plan that includes optional support and a one time migration cost. Even on that fair basis, OpenJDK wins clearly for most estates.
The migration is a one time cost, spread across a year. The optional support is a fraction of the Oracle fee. After the first cycle, the recurring cost falls to the support line alone, while the Oracle subscription keeps rising with headcount.
Three year cost shape, 10,000 employee estate (planning ranges)
| Cost line | Oracle subscription | OpenJDK with optional support |
|---|---|---|
| Year one license or subscription | full per employee fee | free build, plus migration project |
| Year one support | included in the fee | optional, a fraction of the fee |
| Years two and three | rises with headcount | support line only, flat |
| Three year direction | up | down after year one |
The shape is the story. Oracle's line points up, because the meter is your growing payroll. The OpenJDK line points down after the migration year, because the build is free and only the optional support recurs.
Model your own estate before you decide, because a small, Java heavy engineering shop can land differently. For most large employers, though, the three year number favors the migration by a wide margin.
Finance teams respond to this shape, because it converts an open ended, rising line into a small, predictable one. That predictability is often worth as much to a chief financial officer as the headline saving itself.
This is the heart of the problem. Oracle Java cost scales with headcount. Real Java use scales with workloads. In a growing company those two lines pull apart, and the gap is money.
When you hire a thousand people in sales, finance, and operations, your Oracle Java bill rises even if not one of them ever runs a Java application. The meter moved. The usage did not.
That is why the subscription gets worse at scale for most buyers. The larger and more diverse the workforce relative to the Java footprint, the more of the bill is pure overpayment. Small, Java heavy engineering shops are the rare exception.
The damage is not even across industries. Sectors with large workforces and modest Java footprints take the worst of it. Retail, logistics, healthcare, and the public sector all employ many people who never touch a Java application.
Technology and financial services sit differently. They are Java heavy, so a larger share of the workforce genuinely uses it, and the metric is less punishing relative to the deployment. Even there, the count usually overstates the true need.
The lesson is the same everywhere. Size the real footprint, then judge the metric against it. A headline rate that looks reasonable for a software company can be ruinous for a hospital network with the same headcount.
Take a 10,000 employee retailer as a worked example. At the list tier, the subscription runs into the high six figures a year. Yet a sweep typically finds Oracle Java on a small set of back office servers, perhaps a few hundred runtimes.
Price the few hundred runtimes the way Oracle prices the workforce and the waste is obvious. The retailer is paying for ten thousand people to support software that a fraction of one percent of them ever touch. That is the metric working exactly as designed.
The same mistakes recur across estates, and each one hands Oracle leverage that is hard to claw back later. Naming them is the cheapest insurance a buyer has.
The first mistake is the most expensive. Oracle's soft outreach is designed to collect a number before you have prepared one. A generous reply, given to be helpful, sets the anchor for everything that follows.
The second is the most common. Buyers negotiate the rate while the count and the footprint are still unknown. They win a discount and lose the deal, because the base was never the right base.
Each mistake has the same root. The buyer engages on Oracle's timeline with Oracle's framing. The fix is to engage first, on your own evidence, with the alternative already costed.
The annual fee is only the visible cost. Three more sit underneath it, and each one tends to surface at the worst moment, usually a renewal or an audit.
The first is the back bill. If Oracle finds unlicensed Oracle Java use during a review, it can seek payment for past use, not just future cover. The exposure is larger than the forward subscription, because it reaches backward.
The second is the true up. As headcount grows, the count grows, and the renewal reflects it. A buyer who signed at one headcount can face a materially higher number at renewal without buying anything new.
The third is lock in. Once Oracle Java is embedded estate wide and the subscription is in place, the cost of staying feels lower than the cost of moving. That inertia is exactly what the metric is designed to produce.
Each hidden cost has a buyer side answer. The estate sweep removes the back bill surprise, because you find the exposure before Oracle does. A capped renewal and a fixed measurement date contain the true up. The OpenJDK plan dissolves the lock in.
Do these before you sign, not after. Every one of them is far cheaper to negotiate when you still hold the alternative than to unwind once the subscription is in place and the estate has settled around it.
Buyers who wait until the renewal to address these find the leverage gone. The time to fix the count, cap the term, and plan the migration is while Oracle still wants your signature.
After the sweep and the migration, most buyers are left with a small Oracle footprint that genuinely needs Oracle support. That residual is what you negotiate, and the smaller envelope changes the conversation entirely.
Lead with the defensible count and the migration evidence. When Oracle can see that the bulk of the estate is moving to OpenJDK, the account team's leverage falls, because the alternative is no longer theoretical. It is in flight.
Four levers carry most of the value. Use them together, because each one reinforces the others, and a buyer who pulls all four lands the smallest realized number.
Residual negotiation levers and what each one does
| Lever | What it does | When to use it |
|---|---|---|
| Defensible count | Cuts the base 18 to 28 percent off the opening number | Before any rate discussion |
| Costed OpenJDK plan | Removes Oracle's leverage on the bulk of the estate | As the headline alternative |
| Capped multi year renewal | Stops the true up at the back end of the term | When committing to a term |
| Co terminus dates | Aligns Java with other Oracle renewals for combined leverage | Where Oracle Database or apps renew nearby |
The closing move is sequencing. Negotiate the count first, the scope second, the rate third, and the term last. Buyers who start with the rate, the way Oracle prefers, give away the count and the scope before they have begun.
The smaller the residual, the weaker Oracle's position, because the account team is negotiating over a fraction of the original estate while your alternative carries the rest. Shrink the base, and the rate follows.
The savings are large because the starting point is so inefficient. When the meter prices the whole payroll and the footprint is small, the gap between what Oracle quotes and what you should pay is most of the bill.
In our engagement file, the combination of a defensible count and an OpenJDK migration removed 60 to 85 percent of the proposed subscription cost within one renewal cycle. The residual was a small Oracle footprint, negotiated against a far smaller envelope.
Where the savings come from (planning ranges)
| Lever | Typical effect on the proposed cost |
|---|---|
| Defensible employee count | cuts the base 18 to 28 percent |
| Migrate non critical workloads to OpenJDK | removes 60 to 85 percent of the subscription |
| Capped multi year renewal | protects the next cycle from the true up |
| Coordinated Oracle estate timing | adds leverage on the residual rate |
The levers stack. The count reduction shrinks the base. The migration removes most of what remains. The cap and the coordination protect the small residual. Used together, they turn a seven figure quote into a modest, defensible spend.
The work is not exotic. It is a sweep, a count, a migration plan, and disciplined sequencing. The return on that work is among the highest in the entire software estate, because the metric overcharges so heavily at the start.
Put plainly, the savings are not a negotiation trick. They are the difference between paying for the software you run and paying for everyone you employ. Closing that gap is the whole job.
Java rarely travels alone. Most buyers facing a Java review also carry Oracle Database, options and packs, and sometimes a ULA or an applications footprint. Oracle's account teams see the whole estate, and so should you.
The connection matters because leverage pools. A Java negotiation that ignores a nearby Database renewal or a ULA decision leaves value on the table. Aligned renewal dates turn separate conversations into one, where your combined spend carries weight.
The audit motion is also shared. The same Software Investment Advisor and License Management Services functions that probe Java probe Database and options. A weak position in one area invites pressure across the others.
The buyer side move is to run Java inside an estate wide plan, not as a standalone fire. For the full picture, the Oracle knowledge hub and the Oracle Java licensing pillar map how the pieces connect.
The standard reseller pitch is that the Universal Subscription is the safe choice because it covers everything. We disagree. In most enterprise estates we have modeled, the per employee subscription is the most expensive answer, because it prices the whole workforce for software a fraction of staff use. The buyer side move is an estate sweep first, isolate Oracle Java to the workloads that genuinely need Oracle support, migrate the rest to a free OpenJDK distribution, and only then negotiate the residual against a far smaller employee envelope. Coverage you do not need is not safety. It is spend.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
Oracle prices Java for the whole payroll. The buyer who isolates it to the servers that need it, and migrates the rest, pays for the software they actually run.
Oracle Java SE Universal Subscription lists at roughly 15 dollars per employee per month at the lowest volume tier, falling toward 6 to 7 dollars at high headcounts. The rate is per employee across the whole organization, so a 25,000 staff employer pays into seven figures a year at list before any discount.
Oracle counts full time and part time staff plus temporary workers, agents, contractors, and consultants who support internal operations. The definition is deliberately broad, so the count usually exceeds badged headcount. One Java workload can pull the entire organization into the meter, which is what makes the metric so expensive.
Yes, Oracle's definition includes contractors and consultants who support internal business operations. This is the most common count dispute, because few buyers have a clean contractor number. The defense is a documented, sourced figure that limits the count to workers genuinely in scope rather than Oracle's broad estimate.
The usual trigger is a download record showing Oracle JDK pulls of versions that require a paid subscription, tied to your company domain. A lapsed legacy subscription or a revealing support ticket can also start it. The first contact is normally soft Software Investment Advisor outreach, not a formal audit letter.
Yes, OpenJDK is the same open source codebase Oracle JDK is built from, and free production builds exist from Eclipse Temurin, Amazon Corretto, Microsoft, Azul, and Red Hat. For the large majority of enterprise workloads it is a drop in replacement that removes the Oracle subscription entirely.
In our engagement file, moving the non critical estate to a free OpenJDK build removed 60 to 85 percent of the proposed subscription cost within one renewal cycle. The residual is the small Oracle footprint where Oracle support is genuinely required, negotiated against a much smaller employee envelope.
For most enterprises, neither in full. The buyer side move is to isolate Oracle Java to the workloads that truly need Oracle support, migrate the rest to a free OpenJDK build, and negotiate only the residual. Taking the full subscription prices your whole workforce for software a fraction of staff use.
Bring evidence, not estimates. Source the headcount from an HR system of record, document which entities are in scope, exclude unintegrated acquisitions, and limit contractors to those supporting in scope systems. A sourced count typically lands 18 to 28 percent below Oracle's opening number.
Plan for 9 to 14 months for a structured enterprise migration, starting with the lowest risk workloads. The runtimes are functionally equivalent, so most of the work is testing, change control, and sequencing rather than code rewriting. Java heavy or heavily customized estates sit at the longer end of the band.
Some uses remain free, such as personal use and certain development and testing under Oracle's terms, and older releases under their original license. Commercial production use of current Oracle JDK releases generally requires the paid subscription. Confirm each case against Oracle's own terms rather than assuming, because the lines are specific.
The per employee tier bands, the employee count dispute checklist, the distribution by distribution migration sequence, and the residual negotiation playbook.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement, finance, and software asset leaders facing an Oracle Java review.
Oracle meters the payroll. Isolate Java to the servers that need it, migrate the rest, and you pay for what you run, not for who you employ.
