Per processor licensing priced Java by the cores running it, adjusted by Oracle's core factor table. For concentrated deployments it was often far cheaper than the per employee metric, and a documented per processor right still matters in 2026.
Per processor Java licensing counted the cores running Java, scaled by the core factor table. Held and documented, it can keep a small server footprint off the employee metric that now counts your whole workforce.
The per processor metric priced Java by the processing power running it rather than by the people using it. You counted the cores in the servers where Java was deployed, multiplied each by a number from Oracle's core factor table, and licensed the result. A deployment concentrated on a handful of servers carried a small processor count, and therefore a small bill, no matter how many people the application ultimately served.
That is the opposite logic to the Universal Subscription, which since January 2023 has counted every full time and part time employee, every contractor, and every temporary worker, regardless of who runs Java. Per processor priced the machine. The employee metric prices the company. For a workload sitting on a few servers, the two numbers can differ by an order of magnitude.
The count was never simply the number of cores. Oracle published a core factor table that assigned a multiplier to each processor type. A common factor was one half, so a server with sixteen cores at a factor of one half licensed as eight processors. Other chips carried different factors. Reading the table correctly was the difference between an accurate count and an overcount, and it remains essential when you value an old per processor entitlement today.
The careful buyer recorded the exact processors, their cores, and the factor applied, because at audit Oracle will recompute the count against current hardware. If you virtualized or moved workloads since purchase, the processor count Oracle asserts may not match what you licensed.
The figures below are indicative and exist to show the shape of the gap, not to predict your result.
| Basis | Counted unit | Indicative count |
|---|---|---|
| Raw cores on Java servers | Physical cores | 16 cores |
| Core factor applied | Cores times factor | 8 processors |
| Universal Subscription | Entire counted population | 12,000 employees |
Eight processors against twelve thousand counted employees is the gap a documented per processor right can defend. The application might serve the whole company, but the legacy metric only ever priced the cores it ran on.
Per processor rewards concentration. The fewer servers Java runs on, the smaller the count. The employee metric does the reverse, because it ignores deployment entirely and prices your headcount. So the estates that benefit most from a legacy per processor position are those that kept Java on a contained server footprint while employing a large workforce. A bank running a Java application on a small cluster, serving thousands of staff, is the textbook case.
The buyer side task is to prove the footprint. Document the servers, the cores, and the factor, and you can show Oracle that the legacy license already covers the deployment. Where new servers fall outside the licensed count, migrate them to a free OpenJDK distribution rather than accepting the employee metric for the whole company.
If you hold perpetual per processor licenses for Java SE, confirm the quantity, the versions covered, and whether support is current. The right to run a licensed version survives a lapse in support, though new updates do not. Then map your current Java servers against the licensed processor count and the core factor table. You may find you are covered, short, or holding headroom. For how these older positions hold up under the intensified 2026 audits, see our explainer on Named User Plus Java licenses and our guide to migrating off a legacy Java metric.
Virtualization is where per processor counts most often go wrong, in both directions. Oracle distinguishes between hard partitioning, which it accepts as a way to limit the cores that must be licensed, and soft partitioning, which it generally does not. If Java runs on a virtual machine inside an environment Oracle treats as soft partitioned, Oracle has historically argued that every physical core in the underlying cluster must be counted, not just the cores allocated to the virtual machine. A deployment that looks like four cores on paper can attract a claim for an entire host or cluster.
The buyer side response is to know which partitioning approach governs each deployment and to document it. Where you rely on a method Oracle accepts as hard partitioning, keep the evidence that the boundary is real and enforced. Where you cannot, assume the larger count and either contain the deployment on dedicated hardware or migrate it to a free OpenJDK distribution. The worst outcome is discovering at audit that a workload you counted as a few cores is being claimed as a full cluster.
Beyond virtualization, two disputes recur. The first is hardware that changed since purchase. If you refreshed servers, consolidated, or moved Java to different machines, the processor count Oracle asserts today may differ from what you originally licensed. Keeping a record of the licensed footprint and how it has changed lets you answer the question rather than concede it. The second dispute is the core factor itself. Oracle recomputes the count using the factor for the processors in place at audit, and a buyer who recorded an old factor may be surprised by a new one. Confirming the current factor for your actual chips is part of valuing the position.
In every case the defense is the same. Document the servers, the cores, the partitioning method, and the factor, and you can hold the count to the deployment you actually run. Leave any of those undocumented and the count drifts toward Oracle's preferred number.
A legacy per processor position is most valuable when Java runs on a small, stable, contained footprint while the organization employs a large workforce. Picture an insurer running a core Java application on a modest cluster behind a clear partition, serving thousands of staff and customers. The per processor count prices the cluster. The employee metric would price the entire company. For deployments like this, the buyer side goal is to keep the footprint contained and documented, license the cores that run Java, and refuse to let a deployment based reality be repriced on a headcount basis.
Cloud deployments add a wrinkle to a per processor position, because the count depends on the virtual cores you run and how the agreement treats authorized cloud environments. A workload that was a tidy processor count on premises can become harder to reason about once it runs on elastic infrastructure that scales cores up and down. The buyer side task is to fix and document the cloud footprint that runs Oracle Java, so the count reflects a defined allocation rather than the maximum the platform could ever provision.
Where the cloud footprint is variable or hard to bound, the cleaner answer is often to migrate those workloads to a free OpenJDK distribution and keep the per processor license pointed at a stable, contained set of cores. A legacy per processor right is most valuable when the cores it covers are predictable. Elastic, undocumented scaling is exactly the condition that lets a count drift upward, so containment and evidence matter even more in the cloud than they do on premises.
Per processor prices the machine, not the payroll. Document the footprint and the core factor, cover the licensed servers, and migrate anything outside the count rather than letting it pull you onto the employee metric.
Per processor licensing remains relevant in 2026 because it values Java by deployment, which is almost always smaller than your headcount. Read the core factor table carefully, evidence the footprint, and you can keep a concentrated deployment off the employee metric. For the full picture of how the metric and the audit fit together, read our Oracle Java licensing guide for 2026.
Download our Oracle Java licensing guide for 2026 to map old entitlements against the employee metric before your next audit or renewal.
Download the guideFixed fee or gainshare, both backed by our guarantee. We sit between you and Oracle and we never take vendor money.
Get a QuoteWeekly intelligence on Oracle Java licensing moves and the buyer side defenses that work.