A Java exit is decided by two things: the evidence file that records exactly where Oracle Java runs, and the employee based subscription that now prices Java by headcount rather than by how much you deploy. Get both clear before your ULA ends and the post Java decision becomes a calculation rather than a gamble.
Java is the Oracle product where the gap between what you deploy and what you pay for has widened the most. Where a database ULA rewards counting more, a Java position is usually about counting precisely and then deciding whether to stay on Oracle Java at all. The reason is the pricing model. Oracle's current Java SE subscription is charged per employee across the whole organisation, so the bill is driven by your headcount rather than by the number of machines running a Java runtime. That changes the evidence work and the exit decision together. This article sets out what Java usage evidence you actually need, how the employee based subscription reshapes the math, and how to leave a Java ULA or Java entitlement in a position you can defend. The metric, the products in scope, and what counts all depend on your specific contract, so treat the mechanics below as the map rather than the territory.
You need a complete inventory of every machine and environment where an Oracle Java runtime is installed or running, the specific distribution and version on each, the features in use, and the business purpose of the deployment. That installation and usage record is the evidence file. For a Java entitlement that certifies on a count, the evidence supports the number you declare. For an estate you intend to move off Oracle Java, the same record proves what you removed and when. Either way the evidence is what stands between a clean position and an open ended argument with Oracle later. Build it while your unlimited or contracted right still protects the deployments, not after, because reconstructing an installation history once the term has closed is far harder and far less convincing.
With Java the evidence is distribution level, not server level. Knowing a machine runs Java is not enough. You need to know whose Java it runs, because the Oracle binary is what creates the exposure.
A defensible Java evidence file is built from the runtime up. It records the host or container, the exact Java distribution and vendor, the version and update level, how the runtime was obtained, the features and commercial components in use, and the environment type. The distinction that matters most is between an Oracle supplied build and an open source build of the same version from another provider, because only the Oracle binary sits under Oracle's Java terms. A spreadsheet of server names is not enough. The file needs to answer, for every Java instance, the question Oracle would ask: is this our Java, and if so under what right is it running.
Oracle's current Java SE subscription is priced per employee across the whole organisation rather than per processor or per installed instance. The practical effect is that the cost of staying on Oracle Java after a ULA is set by your total headcount, not by how much Java you actually run. An organisation with a small Java footprint and a large workforce can find that subscribing is expensive relative to the value, while an organisation that runs Java heavily across a modest workforce may find the opposite. This is the calculation that decides most post Java positions. Where the database conversation is about maximizing a count, the Java conversation is usually about whether to remove or replace Oracle distributions so that no subscription is required at all. Both options need to be modeled with real numbers before anyone commits, because the cheaper path is genuinely contract and headcount specific.
Consider an anonymized organisation approaching the end of a Java entitlement. Its real Java footprint is modest, a few dozen servers, but its employee count is large. Under the employee based model the subscription cost is tied to the workforce, so it looks high against the actual usage. The alternative is to replace the Oracle Java distributions with open source builds of the same versions, retiring the Oracle binaries entirely and removing the basis for a subscription. The figures below are indicative and every estate differs, but the shape of the decision is the point.
| Path | What drives the cost | When it tends to win |
|---|---|---|
| Stay on Oracle Java SE subscription | Total employee headcount | Heavy Java use across a smaller workforce |
| Replace with open source builds | Migration and validation effort | Modest Java footprint across a large workforce |
| Mixed, keep Oracle only where required | The residual Oracle install base | A small set of workloads genuinely needs Oracle Java |
Generally no. Open source builds of the same Java version, supplied by other providers, are not licensed under Oracle's Java terms and do not require an Oracle subscription. The exposure comes from Oracle supplied binaries, so the risk lives in mixed estates where an Oracle distribution has been installed somewhere alongside open source ones, often without anyone choosing it deliberately. A developer downloads an Oracle build for one project, an appliance ships with one embedded, or an old install was never replaced. This is exactly why the evidence file has to be distribution level. An estate that believes it is fully on open source Java but still carries a handful of Oracle binaries is exposed, and a complete inventory is what turns that belief into a fact you can prove. Where Oracle builds are found, the choice is to remove them, replace them with an open source equivalent, or account for them deliberately.
The Java decision should be made inside the term, not after it. If the plan is to move off Oracle Java, the migration and the evidence that confirms it need to be substantially complete before the entitlement closes, so the position at exit reflects what you actually run rather than a removal still in progress. If the plan is to certify a Java count, the deployments need to be in place and documented within the term in the same way as any other Oracle product. The worst outcome is to reach expiry with an unmeasured Java estate, a half finished migration, and no record of which binaries came from where. That is the position from which an employee based subscription quote looks unavoidable, when in fact a clean inventory and a deliberate removal would have made it optional.
Java and middleware are usually handled together at exit, and the evidence questions overlap with the rest of your Oracle estate. Read certifying out of a Java ULA for the exit decision in full and WebLogic in a ULA, counting and exit for the middleware side of the same engagement. For how the Java work fits the wider exit, see the ULA exit strategy guide.
You need an inventory of every machine and environment where an Oracle Java runtime is installed or running, the specific Java distribution and version on each, the features in use, and the business purpose. That installation and usage record is the evidence file, and it is what supports the certified position or proves what you can safely remove before exit. The exact metric and what counts depend on your contract and the products in scope.
Oracle's current Java SE subscription is priced per employee across the whole organisation, not per processor or per installed instance. That means the cost of staying on Oracle Java after a ULA is driven by headcount rather than by how much Java you actually run, which often makes removing or replacing Oracle Java distributions the cheaper path. Model both before you decide, because the right answer depends on your headcount and your real Java footprint.
Generally no. Open source builds of the same Java version, supplied by other providers, are not licensed under Oracle's Java terms. The risk is mixed estates where an Oracle distribution is installed alongside open source ones, because the Oracle binaries are what create exposure. A complete distribution level inventory is what separates a clean estate from a costly one.
Book a confidential assessment and we will build your distribution level Java inventory, model the subscription against removal, and set a position you can defend.