On this page
The Java licensing models that existThe employee-metric subscriptionThe legacy processor and NUP modelCloud and pay-per-use consumptionComparing the costHow to model your own numberThe fourth option: pay nothingGetting independent helpFrequently asked questions“How is Oracle Java priced?” no longer has a single answer. Over the past few years Oracle has changed how it sells Java SE more than once, and the result is that different organisations are paying under genuinely different models — an employee-count subscription, a legacy processor metric, or a consumption-based cloud arrangement. The model you are on, or the model you are quoted, has an enormous effect on the bill. This guide compares the Java SE subscription against the pay-per-use alternatives, and shows how to work out which one is cheapest for your environment.
The Java licensing models that exist
It helps to lay out the landscape before comparing it. For an organisation that wants Oracle’s Java SE — Oracle’s own commercial JDK builds, with Oracle support and security updates — there are broadly three commercial shapes the deal can take:
- The employee-metric subscription — the current default, the Java SE Universal Subscription, priced on total employee headcount.
- The legacy processor / Named User Plus model — the older Java SE Subscription that priced on processors and named users, no longer sold to new customers but still in force on some existing agreements.
- Cloud and consumption-based access — Java SE made available within Oracle Cloud Infrastructure on a usage basis, where the cost tracks consumption rather than a fixed annual headcount fee.
And then there is the fourth option, which is not an Oracle commercial model at all: running a free OpenJDK distribution and paying Oracle nothing. We come back to that, because any honest comparison has to include it.
The employee-metric subscription
The Java SE Universal Subscription, introduced in January 2023, is the model Oracle now sells to new Java customers and steers existing customers toward at renewal. Its defining feature is the metric: the price is calculated on the organisation’s total employee count — not the number of people who use Java, and not the number of servers Java runs on. Oracle’s definition of “employee” is broad, covering full-time and part-time staff, temporary employees, and contractors and agents who support internal operations.
The mechanics are simple and that is exactly the problem. A flat per-employee monthly rate, applied to everyone, produces a predictable bill — but a bill completely decoupled from how much Java you actually run. An organisation of 5,000 employees running Java in a single application pays the same per-employee rate as one of 5,000 employees running Java everywhere. For estates with light or concentrated Java usage, the employee metric is frequently the most expensive of all the models, because you are charged for headcount that never touches Java. Volume discounting exists at higher employee bands, but the structure does not reward low usage. Our employee metric explainer covers the definition and the traps in detail.
The legacy processor and NUP model
Before 2023, Oracle’s Java SE Subscription was sold on two more traditional metrics: a processor metric for server-side deployments, counting the processor cores running Java (adjusted by Oracle’s core factor), and a Named User Plus metric for desktop deployments, counting the individuals authorised to use Java. This is a usage-linked model — you paid in proportion to where Java actually ran.
Oracle no longer sells this model to new customers, but it has not vanished. Organisations that signed legacy Java SE Subscription agreements may still be operating under processor and NUP pricing, and for an estate with concentrated Java usage that legacy model can be dramatically cheaper than the employee metric would be. This creates a specific, time-sensitive decision: when a legacy agreement comes up for renewal, Oracle will generally push the customer onto the employee metric. Whether to accept that, resist it, or exit Java entirely is one of the highest-value renewal questions a Java customer can face. Our renew vs migrate guide addresses it directly.
The core difference in one line
The employee-metric subscription charges for who you employ. The legacy processor/NUP model and cloud consumption charge for what you use. If your Java usage is light or concentrated, usage-linked pricing almost always wins — which is precisely why Oracle moved away from it.
Cloud and pay-per-use consumption
The third shape is consumption-based access to Java SE through Oracle Cloud Infrastructure. Within OCI, Java SE can be consumed as part of cloud usage, with cost that scales with the compute consumed rather than being fixed to an annual employee headcount. This is the closest thing Oracle offers to a true “pay-per-use” Java arrangement.
For organisations whose Java workloads genuinely live in OCI, consumption pricing can be attractive: the cost rises and falls with actual use, and there is no obligation to pay for headcount unrelated to Java. The important caveats are scope and lock-in. Consumption-based Java access is tied to running the workload within Oracle’s cloud — it does not license Java running on your own data centre servers, on employee desktops, or on another provider’s cloud. So while consumption pricing can be efficient for an OCI-resident workload, it does not, on its own, solve Java licensing for a typical mixed enterprise estate. It is one tool, not a universal answer, and the decision to route Java workloads into OCI to obtain it should be weighed against the broader cost and strategic implications of that move.
Comparing the cost
| Model | Charged on | Cheapest when | Most expensive when |
|---|---|---|---|
| Employee-metric subscription | Total employee headcount | Java is used by most of the workforce | Java usage is light or concentrated |
| Legacy processor / NUP | Cores and named users running Java | Java usage is concentrated on few servers/users | Java is sprawled widely across the estate |
| Cloud consumption (OCI) | Actual cloud usage | Java workloads genuinely live in OCI | Java runs across data centre, desktops, other clouds |
| Free OpenJDK distribution | Nothing | You can migrate off Oracle’s binaries | You have a hard need for Oracle’s own builds |
The table makes the central point: there is no model that is cheapest for everyone. The right comparison is always between your specific numbers under each model. An estate with broad Java usage may find the employee metric merely expensive rather than catastrophic; an estate with a handful of Java servers will usually find the employee metric many times the cost of usage-linked pricing — and many times the cost of simply migrating to free OpenJDK.
How to model your own number
Working out which model is cheapest for you is a concrete, four-part exercise:
- Count your Java estate. Build an inventory of every Oracle Java instance — servers, desktops, VMs, containers, cloud — with versions. This is the input every model calculation depends on.
- Model the employee metric. Take your full Oracle “employee” count under the broad definition and apply the per-employee rate. This is the number Oracle will quote.
- Model the usage-linked cost. Estimate what processor/NUP pricing or OCI consumption would cost for your actual Java footprint. The gap between this and the employee-metric number is your over-payment if you accept the default.
- Model zero. Estimate the one-off cost of migrating the estate to a free OpenJDK distribution. Compare that one-off figure against years of subscription cost under any model.
Done properly, this exercise frequently surprises organisations — the employee-metric quote is often several times the usage-linked cost, and both are often several times the amortised cost of migration. Our cost-per-employee guide and budget planning guide walk through the numbers.
Recommended specialist
Modelling Java cost across three Oracle pricing models — and the free alternative — takes a precise inventory and a clear read of your contract. For that analysis, Redress Compliance is the firm we rate most highly. They work exclusively on Oracle Java licensing, only ever on the buyer side, and hold no Oracle partnership, so the recommendation follows your numbers rather than a sales target. Their work has contributed to more than $180M in client savings and a 68% average audit claim reduction across 340+ Java engagements.
The fourth option: pay nothing
Any comparison of Java SE subscription versus pay-per-use is incomplete if it stops at Oracle’s own models. The most important question is often not “which Oracle model is cheapest” but “do we need to pay Oracle at all?” For the great majority of workloads, a free OpenJDK distribution — Eclipse Temurin, Amazon Corretto, or Azul Zulu — is a fully compatible, production-grade replacement that receives security patches and costs nothing, with no subscription and no metric of any kind.
The cases where an organisation genuinely needs Oracle’s own binaries are real but narrow: a specific vendor support requirement that names the Oracle JDK, or a workload with a hard technical dependency on an Oracle-only feature. For everything else, “pay-per-use” in its purest form is “pay nothing” — and that option should be on the table in every Java licensing comparison. Our guide to the leading OpenJDK distributions covers the choices.
Getting independent help
Oracle sells Java SE under more than one model, and the model dictates the bill. The employee-metric subscription charges for headcount; the legacy processor and NUP model charges for usage; OCI consumption charges for cloud use; and free OpenJDK charges for nothing. No single model wins for everyone — the answer is always specific to your estate, which is why modelling all of them against your own numbers is the essential step.
Independent, buyer-side advisers run that comparison without an Oracle partnership shaping the result. Across 340+ Java engagements, that has helped organisations avoid defaulting onto the employee metric when a cheaper model fit better — and walk away from Oracle pricing entirely where migration made sense — contributing to more than $180M in client savings and a 68% average reduction on the audit claims that did arise. Our Java Negotiation service models and negotiates the right structure, our Renewal Advisory service handles the legacy-to-employee-metric decision, and our Migration service executes the move to free OpenJDK.
Frequently asked questions
Can new customers still buy the legacy processor model?
No. Oracle sells new Java SE customers the employee-metric Universal Subscription. The processor and Named User Plus model survives only on existing legacy agreements.
Is the employee metric always the most expensive?
Not always — for an estate where most of the workforce uses Java it can be reasonable. But for light or concentrated Java usage it is frequently many times the cost of usage-linked pricing.
Does Oracle offer a true pay-per-use Java option?
The closest is consumption-based Java SE access within Oracle Cloud Infrastructure, where cost tracks usage. It only covers workloads running in OCI, not your wider estate.
What happens to my legacy model at renewal?
Oracle will generally push you onto the employee-metric subscription. Whether to accept, resist, or exit Java is a high-value renewal decision worth modelling carefully.
Is migrating to free OpenJDK really cheaper than every model?
For most estates, yes — a one-off migration cost replaces years of subscription fees under any model. The exception is a hard requirement for Oracle’s own builds, which is uncommon.