A cleanup is a removal project with an evidence requirement bolted to it. The deliverable is not a lower install count. It is a dated register that proves, machine by machine, that Oracle branded Java is gone and cannot come back.
Most Java cleanups fail on the last mile. The runtimes come off the machines, nobody writes down what was there, and two years later the organisation cannot prove any of it happened.
This page is the project itself: the six populations to sweep, the removal runbook for each, the nine field removal record, and the seven documents that make the whole thing hold up.
Where this page states a licensing position it is grounded in Oracle's published terms and in the distributors' own documentation: Oracle's Java SE licensing FAQ, the Java SE Universal Subscription page, the OpenJDK project, Eclipse Adoptium and Amazon Corretto.
Two adjacent pages carry the parts this one deliberately leaves out. The metric and its history sit in the Oracle Java licensing reference. If a notice has already arrived, start with the Java audit defence tactics and the audit claim defence framework instead, because a live audit changes what you are allowed to remove.
It is removing Oracle branded Java runtimes from every machine that does not have a 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 in the estate ends in exactly one of those three states. A cleanup is finished when no asset is in a fourth state called unknown.
The three good moments are a renewal twelve months out, the closing of an acquisition, and the quarter after a friendly call from an Oracle representative asking about your Java estate. All three give you time to work without a deadline someone else set.
The bad moment is 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 and invites an argument you cannot win.
You sweep six populations with a different technique for each, because no single tool sees all six. The mistake that defines a failed cleanup is running one discovery product across the server estate and treating the output as the estate.
Six populations, six detection techniques
| Population | Where the copies actually sit | How you detect them | Typical share |
|---|---|---|---|
| Servers and virtual machines | Package manager records, plus loose archives unpacked under an application directory | Resolve the Java command to a real path, then read the release file for the implementor value | 25 to 40% |
| Developer endpoints | Fetched straight from the vendor download page, outside the software catalogue | Endpoint agent plus the code signing certificate on the executable | 20 to 35% |
| Build and pipeline agents | Declared in the pipeline file, not installed on the runner | Read the toolchain declaration in the repository, not the agent | 5 to 10% |
| Container images | Inside base images you inherited rather than images you wrote | Layer scan in the registry plus the software bill of materials | 5 to 15% |
| Vendor packaged applications | A private runtime buried in the vendor's own directory tree | File system scan under each vendor install root, then ask the vendor in writing | 15 to 30% |
| Appliances and plant systems | Firmware you cannot open and must not patch | A written statement from the manufacturer, not a scan | 2 to 8% |
Two runtimes can report the same version number and carry entirely different obligations. The question is never which version, it is who built this file and under which terms it was obtained.
Almost every cleanup finds a second wave after the first pass is declared complete. The same three hiding places produce it.
You remove it with a different method per population, in waves, each wave gated by a rollback plan. Bulk removal across an entire estate in one change window is how a cleanup turns into an outage review.
What you do, what breaks, and what you keep
| Population | The removal action | What breaks if you rush it | The record you keep |
|---|---|---|---|
| Servers | Install the replacement, repoint the environment variable and any service definition, restart, then remove the old runtime | Services that hardcode an absolute path in a startup script fail on restart, often days later | Change ticket, before and after runtime evidence, service restart confirmation |
| Developer endpoints | Push the replacement through the management tool, then remove the old package and clear the local cache | Local build tools pinned to the old path stop working and engineers reinstall Oracle themselves | Device compliance report before and after, dated per device |
| Pipeline agents | Change the distribution named in the toolchain declaration, then rebuild the agent image | Builds pass locally and fail in the pipeline, or worse, pass with the wrong runtime | The merged change to the pipeline definition, with commit reference and date |
| Container images | Change the base image, rebuild, and expire the old tags in the registry | Old tags stay pullable forever and quietly return to production | Registry evidence that old tags are gone, plus a fresh bill of materials |
| Vendor packaged applications | Ask the vendor in writing which runtime it ships and who licenses it. Then upgrade or except | Replacing a private runtime yourself voids the vendor's support statement | The vendor's written answer, filed with the exception record |
| Appliances and plant systems | Do not touch. Obtain a written statement and place it on the exception list | Unplanned downtime on systems that are not yours to patch | The manufacturer's letter, with the review date |
Standardise on one distribution across the estate and one supported version line. Two distributions doubles your patch surface for no licensing benefit, and it makes the evidence pack harder to read.
Replacement options and what actually decides the choice
| Distribution | Where it fits naturally | Support route | The question to ask first |
|---|---|---|---|
| Eclipse Temurin | Mixed estates with no single cloud allegiance | Community builds, commercial support available from several vendors | Does your application vendor name it in its certification matrix? |
| Amazon Corretto | Estates already weighted to Amazon Web Services | Free, with long term support builds published by Amazon | Are your on premises servers covered by the same policy? |
| Microsoft Build of OpenJDK | Windows fleets and Azure workloads | Free, published and supported by Microsoft | Which version lines are covered, and for how long? |
| Azul builds of OpenJDK | Regulated environments that want a contract and a named support desk | Commercial, with broad version coverage including older lines | Do you need a supported build of a version everyone else has dropped? |
| Red Hat build of OpenJDK | Estates standardised on Red Hat Enterprise Linux | Included in the existing operating system subscription | Does the entitlement extend to your Windows and container workloads? |
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.
You prove it with a removal record per asset, written at the time, plus two rescans on a fixed schedule. Proof is a document, not a screenshot, and it has to be readable by someone who was not there.
Run the same detection method three times: at removal, at 30 days, and at 90 days. The first proves the action, the second catches an automated rebuild putting it back, and the third catches human drift.
Publish the delta each time. A register that shows three assets regressing at day 30 and being fixed is far more persuasive than one that shows a perfect result on day one and nothing afterwards.
Several Oracle products ship a Java runtime whose use is already licensed as part of that product. Where a runtime exists only to operate that product, it is usually covered rather than exposed.
Removing it gains nothing and loses the evidence that it was covered. Check the parent product's ordering document first, then mark the asset as covered rather than clean.
White Paper · Oracle
The Oracle Java Audit Defence Playbook
What the Universal Subscription really costs and how buyers push back. Read it free.
Seven documents, assembled as you go rather than reconstructed at the end. The pack is the entire commercial value of the project, because it is the only thing that answers a claim without you having to argue about memory.
The evidence pack, and who has to be able to read it
| Document | What it contains | Who signs it |
|---|---|---|
| Scope statement | Legal entities, asset populations, cutoff dates, and anything deliberately excluded | Programme sponsor |
| Method note | Exactly how each population was detected, in enough detail to be reproduced by a third party | Asset management lead |
| Removal register | One row per asset with the nine fields, including the two rescan results | Asset management lead |
| Exception list | Every retained Oracle runtime, its reason, its owner, its approval and its expiry date | Programme sponsor and legal |
| Coverage file | Assets marked covered, with the parent product order that covers them | Commercial or procurement lead |
| Guardrail evidence | Configuration proof for each control that stops the runtime returning | Infrastructure lead |
| Attestation | A one page signed statement of what was done, by whom, over what period | Accountable executive |
The common advice is straightforward: uninstall Oracle Java everywhere, and you are clean. We disagree, and the sequence matters more than the instruction. An uninstall with no contemporaneous record converts a defensible position into an undefendable one, because a vendor's download records outlive your removal by years while your proof of what was actually deployed disappears the moment the file does. When a claim arrives two years later, the only thing that answers it is a dated register showing what was present, under which terms it was obtained, and what happened to it. Removal is the cheap half of this project. Evidence is the half that pays for it.
Source: Redress Compliance advisory engagement file, Java remediation projects 2024 to 2025.
You put seven guardrails in place before the project closes, and you evidence each one. Without them the estate reverts within two quarters, usually through newly built developer machines and inherited container images.
Indicative effort for a mid size estate, in person days
| Workstream | Discovery | Removal | Proof and pack |
|---|---|---|---|
| Servers and virtual machines | 5 to 10 | 15 to 30 | 5 |
| Developer endpoints | 3 to 5 | 5 to 10 | 3 |
| Pipelines and containers | 3 to 6 | 8 to 15 | 3 |
| Vendor packaged applications | 5 to 10 | 10 to 40 | 5 |
| Guardrails and closeout | 1 | 8 to 12 | 5 |
The vendor packaged row is the one that varies most. One uncooperative application supplier can consume more elapsed time than the entire server estate, which is why that conversation starts in week one and not in week ten.
Eight to twelve weeks for a mid size estate that already has endpoint management and a configuration database. Discovery takes two to three weeks, removal runs in parallel waves over four to six, and the pack closes out in two. What stretches it is almost never technology, it is the supplier who certifies only an Oracle build.
No. Once a formal notice exists you freeze the estate and document it, because removing binaries after a claim arises destroys the evidence you need to show what was actually deployed and under which terms. Resume the removal programme after the scope is agreed in writing, and record the freeze itself as part of the file.
The same detection method run twice, before and after, with timestamps and the raw value read on each occasion. A screenshot of an empty folder is not evidence, because it does not identify the method, the machine or the moment. Add the change ticket reference and a named approver and the row becomes difficult to dispute.
Usually not, and removing it can cost you more than it saves. Where a runtime exists solely to operate an Oracle product you already license, the parent product's ordering document typically covers it. Record it as covered, keep the ordering document reference in the pack, and leave it alone.
Put the request in writing and set a date. Ask for their certification statement, the runtime they ship, who licenses it, and their roadmap for supporting an alternative distribution. If the answer is unsatisfactory, the machine goes on the exception list with an expiry date and the question moves into your next contract renewal with that supplier.
Golden images, catalogue policy, repository controls, egress denial, a pipeline check, a purchasing question and a fixed onboarding build. Of those, rebuilding the golden images does the most work, because most reappearance comes from newly provisioned machines rather than from anyone deliberately reinstalling.
Only if it takes you to zero, or to a state where every remaining install is covered or excepted with evidence. Partial removal changes your risk profile and your negotiating position, but it does not by itself change a subscription priced on your headcount. Plan the project to reach a defined end state, not to reduce a count.
Whoever owns the Oracle commercial relationship, not the team that built it. Asset management produces the register, but the pack is a commercial asset that gets used in a renewal or a dispute. Hand it over formally, with a named owner and a review date in the calendar.
As a fixed scope buyer side project with the evidence pack as the contracted deliverable. We run the six population sweep, write the method note, drive the supplier correspondence, and hand back a register that your own asset team maintains afterwards. We do not resell any distribution and we do not implement.
Related programmes and background: Vendor Shield, the Renewal Program, the Benchmark Program, the Software Spend Assessment, our benchmarking method, about us, the management team, our locations, and contact.
A buyer side framework that pairs Java cleanup, audit defense, and ULA decision making in a single negotiating play. Includes metric defense templates, retirement evidence checklist, and the renewal anchor table used across hundreds of Oracle engagements.
Independent. Buyer side. Built for CIOs and procurement leads carrying Oracle Java exposure or facing a universal subscription renewal. No vendor influence. No sales kickback.
Oracle ULA Decision Framework
Open the white paper in your browser. Corporate email only.
Open the Paper →We cut the Oracle Java quote from three point two million to seven hundred thousand inside ten weeks. The retirement evidence file made the renewal defensible and closed the universal subscription debate.
We have run 500+ enterprise clients across 11 publishers. Every engagement starts with one conversation.
Universal subscription metric movement, third party JDK release news, audit script patterns, retirement evidence templates, and the wider Oracle Java commercial leverage signals across every engagement.
