Run the methodology with a senior advisor.
A senior Admodum advisor will walk the Java SE methodology through with your CIO, CTO, sourcing or SAM team. Engagements run as fixed fee, contingency or annual retainer.
Twenty-two pages on the 2023 pricing change, the Employee metric reading, the deployment count, the OpenJDK transition case and the BATNA posture at renewal.
In January 2023 Oracle replaced the Java SE Subscription (priced per Named User Plus and per Processor) with the Java SE Universal Subscription (priced per Employee). The change moved Java SE off a deployment-bound metric onto a population-bound metric. For most buyers, the price-per-unit fell. The total bill rose by a multiple.
The commercial logic behind the change is the same logic that drives every metric simplification in enterprise software. A deployment-bound metric requires both parties to count deployment. A population-bound metric requires only one party to assert a headcount. The audit overhead falls. The pricing discipline rises. The publisher reads the change as a commercial improvement; the buyer reads it as an upward step in the cost of running Java in production.
The buyer's first response is often to attempt a deployment-reduction posture. The deployment-reduction posture, under the new metric, does not change the bill. Whether one server runs Java or ten thousand, the buyer is licensed on the Employee count. The only deployment posture that changes the bill is the posture in which Oracle Java is removed entirely.
The metric is defined in the Oracle contract and the published price list. The wording covers four populations and the reading of each matters.
Employees. Full-time, part-time and temporary employees of the legal entity that signs the order. The reading is straightforward and the count is the count the HR system reports.
Agents, contractors and consultants. Workers who are not employees but who, in the normal course of business, support the operation. The reading is the operative source of metric inflation. A contractor who has not touched a Java-enabled system but works for the buying entity is in scope. A consultant from a global systems integrator who works on a project that does not use Java is in scope. The metric is population-bound, not use-bound.
Outsourcers. Where an outsourcer operates a Java-enabled system on behalf of the buyer, the outsourcer's own employees who support that system are in scope. The contractual reading places the burden of metric inclusion on the outsourcer's employee count, not the buyer's.
Where the definition leaves room. The definition does not include third-party customers of the buyer, third-party suppliers of the buyer, or the buyer's parent or subsidiary entities outside the legal entity that signed the order. Each of these categories is a defensible exclusion in the renewal negotiation if the buyer can document the boundary.
Under the old Named User Plus and Processor metric, the deployment count drove the bill. Under the new Employee metric, the deployment count drives the migration. The buyer must know where Oracle Java is deployed in the estate, what version runs and what licensing terms apply to that version.
The deployment inventory runs four passes. The first pass scans every server and every workstation for installed Java binaries. The output is a master inventory keyed to host. The second pass distinguishes the Oracle JDK from the OpenJDK distributions. The Oracle JDK ships from Oracle; OpenJDK ships from Amazon, Microsoft, Eclipse, Red Hat, IBM and others. The bill is bound to the Oracle JDK only.
The third pass distinguishes the version of the Oracle JDK and the licensing terms it carries. Oracle Java SE 8 through 16 are licensed under the Oracle Binary Code License (BCL) for non-production use, with Java SE Subscription required for production use. Java SE 17, 18, 19, 20 and (with restrictions) 21 ship under the No-Fee Terms and Conditions (NFTC), which allows production use at zero cost until a later cut-off. Java SE 22 and onward revert to a paid subscription. The buyer who has standardised on Java SE 17 LTS may, depending on the upgrade timing, be running unlicensed Oracle JDK at zero cost or licensed Oracle JDK at full Employee count.
The fourth pass closes the gap between the deployment view and the support view. The Oracle JDK installed on a server but never run, never patched and never depended on by an application is a deployment that can be removed without operational consequence. The deployment that has been patched, that is on the support roadmap and that an application stack depends on is the deployment that drives the migration decision.
OpenJDK is the upstream open-source project from which Oracle JDK derives. The OpenJDK source is identical to the Oracle JDK source for the LTS versions. The OpenJDK binary distributions are produced by Amazon, Microsoft, Eclipse, Red Hat, Azul, IBM and several others. Each distribution carries its own support model and pricing.
The migration path is straightforward in most application stacks. Java is a write-once-run-anywhere runtime by design, and the bytecode compiled against Oracle JDK runs unmodified against OpenJDK. The operational risk is bound to three categories of dependency. The first is dependency on Oracle JDK-only commercial features (Java Mission Control, Application Class Data Sharing in older versions, certain Oracle GraalVM features), some of which have been open-sourced and some of which have not. The second is dependency on Oracle's support model (rapid security response, deep technical escalation, Oracle account management). The third is dependency on third-party software certifications (some ISVs certify their products on Oracle JDK only; the buyer who runs that ISV on OpenJDK runs uncertified).
The residual Oracle Java SE need is the deployment that, after migration, must remain on Oracle JDK. For most buyers it is zero. For some, it is a small fraction of the estate bound to a single ISV certification or to a Java Mission Control workflow. The Employee metric does not scale to residual deployment; the buyer who runs even one residual Oracle JDK deployment is licensed at the full Employee count.
BATNA, the Best Alternative to a Negotiated Agreement, is the position the buyer takes if the Java SE Universal Subscription renewal does not close. Under the new Employee metric, the BATNA is binary. Either the buyer migrates to OpenJDK and exits the subscription entirely, or the buyer renews at the Employee count.
The renewal-window posture starts twelve to eighteen months before the renewal date. The deployment inventory is built. The OpenJDK migration plan is drafted. The residual Oracle Java SE need (if any) is documented. The cost of the OpenJDK migration (engineering effort, ISV recertification, training, support contract on the OpenJDK distribution) is framed against the cost of the Oracle Java SE renewal.
The buyer presents the renewal posture to Oracle with the OpenJDK migration in flight, not as a threat. The posture changes the negotiation. The publisher reads the OpenJDK migration as the buyer's BATNA and responds with discounts, multi-year price holds, term concessions and (in some cases) employee-count carve-outs against the metric. The buyer who walks into the renewal meeting with no OpenJDK plan walks out with the list-price renewal.
Oracle's audit posture on Java SE has stiffened since the 2023 metric change. Oracle's License Management Services (LMS) team is making a higher volume of Java-specific outreach, often citing public information about the buyer's headcount as the opening Employee count.
The compliance posture starts with the notification response. Acknowledge receipt in writing. Refer the inbound to a named single point of contact (the SAM lead or external counsel, not the IT operations team). Ask for the audit scope, the supporting clause, the evidence Oracle is willing to share and the timeline. Do not respond with deployment data, scripts or inventory until the scope and protocol are agreed in writing.
Scope contestation is the second move. Java SE audit scope, in Oracle's reading, extends across the legal entity. The buyer's scope contestation rests on the contract language at the licensing entity, the corporate structure, the affiliate boundary and the documented separation between legal entities inside the corporate group.
The evidence boundary is the third move. The deployment evidence the buyer shares is the evidence the buyer has tested for accuracy. The deployment evidence the buyer does not share is the evidence Oracle is contractually entitled to compel, which is narrower than Oracle's opening request. The closing letter records the agreed Employee count, the support boundary, the audit moratorium and the residual rights position.
The Java SE paper sits inside the Oracle four-paper reading list. The companion papers extend the methodology to adjacent Oracle commercial mechanics:
The methodology in this paper is the methodology Admodum has applied across forty-one Java SE Universal Subscription renewals and audit responses inside the firm's engagement history. Each engagement is structured as fixed fee, contingency / gainshare or annual retainer, depending on the buyer's posture at the renewal window.
A senior Admodum advisor will walk the Java SE methodology through with your CIO, CTO, sourcing or SAM team. Engagements run as fixed fee, contingency or annual retainer.