You cannot migrate off Oracle Java, or defend an audit, from an incomplete inventory. This guide gives you the discovery methodology to find every Oracle JDK and JRE across your estate and separate licensable Oracle binaries from free OpenJDK.
You cannot migrate off Oracle Java, or defend an audit, from an incomplete inventory. This guide gives you the discovery methodology to find every Oracle JDK and JRE across your estate and separate licensable Oracle binaries from free OpenJDK.
Every Oracle Java decision (migrate, renew, or defend an audit) rests on one artifact: a complete, defensible inventory of what is actually installed and running. Get this wrong and you either overpay Oracle for phantom exposure or, worse, sign an employee-metric subscription because you could not prove your Oracle footprint is small enough to remove. In 25 years of negotiating with this vendor, the pattern does not change: the party with the better inventory sets the price.
The stakes are specific. Oracle's Java SE Universal Subscription is priced on total headcount, not deployment. List runs from $15.00 per employee per month at the smallest band down to $5.25 per month at 40,000 to 49,999 employees, with the definition of "employee" including full-time, part-time, temporary staff plus the staff of your agents, contractors, outsourcers, and consultants who support internal operations. A 5,000-employee company pays roughly $630,000 per year at list whether it runs Oracle Java on 40 servers or 400. If your inventory shows 12 licensable Oracle installs that you can remove in a weekend, you do not buy that subscription at all. That is the entire economic argument, and it lives or dies on discovery.
Our field data closes the loop: an estate sweep routinely finds Oracle JDK on 15 to 35 percent of servers assumed to be OpenJDK. Read the discovery gap analysis for the mechanics of why that number is so consistent. This article is the how-to that sits under it: the methodology to find every install before Oracle's LMS scan does.
The party with the better inventory sets the price. Oracle's LMS team runs discovery for a living. You should run yours first.
Most inventories fail because they scan one surface and declare victory. Oracle Java lives on four distinct surfaces, each requiring a different detection technique. Scope all four before you run a single scan, and assign an owner to each.
The traditional target, and still where the bulk of licensable exposure sits. Physical servers, VMs, and the guests inside VMware clusters all need filesystem-level scanning for JDK and JRE binaries. Do not trust CMDB records that list "Java" without a vendor string; those records are almost never accurate down to the Oracle-versus-OpenJDK level.
End-user machines carry legacy Oracle JRE installs from the Java 8 era, browser plugins, and application-bundled runtimes. These matter for two reasons: the employee metric's processor ceiling of 50,000 processors is stated exclusive of desktop and laptop computers, but the presence of Oracle binaries on desktops is still evidence of use, and old JRE 8 installs are a favorite audit finding because Oracle knows they are everywhere.
This is where filesystem scanning breaks. A container running an Oracle JDK base image may exist for four minutes and never touch a persistent disk your scanner sees. You need runtime detection that catches JVMs while they execute. Enterprise estates can contain tens of thousands of JVMs across container platforms, and a static scan will undercount them badly.
The trap that catches the most sophisticated teams. Commercial software often ships with an Oracle JRE inside its install directory. Some of those Oracle runtimes are covered by the vendor's own distribution license; some are not and become your liability the moment you use the product outside the vendor's bundled scope. Your inventory must flag every embedded Oracle JVM and then, separately, determine whether it is covered. We treat this as its own workstream; see migrating third-party apps that bundle Oracle Java.
Since Java 11, Oracle JDK is built directly from the OpenJDK source, so the binaries are functionally identical. Features like JFR and ZGC that were once Oracle-only are upstreamed. This means a version number alone tells you nothing about licensing. You must fingerprint the vendor, not the version. Four signals, in order of reliability:
java -XshowSettings:properties -version and inspect the java.vendor and java.vendor.version properties. Oracle builds report Oracle as the vendor. Community and distribution builds report their own identity, for example a GraalVM Community or Eclipse Temurin string. This is the single most reliable signal and should be your primary key.jdk-17.0.x under an Oracle-style directory versus temurin, zulu, corretto, or graalvm give a fast triage read before you confirm with the vendor string.A version number tells you nothing about licensing. Fingerprint the vendor string, then confirm with packaging and path. Everything else is triage.
Your inventory must record the exact update level, not just the major version, because Oracle's free-use terms change mid-version. The No-Fee Terms and Conditions (NFTC), in use since September 2021, permit free use including commercial and production use, but only within defined windows. Miss the window and the same binary becomes payable. These are the cliffs to encode in your inventory logic:
| Version | Free-use status | Cliff / trigger |
|---|---|---|
| JDK 8 / 11 (Oracle builds) | Licensable for most commercial use | Legacy OTN/subscription terms; classic audit target |
| JDK 17 (17.0.12 and earlier) | Free under NFTC | Last NFTC build was Sept 2024 |
| JDK 17 (17.0.13 and later) | Payable | OTN license from Oct 2024; subscription required |
| JDK 21, 22, 23, 24 | Free under NFTC | Free until September 2026; payable after |
| JDK 25 | Free under NFTC in production | Free until September 2028; later updates move to OTN |
The dangerous part is that the licensable event is a download, not a purchase. A build pipeline pinned to a "latest" tag is a standing instruction to cross whatever version boundary arrives next, silently. Your inventory must capture patch level to the third digit (for example 17.0.12 versus 17.0.13) and flag any floating references in package managers and container base images. Pin runtimes explicitly. Treat every latest tag pointing at an Oracle repository as an open liability until proven otherwise.
There is no one scanner that catches all four surfaces. Build a stack that pairs filesystem discovery with runtime detection, because each covers the other's blind spot.
Software asset management tools such as Flexera can perform machine and software inventory, capture the presence of specific applications including Oracle Java, and track usage. Dedicated migration scanners find JDKs that are physically present on disk. These are strong for servers, desktops, and persistent VMs, and they are your source of truth for install paths and version strings. Their weakness is ephemeral workloads: a scanner sees only what is on disk when it runs.
Runtime inventory services (Azul's JVM Inventory is the prominent example) gather data directly from the JVM as it executes, capturing vendor, version, install path, and the running application. This is how you catch ephemeral containers and short-lived processes that filesystem scans miss. The stated limitation is important to plan around: runtime detection does not perform network-wide searches for JDK installations on local or remote file systems. It sees what runs, not what sits idle on disk.
Oracle's own detection scripts are available, and running them internally before Oracle does is the single most useful audit-defense move you can make. It shows you exactly what Oracle's tooling will report and lets you remediate before the finding lands in a formal claim. This is part of a disciplined internal program; see our approach to conducting internal Oracle license audits.
| Surface | Primary method | Secondary method | Blind spot to cover |
|---|---|---|---|
| Servers / VMs | Filesystem SAM scan | LMS scripts | VMware guest sprawl |
| Desktops / laptops | Endpoint agent inventory | Manual JRE 8 sweep | Browser plugins, app bundles |
| Containers | Runtime JVM detection | Image registry scan | "latest" tag drift |
| Embedded / third-party | App inventory + directory scan | Vendor license review | Coverage vs. liability call |
Raw discovery data is not an inventory. Classification is. Every JVM you find must be tagged into one of four buckets, and the bucket, not the count, is what determines your exposure and your migration plan.
The classification also drives target selection. Once you know which distributions you already trust and where they run well, choosing replacements is faster; our comparison of OpenJDK alternatives to Oracle Java maps the credible options on cost and support SLA. If you are weighing a paid but non-Oracle path, the Azul Zulu versus Oracle Java comparison lays out two very different contracts.
A complete inventory feeds directly into execution. The licensable-Oracle bucket becomes your migration backlog, sequenced by risk and effort. Follow the OpenJDK execution guide for the full replacement workflow, and use compatibility testing across JDK vendors to de-risk each swap before it hits production. For large estates, sequence the work with phasing a Java migration across a large estate rather than attempting a single cutover.
Two operational habits protect the inventory after you build it. First, block Oracle's update check-ins so machines stop silently pulling new binaries; see how to block Oracle Java update telemetry. Second, keep the inventory living: re-scan on a schedule, because a static snapshot decays the moment a developer pulls a new base image or an application update ships an embedded runtime.
A one-time scan is a photograph. An inventory that survives an audit is a living register with cliff dates, owners, and re-scan cadence.
Move in this order. First, scope the four surfaces and assign owners. Second, stand up filesystem plus runtime detection so you cover both static and ephemeral workloads, and run Oracle's own LMS scripts on yourself. Third, classify every JVM by vendor string into the four buckets and record patch level to the third digit with its cliff date. Fourth, freeze silent conversion by pinning runtimes and blocking auto-updates. Fifth, hand the licensable-Oracle bucket to the migration team and keep the register alive with scheduled re-scans.
Done well, this inventory is worth more than any tool license it consumed. It is the document that lets you decline Oracle's subscription with evidence, or, if you must buy, buy the minimum with the audit posture already handled. Companies that resolved seven-figure Java claims to zero did it on the strength of exactly this kind of inventory work; see the Avis Budget Group case study for what a defensible position looks like in practice.
Run java -XshowSettings:properties -version and read the java.vendor property. Oracle builds report Oracle as the vendor; distributions like Temurin, Zulu, Corretto, or GraalVM Community report their own name. Since Java 11 the binaries are built from the same source, so only the vendor string is reliable. Version number alone tells you nothing about licensing.
Oracle's free-use terms change mid-version. Oracle JDK 17.0.12 and earlier are free under the NFTC, but 17.0.13 and later (from October 2024) require a paid subscription. JDK 21 through 24 are free until September 2026. Your inventory must record the exact update level to the third digit or you will misclassify licensable installs as free.
No. Filesystem and SAM scanners catch installs on disk but miss ephemeral containers. Runtime JVM detection catches running processes but does not search file systems for idle installs. You need both, plus running Oracle's own LMS scripts internally to see what Oracle's tooling will report.
The 50,000-processor ceiling in the employee metric is stated exclusive of desktops and laptops, but the employee metric is priced on headcount regardless of where Java runs. Oracle JRE 8 installs on desktops are still evidence of use and a common audit finding, so inventory them even though they do not consume the processor allowance.
Some embedded Oracle runtimes are covered by the vendor's own distribution license; some are not. Flag every embedded Oracle JVM in your inventory, then make a coverage determination per product. Do not assume bundled means covered, and do not assume it makes it your liability either. It requires a case-by-case review.
A one-time scan decays immediately because developers pull new base images and application updates ship new runtimes. Treat the inventory as a living register with scheduled re-scans, ideally monthly for container estates and quarterly for servers and desktops. Pin runtimes and block auto-updates so machines stop silently crossing version cliffs between scans.
Oracle now audits Java SE on employee count, not installs, which can multiply the bill several times over. How to defend the notice and exit to OpenJDK.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.