The Java SE employee metric, explained.

In January 2023 Oracle changed how it sells Java — and in doing so, changed the size of the bill for almost every customer. The mechanism is the employee metric: a licensing model that prices Java SE not on how much Java you run, but on how many people your organisation employs. Understanding this single metric is the difference between a predictable cost and an audit shock.

What the employee metric is

The employee metric is the pricing basis of the Oracle Java SE Universal Subscription. Instead of counting servers, processors or named users, Oracle counts your total number of employees and multiplies that figure by a per-employee monthly rate. Every employee is licensed whether or not they ever launch a Java application. A single Java install anywhere in the business triggers a requirement to license the entire workforce.

This is the most important thing to grasp about Java licensing today: the metric is deliberately decoupled from usage. Oracle's reasoning is that Java is so pervasive — in desktops, back-office systems, middleware and embedded tooling — that an organisation-wide count is "simpler". The practical effect is that the cost is driven entirely by HR headcount, a number the IT and procurement teams negotiating the deal often do not even control.

The January 2023 shift

Before 2023, Oracle sold Java SE subscriptions on two familiar metrics inherited from its wider product catalogue: Named User Plus (roughly, per person who can access the software) and Processor (per licensed processor core, adjusted by a core factor). These metrics tied cost to actual deployment. A company running Java on 20 servers paid for 20 servers' worth of processors.

On 23 January 2023 Oracle stopped selling those metrics for Java and launched the Universal Subscription. Existing Named User Plus and Processor subscriptions were allowed to continue for a time, but at renewal Oracle steers customers onto the employee metric. For most organisations the move is not cost-neutral — it is a substantial increase, because headcount is almost always far larger than the Java deployment that the old metrics measured.

How Oracle defines "Employee"

The definition is where the cost really lives, and it is far broader than the everyday meaning of the word. Under the Universal Subscription, the employee count includes:

• All full-time employees, regardless of role or department.
• All part-time employees.
• All temporary employees.
• Agents, contractors, consultants and outsourcers who support the organisation's internal business operations.

In other words, the count is not "people who use Java" and not even "people on the payroll" — it is closer to "everyone who works for you in any capacity, plus the third parties working on your behalf". A retailer with 6,000 store staff who never touch a Java application still counts all 6,000. An organisation that outsources a large part of its IT to a managed-services provider may have to count that provider's relevant staff too. This definition is the single biggest reason employee-metric quotes come in three to ten times higher than customers expect.

The pricing tiers

The Universal Subscription is priced per employee per month, on a sliding scale. The band your total employee count falls into sets the rate applied to every employee. The published list pricing is:

Total employees	List price / employee / month
1 – 999	USD 15.00
1,000 – 2,999	USD 12.00
3,000 – 9,999	USD 10.50
10,000 – 19,999	USD 8.25
20,000 – 29,999	USD 6.75
30,000 – 39,999	USD 5.70
40,000 – 49,999	USD 5.25
50,000+	Negotiated with Oracle

These are list prices. Volume discounting is available and the larger the deal, the more room there is to negotiate — but the headline rate still anchors the conversation, and the tier structure means a few hundred extra employees can occasionally pull a whole organisation into a lower per-employee band.

Why the bill is so large: a worked example

Consider a mid-sized enterprise with 5,000 employees. Only an estimated 150 of them — developers, a handful of analysts, some back-office users — ever run a Java application. The technical footprint is modest: perhaps 60 servers and a few hundred desktops.

Under the employee metric, none of that matters. With 5,000 employees the organisation sits in the 3,000–9,999 band at USD 10.50 per employee per month:

• 5,000 employees × USD 10.50 = USD 52,500 per month
• × 12 = USD 630,000 per year

That is USD 630,000 annually to license Java for an organisation where 150 people actually use it — an effective cost of roughly USD 4,200 per real Java user. Under the old Processor metric, the same deployment might have cost a fraction of that. This gap, multiplied across a multi-year subscription term, is exactly what makes the employee metric the defining issue in Oracle Java licensing today.

Minimums, true-ups and the all-or-nothing rule

Three contractual features make the metric harder to manage than the headline rate suggests:

• All-or-nothing. You cannot license "just the Java users" or "just the production servers". If the metric applies, it applies to the whole employee count. There is no partial subscription.
• Annual true-up. The employee count is reassessed at renewal. If your headcount has grown, your bill grows with it — even if your Java usage has shrunk or disappeared entirely.
• Headcount, not Java count, drives change. An acquisition, a hiring wave or bringing an outsourced function in-house all raise the bill, while decommissioning Java does not lower it unless you exit the subscription completely.

Employee metric vs the metrics it replaced

Aspect	Old NUP / Processor	Employee metric
Cost driver	Java deployment size	Total organisation headcount
Cost of low Java usage	Low	High — usage is irrelevant
Predictability	Tied to infrastructure	Tied to HR headcount
Effect of growth	Only if Java footprint grows	Every new hire raises the bill
Available to buy new	No — retired Jan 2023	Yes — current model

How to reduce employee-metric exposure

Because the metric is all-or-nothing, the most effective lever is not to negotiate the rate — it is to question whether you need the subscription at all. Proven approaches include:

• Eliminate Oracle JDK entirely. If every Java workload runs a free OpenJDK distribution — Eclipse Temurin, Amazon Corretto and the like — there is no Oracle subscription to buy. This is the only route to a zero-cost Java estate, and it is achievable for the large majority of workloads. See our Java migration service.
• Accurately scope the employee count. Oracle's definition is broad, but it is not infinite. Disputes over who genuinely counts as a supporting "contractor" or "outsourcer" can move the number materially.
• Negotiate the term and discount. Larger commitments unlock deeper discounts and price-lock protection against headcount-driven increases — the focus of our Java negotiation work.
• Time the decision. Renewal is the moment of maximum leverage. Approached early, with a credible migration alternative on the table, it is also the moment to exit.

Across 340-plus Java engagements we have helped clients save more than USD 180 million — much of it by avoiding or escaping the employee metric rather than simply discounting it.

Common employee-count scoping disputes

Because the employee figure drives the entire bill, the exact count is worth real scrutiny. Oracle's definition is broad but it is not unlimited, and several recurring questions can move the number materially:

• Outsourced staff. The definition covers contractors and outsourcers who support your internal operations — but a managed-service provider's staff who are already separately licensed, or who do not support your internal operations, may be arguable.
• Subsidiaries and group structure. Which legal entities fall inside the licensed organisation is a definitional question, not a given. A clearly drawn corporate scope can keep separately-run entities out of the count.
• Seasonal and temporary peaks. The count is taken at a point in time; how a seasonal workforce is treated is worth pinning down explicitly in the contract.
• Recently divested business units. Headcount that has left the organisation should leave the count — but only if the agreement is updated to reflect it.

None of these are loopholes; they are legitimate scoping questions. Getting them right before signing, rather than discovering them at a true-up, is one of the most direct ways to control the cost of the metric.

Frequently asked questions

Does the employee metric count people who never use Java?

Yes. That is the defining feature of the metric — it licenses every employee regardless of whether they ever launch a Java application. Actual usage is not part of the calculation at all.

Can we license only the part of the business that uses Java?

No. The Java SE Universal Subscription is all-or-nothing for the licensed organisation. There is no option to license a single department, a server group, or only the Java users.

How does Oracle verify our employee number?

The count is customer-declared, typically from HR records, but Oracle can and does challenge figures it believes are understated. The breadth of the definition — including contractors and outsourcers — is where most disagreements arise.

Will our Java bill go up if we hire more people?

Yes. The count is reassessed at renewal, so workforce growth raises the bill even if Java usage is flat or falling. An acquisition can change your position substantially.

Is the per-employee price negotiable?

The published tier rates anchor the discussion, but volume discounts are available, particularly on larger commitments. The bigger structural lever, though, is questioning whether you need the subscription at all.

How do we avoid the employee metric completely?

Migrate every Java workload to a free OpenJDK distribution. With no Oracle JDK in production, there is no Universal Subscription to buy and the employee metric never applies.

Conclusion

The employee metric is not a pricing detail — it is the central fact of Oracle Java licensing in 2026. It converts a technical question ("how much Java do we run?") into an organisational one ("how many people do we employ?"), and it does so in a way that almost always favours Oracle's revenue. The organisations that handle it well are the ones that treat it as a strategic decision: measure the true employee count, model the cost honestly, and weigh it against the genuinely free alternative of a supported OpenJDK distribution. Done early, that analysis routinely turns a six- or seven-figure subscription into a number far closer to zero.