What Named User Plus means for Java
Named User Plus is Oracle's classic user based metric, used across its product lines, and for Java it meant licensing by the count of distinct individuals authorised to access the software rather than by the size of the organisation. Under the pre 2023 Java SE subscription, an enterprise could license only the people who actually used Java, which for a company with a small developer population and a large general workforce was dramatically cheaper than the model that replaced it. This article sits beneath the Oracle Java licensing pillar.
The defining feature of NUP, and the one buyers most often miss, is that it is not a pure user count. It carries per processor minimums, meaning Oracle requires a minimum number of named users for each processor the software runs on, regardless of how few people actually use it. That floor exists to stop customers licensing a handful of users for a heavily deployed system, and it is central to how NUP behaves in practice. The metric sat inside the broader legacy Java SE subscription.
How the NUP count works
Calculating a NUP requirement is a two step exercise. First you count the named users, every individual authorised to use Java, including people and, importantly, non human operated devices where applicable. Then you calculate the per processor minimum by multiplying the licensable processor count by Oracle's required minimum users per processor, and you license the higher of the two numbers. For a lightly used but widely deployed Java estate, the processor minimum, not the user count, usually decides the bill.
Named User Plus rewards narrow, dedicated deployments and punishes Java that is installed everywhere but used by few.
This is why NUP suited some organisations and not others. A bank running Java for a defined team of three hundred users on a contained set of servers could license efficiently. A retailer with Java quietly installed across thousands of point of sale devices faced large processor minimums even if few staff consciously used Java. The processor side of the legacy model is covered in the Java processor licensing guide.
NUP against the employee subscription
The shift from NUP to the employee metric in January 2023 is the single most consequential change in Java licensing history, because it severed price from usage. NUP scaled with how many people used Java; the Universal Subscription scales with how many people you employ. For most enterprises that change increased the licensable quantity enormously, because the whole workforce is always larger than the Java user population.
| Dimension | Named User Plus | Employee subscription |
|---|---|---|
| Counts | Authorised Java users | Total workforce |
| Minimums | Per processor floor | None, headcount only |
| Favours | Narrow, dedicated use | Nothing for the buyer |
| Availability | Legacy, closed to new buyers | Current default |
| Optimisable | Yes, by limiting users | No |
The comparison explains why retaining a NUP agreement, where still possible, can be worth significant effort for organisations whose Java user population is far smaller than their headcount. The full cost contrast is in the Java pricing guide and the workforce mechanics in the employee metric guide.
Where NUP still applies
Oracle closed the legacy Java SE subscription to new customers when it launched the employee model, but it did not instantly void existing agreements. Organisations holding a legacy NUP based Java subscription have in many cases been able to renew on the old metric for a period, though Oracle applies steady pressure to migrate them to the workforce model at each renewal. Whether a given customer can hold its NUP position depends on the exact wording of its agreement and its negotiating leverage.
This makes the legacy NUP agreement a genuine asset to be defended rather than a relic to be surrendered. For a low usage, high headcount organisation, the difference between renewing on NUP and converting to the employee subscription can be a multiple of the annual cost. Preserving that position requires understanding both the contract and Oracle's renewal tactics, which is core to our Java advisory service and broader audit defence work.
Can I keep my Java Named User Plus licence?
Possibly, but it depends on your contract and your leverage. Oracle no longer sells the legacy Named User Plus Java subscription to new customers, and it actively encourages existing customers to convert to the employee model. Some organisations have nonetheless renewed on the legacy metric, particularly where the contract supports it and the customer negotiates firmly.
Whether keeping NUP is worthwhile is a separate question from whether it is possible. For an organisation whose Java user count is far below its headcount, retaining NUP can save a large multiple over the employee subscription, making the negotiation effort clearly worthwhile. For others, the gap is smaller and migration to a free OpenJDK build may beat both metrics. Establish your numbers under each model before deciding, using the employee metric guide.
How per processor minimums really behave
The per processor minimum is the part of Named User Plus that most often surprises buyers, and it rewards a close look. Oracle requires a minimum number of named users for each licensable processor, so the licensable quantity is never simply the count of people who use Java; it is the higher of the actual user count and the processor driven floor. On a deployment with many cores but few users, the floor dominates, and the organisation pays for a notional user population it does not have.
This behaviour shapes which deployments suit NUP. A system with a small, dedicated user base running on modest hardware licenses efficiently, because the actual user count exceeds or approaches the floor. A system running on large, many core servers but used by only a handful of people licenses poorly, because the floor inflates the requirement far above real usage. Understanding this is the difference between assuming NUP is cheap and knowing whether it is cheap for your specific estate.
Because the floor is driven by processors, the same core counting and core factor mechanics that govern the per processor metric also feed the NUP calculation, including the virtualisation exposure on VMware. A NUP position that looks efficient on dedicated hardware can deteriorate if the underlying processor count expands under soft partitioning rules.
Defending a NUP position at renewal
For organisations holding a legacy NUP agreement, the decisive moments are renewals, because each one is an opportunity for Oracle to convert the customer to the employee model. The conversion is usually framed as simplification or as the only forward looking option, and an unprepared customer can accept it without realising it may multiply the annual cost. Defending the NUP position means treating the renewal as a negotiation in which retaining the existing metric is an explicit objective, not a default that survives by inertia.
Preparation is what makes the defence credible. The customer that arrives at renewal with a precise, documented user count and processor calculation, a clear reading of what its contract permits, and a quantified comparison against the employee subscription is negotiating from evidence. The customer that arrives without those things is reacting to Oracle's framing and is far more likely to be moved onto the more expensive metric.
The leverage is strongest when the customer has a genuine alternative, namely the option to migrate to a free OpenJDK build and leave Oracle Java behind entirely. A NUP renewal negotiated against the credible threat of departure is a very different conversation from one in which the customer feels trapped. That alternative is the foundation of every strong position, and building it is central to our Java advisory and audit defence work.
Keep NUP, convert, or leave Oracle Java
The strategic decision for a NUP holder reduces to three options, and the right one depends on the numbers rather than on Oracle's preference. The first option is to retain NUP where the contract allows and the metric is favourable, which suits a large organisation with contained, dedicated Java usage whose user count and processor floor are both modest relative to its headcount. For this profile, NUP can be a fraction of the employee subscription, and defending it is clearly worthwhile.
The second option is to convert to the employee subscription, which makes sense only in narrow cases, for instance where Java has become so pervasive that the user count and processor floors under NUP already approach the workforce based price, removing the saving that justified the effort of staying on the legacy metric. Even then, the third option usually deserves a hard look.
The third option is to leave Oracle Java altogether by migrating to a free OpenJDK build, which removes the metric question entirely and is frequently the lowest cost outcome regardless of which Oracle metric applies. The disciplined approach is to model all three against real numbers before deciding, using the employee metric guide and the pricing guide, and to let the comparison rather than the vendor drive the choice. The migration path is in the migration guide.
Devices, multiplexing, and the hidden user count
A subtlety of Named User Plus that buyers routinely overlook is that the named user definition can extend beyond people to non human operated devices, and that multiplexing does not reduce the count. If a system funnels many users or devices through an intermediary such as a connection pool or a middleware tier, Oracle counts the users and devices behind the intermediary, not the smaller number of direct connections. This anti multiplexing principle is designed precisely to stop architectures from disguising the true user population.
For Java this matters wherever a deployment serves a large or automated population through a contained front end. A system that appears to have a handful of service accounts may, on Oracle's reading, have a named user count equal to every individual and device ultimately driving those accounts. An organisation that estimates its NUP requirement from connection counts rather than from the real population behind them can badly understate its position and be surprised in an audit.
The defensible approach is to enumerate the actual population of humans and qualifying devices that use each Java system, applying the anti multiplexing principle honestly, and then to compare that count against the per processor floor to find the licensable number. Doing this analysis properly, before Oracle does, is what prevents a NUP position from collapsing under scrutiny, and it is a core part of our Java advisory assessment for legacy metric holders.
The buyer side view
The practical takeaway is that Named User Plus is the legacy metric that still matters, because the customers who hold it often hold real value. NUP priced Java on usage, with a processor floor, and for low usage high headcount organisations that is structurally far cheaper than the workforce subscription Oracle now defaults to. Surrendering a NUP agreement without analysis can be an expensive mistake.
If you are on NUP, treat the agreement as an asset, understand the per processor minimums that drive your real cost, and prepare to defend the position at renewal. If you are evaluating options, model NUP, the employee subscription, and an OpenJDK migration side by side before committing. Start with the Java licensing pillar, read the legacy subscription guide, and brief stakeholders with the Java licensing white paper.
Oracle Java Named User Plus: frequently asked questions
What is Oracle Java Named User Plus?
Named User Plus is a legacy Java metric that licenses by the number of individuals authorised to use Java, subject to per processor minimums. It applied under the pre 2023 Java SE subscription before Oracle moved to the workforce based employee model.
Is Named User Plus still available for Java?
Oracle no longer sells the legacy NUP Java subscription to new customers, but some existing customers have renewed on it. Whether you can keep it depends on your contract wording and negotiating leverage.
Is NUP cheaper than the Java employee subscription?
For organisations whose Java user population is much smaller than their total workforce, NUP is often far cheaper, because it prices on usage rather than headcount. The per processor minimum still sets a floor on the cost.