Only a small set of workloads truly require Oracle Java, usually because a vendor certifies nothing else or the application uses a commercial only feature. Naming that residual precisely is what lets you move everything else to a free OpenJDK distribution and license the remainder narrowly.
Why the residual matters so much
Under the per employee Universal Subscription that Oracle introduced in January 2023, the price is driven by your counted population, not by how many machines run Oracle Java. So the financial goal is not to keep Oracle Java off every server. It is to shrink the set of workloads that force you to carry a subscription at all, then negotiate that residual against the smallest possible employee envelope. Identifying what genuinely requires Oracle Java is the other half of deciding which workloads can move to OpenJDK today. For the full method, see the OpenJDK migration playbook pillar.
The genuine reasons a workload stays
In practice a workload stays on Oracle Java for one of a few concrete reasons, not a vague preference:
- A third party application is certified only on Oracle Java SE, and the vendor will withhold support on anything else.
- The application depends on a commercial only feature that the free OpenJDK build you are evaluating does not include.
- A regulated or contractual requirement names Oracle Java specifically and cannot be varied in the relevant timeframe.
- An old application is pinned to a legacy Oracle Java version with no tested path forward yet.
Each of these is a real constraint you can document. Anything outside this list is usually habit, and habit is not a licensing requirement.
Test the claim before you accept it
Vendors and internal teams often say a workload needs Oracle Java when what they mean is that nobody has tested the alternative. Ask for the certification statement in writing. Ask which exact feature is in use. Ask whether a current vendor release supports OpenJDK even if an older one did not. Many supposed dependencies dissolve on contact with these three questions, which moves the workload back into the today pile.
A residual decision table
| Situation | Requires Oracle Java? | Action |
|---|---|---|
| Vendor certifies only Oracle Java, in writing | Yes, for now | Hold in residual, press vendor for OpenJDK support |
| Commercial only feature in active use | Yes | Hold, or re engineer to remove the dependency |
| Team assumes it is needed, no evidence | No | Test on OpenJDK, then move |
| Legacy version, no tested path | Not proven | Build a test, reassess |
The residual that survives this table is your real Oracle Java requirement. It is almost always far smaller than the estate looks at first glance.
License the residual narrowly
Once the residual is named, the buyer side move is to license it against the smallest defensible employee count and to keep that population isolated and documented. A small, well evidenced residual is a far stronger negotiating position than a vague whole estate subscription, especially with LMS audits intensified in 2026 and running a three year lookback. The difference between the runtimes that drives most of these decisions is set out in OpenJDK versus Oracle Java SE, the real differences.
The buyer side takeaway
A workload truly requires Oracle Java only for a documented reason: a written vendor certification, a commercial only feature in use, a binding requirement, or an untested legacy pin. Test every other claim, move what passes, and license the proven residual against the smallest employee envelope you can defend. Download the field guide below to separate genuine dependencies from habit across your estate.
Download the OpenJDK Migration Field Guide
A buyer side playbook for CIOs, procurement, and general counsel planning a move off Oracle Java. Trade a work email, get the guide and The Java Audit Brief.
Download guide