The technical removal was rarely the hard part. Producing evidence that satisfied a sceptical reader was, and removal without a record is worse than no removal at all
Take the runtimes off and write nothing down, and you have destroyed the evidence that a binary was covered while keeping none that it left.
Prepared by Redress Compliance · August 18, 2026 · Oracle Java cleanup projects. 35 to 45 projects run, 2024 to 2025.
Executive summary
Teams that removed first and documented afterwards could not reconstruct what had been on a machine, and conceded rows they could probably have defended.
The last 5 percent of installations consumed more elapsed time than the first 95, almost always because of one application vendor who would only certify an Oracle build.
Container base images inherited from a public registry were the single most common source of an Oracle runtime nobody had chosen. Roughly one estate in four found one inside software it had bought from somebody else.
Estates without repository control saw Oracle runtimes reappear within two quarters, usually on newly built developer machines. Drift is the whole risk.
What is a cleanup actually removing?
Oracle branded Java runtimes, from every machine with no documented reason to keep one. That is the whole scope. It is not a Java upgrade, not an application modernisation programme, and not a negotiation.
Every asset ends in exactly one of three states
- Clean: no Oracle branded runtime, a replacement distribution where Java is still needed, and a dated removal record.
- Excepted: an Oracle runtime remains, with a named owner, a written reason, an approval and an expiry date.
- Covered: the Java present is licensed by something you already own, typically a restricted use grant inside another product.
A cleanup is finished when no asset sits in a fourth state called unknown. The positions here are grounded in the Oracle Java SE licensing FAQ and in the distributors' own documentation.
Where do the copies actually sit?
In six populations, each needing a different detection technique. The mistake that defines a failed cleanup is running one discovery product across the server estate and treating the output as the estate.
| Population | How you detect them | Typical share |
|---|---|---|
| Servers and virtual machines | Resolve the Java command to a real path, then read the release file | 25 to 40 percent |
| Developer endpoints | Endpoint agent plus the code signing certificate on the executable | 20 to 35 percent |
| Build and pipeline agents | Read the toolchain declaration in the repository, not the agent | 5 to 10 percent |
| Container images | Layer scan in the registry plus the software bill of materials | 5 to 15 percent |
| Vendor packaged applications | File system scan under each vendor install root, then ask in writing | 15 to 30 percent |
| Appliances and plant systems | A written statement from the manufacturer, never a scan | 2 to 8 percent |
Provenance beats version every time. Two runtimes can report the same version and carry entirely different obligations, so the question is who built the file rather than which release it claims to be.
The Oracle Java audit defence brief
Defend a Java audit without overpaying, and know which moves cannot be undone.
Get the brief →What 35 to 45 Java cleanups showed
Across roughly 35 to 45 Oracle Java cleanup projects run between 2024 and 2025, the technical removal was rarely the hard part. Four patterns recur.
- Teams that removed first and documented afterwards could not reconstruct what had been on a machine.
- The last 5 percent of installations consumed more elapsed time than the first 95.
- Estates without a proxy or repository control saw Oracle runtimes reappear within two quarters.
- Container base images inherited from a public registry were the single most common source of a runtime nobody had chosen.
The cleanup is not finished when the last runtime is uninstalled. It is finished when a stranger can read your register and reach the same conclusion you did.
- Every risky clause flagged with the verbatim quote and page anchor
- Entitlements, caps and protections verified across your whole contract portfolio
- Paste ready replacement language and an evidence trail for the response
How is the removal actually run?
In waves, with a different method per population and a rollback plan gating each wave. Bulk removal across an entire estate in one change window is how a cleanup turns into an outage review.
Servers get the replacement installed and the path repointed before the old runtime comes off, because services that hardcode an absolute path fail on restart, often days later. Vendor packaged applications get a written question rather than a removal, since replacing a private runtime voids the support statement.
Standardise on one replacement distribution
One distribution and one supported version line across the estate. Two doubles the patch surface for no licensing benefit, whether you land on Eclipse Adoptium, Amazon Corretto or another build of OpenJDK.
Watch the briefing · 4:37Renew or Exit, and How We Help With EitherThe two paths out of an Oracle Java subscription, and what each one costs.
How do you prove an install is really gone?
With a removal record per asset, written at the time, plus two rescans on a fixed schedule at 30 and 90 days. Proof is a document rather than a screenshot.
A single scan on the day of removal proves nothing about drift, and drift is the entire risk. The rescans are what turn a change ticket into evidence.
The exception list is signed, dated and counted
Write an exception list, sign it, and give it an expiry date. Every estate keeps a few Oracle runtimes, and undocumented exceptions are exactly what an auditor finds.
If a notice has already arrived, the audit defence sequence, the Java audit guide and the response playbook take over, because a live claim changes what you are allowed to remove. The claim itself is answered in how to fight an audit claim.
What the projects measured, 2024 to 2025
Two cuts of the engagement file explain where the elapsed time goes.
An Oracle runtime shipped inside a vendor packaged application, which is the population that has to be asked about rather than scanned.
The final tranche consumed more elapsed time than the other 95 percent combined, almost always over one vendor's certification matrix.
Neither figure is a technical problem. Both are third party dependencies, which is why they belong on the plan at week one rather than at week twenty.
Your first five moves
- Sweep all six populations before declaring an inventory, because most projects sweep two of the six and call it complete.
- Detect by provenance rather than by version, reading the builder from the release file, the code signing certificate or the toolchain declaration.
- Write the removal record at the time of removal, not afterwards, since teams that documented later could not reconstruct what had been on a machine.
- Rescan at 30 and 90 days and put repository controls in place, because runtimes reappeared within two quarters wherever the proxy was open.
- Sign the exception list and give every entry an expiry date. The Java licensing reference carries the metric, the cost optimization playbook covers the spend around it, and the Oracle practice builds the evidence pack alongside the removal.
Frequently asked questions
What does a Java cleanup remove?
Oracle branded Java runtimes from every machine with no documented reason to keep one. It is not a Java upgrade, an application modernisation programme, or a negotiation.
Why is documentation the hard part?
Because removal without a record destroys the evidence that a binary was covered and keeps none that it left. Teams that documented afterwards conceded rows they could probably have defended.
How many populations are there?
Six: servers, developer endpoints, pipeline agents, container images, vendor packaged applications, and appliances. Most projects sweep two of the six and declare victory.
Which population causes the most trouble?
Vendor packaged applications. Roughly one estate in four finds an Oracle runtime inside software it bought from somebody else, and it has to be asked about in writing rather than scanned.
Why detect by provenance rather than version?
Because two runtimes reporting the same version number can carry completely different obligations. The licensing fact is who built the file and under which terms it was obtained.
How many rescans are needed?
Two, at 30 and 90 days. A single scan on the day of removal proves nothing about drift, and drift is the entire risk the evidence pack exists to answer.
Why do runtimes come back?
Because the internal artifact repository has been proxying and caching Oracle archives for years. Without repository control, estates saw them reappear within two quarters on newly built developer machines.
When is the wrong moment to start?
The week after a formal audit notice lands. At that point you freeze the estate instead, because removing binaries once a claim exists destroys your own evidence.
Should exceptions be hidden?
No. Excepted machines are counted, not hidden, each with a named owner, a written reason, an approval and an expiry date. Undocumented exceptions are what an auditor finds.
How do you know the project is finished?
When no asset sits in a state called unknown, and when a stranger can read the register and reach the same conclusion you did. That is a higher bar than the last uninstall.
