Whether to certify Java, exit it, or move to a subscription turns on three inputs: the metric your agreement uses, your real Java usage, and the lifetime cost of each path. Model all three before deciding, because the right Java answer is frequently different from the right database answer in the same agreement.
Java is the product where the usual ULA instinct to certify a high count can be wrong. For the database, a larger certified quantity is generally free value, because support stays flat at the ULA level. Java is measured differently, and the economics of certifying it do not always follow the same logic, so the decision deserves its own framework rather than a borrowed one. This is that framework. It is built for a holder approaching exit who needs to decide, deliberately, what to do with the Java in scope. The conclusion will be specific to your usage and your contract, but the structure of the decision is consistent, and following it stops Java being an afterthought in an otherwise careful certification.
It depends on real usage and the contract metric. Certify Java when the certified entitlement on the contract metric covers your ongoing need at an acceptable support cost. Consider exiting when usage is limited, when a supported alternative covers your runtimes, or when the certified metric would lock in more cost than the use justifies. The decision is a comparison of the two outcomes on a common horizon, not a default toward certifying.
Before choosing a path, establish three things. Each is a piece of work, and skipping any of them turns the decision into a guess.
Find out exactly how Java is counted and certified under your contract, because the metric shapes everything. Java is commonly measured on a subscription or employee based basis rather than installed processors, and what you can certify depends on that definition. The counting work behind this input is set out in counting Java deployments at certification, and it is the foundation of the whole decision.
Establish where Java is actually used, by which applications, and whether that use is growing, stable, or declining. A broad but shallow Java footprint behaves differently from a concentrated, critical one. Projected usage matters as much as current usage, because the entitlement or subscription you choose has to serve the future estate, not just today's.
Model the support or subscription cost of certifying Java, of exiting it, and of any alternative, over the same number of years. The path that looks cheapest at the exit moment is not always the cheapest over the horizon, and Java's metric can make a certified entitlement more or less attractive than it first appears. Any figures used in modelling are indicative until your own contract and estate are in the model.
Certify Java. Best when the certified entitlement on the contract metric covers ongoing need at acceptable cost, and Java is strategic and stable. You convert the unlimited right into a defined entitlement and continue support.
Exit Java entirely. Best when usage is limited or replaceable, or when the metric would lock in cost out of proportion to use. You remove Java from the certified scope and address runtimes through a supported alternative. This path is examined in detail in exiting Java entirely versus certifying.
Move to a subscription. Best when ongoing Java use is real but the certified entitlement does not fit it well. You align cost to the current metric rather than a legacy count, accepting an ongoing subscription in place of a certified quantity.
The choice between these is rarely all or nothing. A holder may certify Java for the part of the estate where use is heavy and strategic, while planning to retire or replace Java elsewhere. The framework supports that split, provided each part is decided on its own usage and cost rather than on a single blanket instinct. The full comparison of the first two paths is in exiting Java entirely versus certifying.
Work the inputs in order, then compare the paths. First confirm the metric, because it determines what certifying even means for your Java. Second establish real and projected usage, so the decision serves the actual estate. Third model the lifetime cost of each path on a common horizon. Only then choose, and document why, so the decision can be defended and revisited if usage changes. The wider Java context that surrounds this framework is set out in the Java ULA explained.
The Java ULA decision is a deliberate comparison, not a default. Confirm the metric, establish real usage, model the lifetime cost of certifying, exiting, and subscribing, then choose the path each part of the estate justifies. Start with the counting work in counting Java deployments at certification, weigh the alternatives in exiting Java entirely versus certifying, and frame the exit through our ULA exit strategy guide. Because the right answer turns on your metric, your usage, and your costs, the decision should be made on a model built from your own agreement.
It depends on real usage and the contract metric. Certify Java when the certified entitlement on the contract metric covers your ongoing need at acceptable support cost. Consider exiting when usage is limited, when a supported alternative covers your runtimes, or when the certified metric would lock in more cost than the use justifies.
Three inputs drive it: the metric your agreement uses to count and certify Java, your real and projected Java usage, and the lifetime support cost of each path. Model all three before deciding, because the right Java answer is frequently different from the right database answer in the same agreement.
We confirm your Java metric, map real usage, and model certify, exit, and subscribe on one horizon, so the Java call is made on evidence rather than on database habit.