Oracle Java Processor Licensing

What processor licensing means for Java

The per processor metric licenses Java according to the computing capacity it runs on, measured in processor cores, rather than according to who uses it or how many people you employ. Under the legacy Java SE subscription, an organisation counted the cores in the servers where Java was deployed, applied Oracle's core factor, and licensed the resulting processor count. The cost was a function of the size of the Java estate, which meant a contained deployment could be licensed economically no matter how large the company. This article sits beneath the Oracle Java licensing pillar.

This is the fundamental contrast with the model that replaced it. Where the employee subscription charges for your whole workforce regardless of deployment, processor licensing charges for your deployment regardless of workforce. For an enterprise running Java on a handful of well defined servers, the per processor model was, and where it survives still is, often far cheaper. The metric lived inside the legacy Java SE subscription.

The core factor and how cores are counted

Processor counting is not a simple tally of physical cores. Oracle applies its core factor table, which assigns a multiplier to each processor type, so the licensable processor count is the physical core count multiplied by the relevant factor. Common x86 cores carry a factor that reduces the count below the raw number, while some other architectures carry higher factors. The same core factor table that governs Database licensing applied to legacy Java, which is why the two were often analysed together.

How a Java processor count is derived
Step	Input	Effect on count
Identify Java servers	All hosts running Oracle JDK	Defines the licensable estate
Count physical cores	Cores per socket and sockets	Raw core total
Apply core factor	Oracle core factor table	Adjusts cores to processors
Account for virtualisation	Soft partitioning rules	Can expand the reachable estate

The virtualisation line is where processor licensing turns dangerous, because Oracle treats VMware as soft partitioning and may count cores across a far wider estate than the customer expects. That interaction is the subject of the Java on VMware guide, and it is the single biggest risk in a legacy per processor position.

Processor against NUP and the employee model

The three Java metrics that have existed sit on a spectrum. Processor licensing ties cost to deployment capacity. Named User Plus ties it to authorised users with a processor floor. The employee subscription ties it to total headcount. Which one is cheapest depends entirely on the shape of the organisation, and the answer differs sharply between a small company running Java widely and a large company running it narrowly.

Processor licensing punishes sprawling deployments and rewards contained ones. The employee model does the opposite, ignoring deployment entirely.

For a large enterprise with a contained Java footprint, the per processor model can be a fraction of the employee subscription cost, which is precisely why Oracle retired it for new sales and pushes existing customers to convert. The full three way comparison is in the Java pricing guide.

Where processor licensing still applies

Like the Named User Plus metric, per processor Java licensing is closed to new customers but persists in existing agreements. Customers who held a per processor Java SE subscription before the 2023 change have in many cases continued to renew on it, subject to Oracle's pressure to migrate. The value of holding that position can be very high for a large, low deployment organisation, making it worth defending carefully at each renewal.

Defending a legacy processor agreement requires two things: a precise, current understanding of your licensable core count, including the virtualisation exposure, and a clear reading of what your contract permits at renewal. Both are areas where Oracle's account teams hold an information advantage that the customer must close. This is core to our Java advisory service and our Oracle audit defence work.

Is processor licensing cheaper than the employee model?

For organisations with a contained Java deployment and a large workforce, yes, often dramatically. Because the per processor metric prices on the cores Java runs on rather than on headcount, a company running Java on a small number of servers can license it for far less than the employee subscription would cost across its entire staff. The saving grows with the gap between deployment size and workforce size.

The qualification is virtualisation. A per processor position that looks cheap on dedicated hardware can become expensive if Java sits in a VMware estate that Oracle counts broadly under soft partitioning rules. Before assuming the legacy metric is cheaper, establish your true licensable core count including that exposure, and compare it against your employee based cost and the zero cost of an OpenJDK migration.

Reading the core factor table correctly

The core factor table is deceptively simple and easy to misread, which makes it a frequent source of both undercounting by customers and overcounting by Oracle. Each processor type is assigned a factor, and the licensable processor count is the total physical cores multiplied by that factor. Common server class x86 cores carry a factor that reduces the count below the raw core total, while certain other architectures carry factors at or above one. Using the wrong factor, or applying it to the wrong core count, produces a materially wrong licensing position.

Two errors recur. The first is counting logical processors or threads rather than physical cores, which inflates the count, since the table operates on physical cores. The second is failing to apply the correct factor for the specific processor model, which can either understate or overstate the requirement depending on the direction of the mistake. Both are avoidable with an accurate hardware inventory and careful reference to the current table.

Because the same table governs Oracle Database licensing, organisations with both products often analyse them together, and the discipline developed for one transfers to the other. Getting the core factor right is foundational, because every downstream number in a legacy Java position depends on it. The interaction with virtualisation, where the reachable core count itself is contested, is covered in the Java on VMware guide.

Hard partitioning and legitimate containment

While Oracle rejects VMware as a way to limit licensing, it does accept certain technologies as hard partitioning, and for legacy per processor customers these remain the legitimate route to containment. Oracle approved hard partitioning methods physically or contractually bind software to a defined subset of cores in a way Oracle recognises, allowing the customer to license only those cores rather than the whole machine. The accepted methods are specific and documented, and deviating from them forfeits the benefit.

The practical value of hard partitioning is that it lets an organisation run Java on a large physical server while licensing only a contained slice, which can dramatically reduce a per processor requirement. The constraint is that the partitioning must be implemented exactly as Oracle specifies, with no configuration that would allow the software to exceed its bounded cores, because any such possibility lets Oracle argue the full machine is licensable.

For organisations weighing whether to defend a legacy processor position, the availability of genuine hard partitioning can be the difference between a manageable and an unmanageable cost. Establishing whether the estate uses an accepted method, and whether it is configured compliantly, is a technical and contractual question that our Java advisory and audit defence work assesses before any position is taken to Oracle.

A strategy for legacy processor agreements

Holding a legacy per processor Java agreement is, for the right organisation, a genuine asset, and the strategy for it has three strands. The first is accurate measurement: a precise, current core count with the correct core factors applied, and an honest assessment of any virtualisation exposure, so the organisation knows its true position rather than a hopeful estimate. Without this, every subsequent decision rests on sand.

The second strand is contractual clarity. The customer needs to know exactly what its agreement permits at renewal, whether it can continue on the per processor metric, and what levers Oracle has to push a conversion. This reading determines how strong the position is and how it should be defended, and it is often where customers discover either more room or more risk than they assumed.

The third strand is the alternative. As with every Oracle Java position, the strongest footing comes from holding a credible option to migrate to a free OpenJDK build, which both caps the downside and strengthens any negotiation. An organisation that can walk away negotiates differently from one that cannot. Modelling the per processor cost against the employee subscription and against a migration, then choosing on the numbers, is the disciplined path, and it is set out further in the Java licensing pillar and the Java licensing white paper.

Disaster recovery, standby, and non production cores

A legacy per processor position is shaped not only by production cores but by the treatment of disaster recovery, standby, and non production environments, which is an area Oracle and customers frequently read differently. Oracle's rules distinguish between standby systems that are truly passive and those that perform any processing, with only narrowly defined failover configurations escaping a full licensing requirement. A warm standby that runs Java for any purpose beyond pure failover can be fully licensable, which can quietly double a position that the customer assumed covered only production.

Non production environments such as development, test, and staging are equally easy to overlook. If they run Oracle JDK, they count, and a sprawling set of lightly governed lower environments can carry a surprising core total. Organisations that licensed only production carefully, while leaving non production uncontrolled, often find that the unmanaged environments are where the largest unlicensed exposure sits.

The discipline, as with the rest of a legacy position, is complete enumeration: every environment running Oracle JDK, production and non production, primary and standby, with the standby treatment assessed against Oracle's specific failover rules rather than assumed. Pairing that with the option to migrate non production to a free OpenJDK build often shrinks the licensable estate substantially. Mapping these environments accurately is foundational to the defence our audit defence team builds around a legacy processor agreement.

The buyer side view

The practical takeaway is that processor licensing is the legacy metric that can save large organisations the most, provided their Java is genuinely contained. It prices deployment, not people, so a big company running Java narrowly pays for the narrow estate rather than the big company. Where that position survives in a contract, it is often worth real effort to keep.

If you hold a per processor agreement, pin down your true core count, quantify your virtualisation exposure honestly, and prepare to defend the metric at renewal rather than drifting into the employee model by default. Model all three metrics and an OpenJDK migration before deciding. Start with the Java licensing pillar, read the Named User Plus guide, and brief leadership with the Java licensing white paper.