Oracle has used two fundamentally different ways to charge for Java SE: the legacy processor metric, which counts the hardware Java runs on, and the 2023 employee metric, which counts your entire workforce. The gap between them decides whether your renewal is a routine cost or a budget crisis. This guide compares both, and shows how to model which one is cheaper for you.
The legacy processor and Named User Plus metrics
From 2019 to the end of 2022, Oracle sold the Java SE Subscription on two metrics, depending on where Java ran.
The Processor metric covered server deployments. The count is not simply "number of servers" — it is derived from the number of physical processor cores, multiplied by Oracle's core factor. The core factor is a table value (often 0.5 for common x86 processors) that adjusts the raw core count. Eight physical cores at a 0.5 core factor count as four Oracle processors. The processor metric is the same counting approach Oracle uses for its database products, which is why licensing teams familiar with Oracle Database recognised it immediately.
The Named User Plus (NUP) metric covered desktop deployments. It counts individual authorised users — every person able to run the licensed Java — subject to a per-processor minimum. NUP suited environments where a defined population of users ran Java on workstations.
The defining feature of both metrics: cost scaled with Java usage. Run Java on more servers, pay for more processors. Give Java to more users, pay for more NUP. If you reduced your Java footprint, your bill fell. The metric rewarded efficiency.
The 2023 employee metric
In January 2023 Oracle replaced both metrics with a single one: the Java SE Universal Subscription, priced per Employee for Java SE Universal Subscription.
Oracle's definition of "employee" is deliberately broad. It includes all full-time, part-time and temporary employees, plus the agents, contractors, consultants and outsourcers who support your internal business operations. It does not mean "people who use Java." It means, in effect, the headcount of your organisation.
The defining feature of this metric is the mirror image of the old one: cost is completely decoupled from Java usage. You could run Java on one server or one thousand — the bill is identical, because it is set by how many people you employ. Reducing your Java footprint saves you nothing under the employee metric. Only reducing headcount or leaving Oracle Java entirely changes the number.
| Processor / NUP metric (legacy) | Employee metric (2023+) | |
|---|---|---|
| What is counted | Processor cores × core factor; or named users | Total organisation headcount, incl. contractors |
| Tied to Java usage? | Yes — scales with deployment | No — scales with company size |
| Reduce footprint to save? | Yes | No |
| Best for | Light Java use, large workforce | Heavy Java use, small workforce |
| Available to new buyers? | No — withdrawn | Yes — the only current model |
Which one costs more?
There is no universal answer — it depends entirely on the ratio between your Java footprint and your headcount. Two contrasting examples make the point.
Example A: large workforce, light Java use
A retailer with 12,000 employees runs Java on 20 server processors. Under the legacy processor metric, it licensed 20 processors — a modest five-figure-to-low-six-figure annual cost. Under the employee metric, it now pays for 12,000 employees: well over $1 million a year at list price. For this organisation the employee metric is dramatically more expensive — a multiple of 10x or more.
Example B: small workforce, heavy Java use
A 150-person software firm runs Java intensively across 200 server processors. Under the processor metric it licensed 200 processors — a substantial bill. Under the employee metric it pays for just 150 employees. For this organisation, unusually, the employee metric is cheaper.
The processor metric punished heavy users. The employee metric punishes large organisations. Most enterprises are large organisations with moderate Java use — which is exactly why the 2023 change raised costs so sharply across the board.
For the great majority of enterprises — thousands of employees, Java on a manageable number of servers — the employee metric is far more expensive than the processor model it replaced. That is the structural reason Java licensing became a board-level issue in 2023.
Before any renewal conversation, build both numbers: (1) your processor count — physical cores running Oracle Java, multiplied by the core factor; and (2) your employee count under Oracle's definition. Multiply each by current rates. The ratio tells you your negotiating reality. If the employee metric is many times the processor cost, your strongest move is usually a credible plan to leave Oracle Java entirely — see the Complete 2026 Guide.
If you still hold a legacy processor agreement
The 2023 change did not cancel existing contracts. If you bought a processor or NUP subscription before 2023, it remains valid for its term. The crunch comes at renewal. Oracle generally will not renew legacy-metric Java agreements — it steers customers onto the employee metric.
That makes your renewal a genuine strategic decision, not an administrative one. Your options are broadly:
- Accept the employee metric. Only sensible if your headcount is small relative to your Java footprint, or if migration is genuinely impractical.
- Negotiate hard. Discounts, multi-year price locks and caps are all negotiable — but only with leverage.
- Migrate away. Replace Oracle JDK with free OpenJDK builds and let the subscription lapse entirely. For most enterprises this is the lowest-cost long-term answer.
The third option is also what gives the second option its power. Oracle discounts hardest when the realistic alternative is losing the customer. A documented migration plan is therefore both a cost-reduction measure and your best negotiating instrument — the core of renewal advisory work.
Counting processors correctly (core factors, virtualisation, soft partitioning) and counting employees correctly under Oracle's definition both have traps that swing the numbers significantly. The advisory firm we recommend most highly for this modelling is Redress Compliance — independent of Oracle, not a partner or reseller, with 340+ Java engagements, an average 68% reduction in audit claims, and over $180M saved for clients.
How the core factor actually works
Because the processor metric still governs every legacy Java agreement in its term, it is worth understanding the core factor precisely — it is where processor counts are won and lost.
The raw input is the number of physical processor cores in the servers running Oracle Java. That number is then multiplied by a value from Oracle's Core Factor Table, a published list that assigns a multiplier to each processor family. For most common x86 server processors the factor is 0.5, meaning two physical cores equal one Oracle processor licence. Some processor types carry a factor of 1.0; a few carry lower values.
A worked example: a server with two sockets, each holding a 16-core x86 processor, has 32 physical cores. At a 0.5 core factor that is 16 Oracle processors. Run Oracle Java across ten such servers and the processor count is 160 — before any virtualisation adjustment. The arithmetic is simple, but the inputs are not always obvious: identifying the exact processor model, confirming its core-factor value, and counting only the cores genuinely running Java all require care. Errors here flow straight into the licence count, and Oracle's default is rarely the customer-friendly reading.
Three modelling scenarios
To make the comparison concrete, consider three organisations modelling their renewal.
Scenario one — the large retailer. 12,000 employees; Oracle Java on 40 server processors. Legacy processor cost: a manageable mid-six-figure sum. Employee-metric cost: roughly $1.7M a year at list. The employee metric is more than triple the old cost. The clear strategic answer is migration — there is no version of the employee metric that is competitive here.
Scenario two — the engineering software firm. 220 employees; Oracle Java intensively across 300 server processors. Legacy processor cost: a heavy sum reflecting the deep footprint. Employee-metric cost: based on just 220 people, materially lower. For this unusual organisation the employee metric is genuinely cheaper — though OpenJDK migration still beats both.
Scenario three — the mid-market manufacturer. 3,500 employees; Oracle Java on 24 processors. Legacy cost: modest. Employee-metric cost: well over $600K a year. The employee metric is several times the old figure — the typical enterprise pattern, and the typical reason to leave.
The lesson across all three: the answer is never assumed, always modelled. The footprint-to-headcount ratio is the deciding variable, and it must be calculated with real numbers before any conversation with Oracle.
Negotiation implications
The metric you are moving from shapes the negotiation you can run. An organisation coming off a legacy processor agreement has a concrete, documented prior cost — and a credible claim that the employee metric represents an unjustified multiple for unchanged software. That is a legitimate negotiating lever, particularly when paired with a costed migration plan.
Oracle's standard response is to frame the employee metric as non-negotiable and the price as fixed. Neither is fully true. The per-employee rate, the tier treatment, the contract term, price-lock provisions and renewal caps are all areas where movement is possible — but only for customers who arrive with their own numbers and a genuine alternative. The processor-versus-employee comparison is not an academic exercise; it is the evidence base for the entire negotiation.
- The legacy processor metric counts cores × core factor; the NUP metric counts named users. Both scale with Java usage.
- The 2023 employee metric counts total headcount, including contractors, and is fully decoupled from Java usage.
- For most enterprises — large workforce, moderate Java footprint — the employee metric is far more expensive.
- Reducing your Java footprint saves money under the processor metric but nothing under the employee metric.
- Legacy agreements stay valid for their term; the decision point is renewal, when Oracle pushes the employee model.
- Model both numbers before negotiating — and treat a migration plan as your strongest leverage.