Why discovery comes first
Every Java licensing decision, whether to defend an audit, to size a subscription, or to migrate to a free runtime, rests on knowing what is actually deployed. Discovery comes first because it is the only step that converts assumption into evidence, and in a dispute with Oracle, evidence is the currency. An organisation that walks into a review able to enumerate its Java estate sets the boundaries of the discussion; one that cannot is reduced to disputing Oracle's reconstruction of its estate, which is a far weaker position.
The reason discovery is hard, and therefore neglected, is that Java spreads quietly. It arrives bundled inside applications, embedded in container base images, installed by default on desktop builds, and pulled into build pipelines as a dependency. None of these require a human to decide to install Java, so the estate accretes without anyone tracking it. This article sits beneath the Oracle Java licensing pillar and treats discovery as the foundation on which both audit defence and migration are built.
The cost of skipping discovery is paid later and at a premium. Organisations that begin negotiating or migrating without a complete inventory routinely find runtimes they did not know about, which either undermines a compliance position mid review or derails a migration that was scoped against an incomplete picture. The discipline is to finish discovery before any commitment is made, because every subsequent number depends on it.
How do you find all Java installations?
You find all Java installations by scanning systematically across every layer where a runtime can live and recording, for each, the version, the vendor and distribution, the installation path, and the application or service that depends on it. A complete discovery covers servers and virtual machines, end user desktops and laptops, container images and registries, build and continuous integration pipelines, and any appliances or vendor systems that embed a runtime. Missing any one layer leaves a blind spot that can surface as an unbudgeted liability.
A Java estate is rarely a list of decisions; it is a sediment of defaults. Discovery is the act of reading that sediment before someone else reads it for you.
The output of discovery is not a count but a map: every runtime located, attributed to a vendor, and linked to the thing that needs it. That linkage is what makes the inventory actionable, because it distinguishes a runtime that can be removed immediately from one that holds a critical application in place and must be migrated deliberately. Without the dependency mapping, an inventory is just a number; with it, it is a migration plan and a compliance defence at once.
Discovery methods and tooling
Discovery combines several methods because no single technique reaches every layer. Endpoint management and software asset management tools enumerate installed packages on managed machines. Filesystem and process scanning finds runtimes that package managers miss, including those bundled inside applications. Container registry scanning inspects image layers for embedded runtimes. Build pipeline inspection identifies runtimes pulled as dependencies. And configuration management records reveal what was provisioned by policy versus what arrived by accident.
The practical approach is to run these methods in parallel and reconcile their outputs into a single authoritative inventory, because each method catches what the others miss. A runtime that the asset management tool reports but the process scan does not is dormant; one the process scan finds but the asset tool does not was installed outside policy. The reconciliation itself surfaces the governance gaps that allowed the estate to grow uncontrolled, which is information worth as much as the inventory. This rigorous, multi method approach is the backbone of the firm's Java advisory service.
Telling Oracle Java from OpenJDK
The single most consequential attribute in the inventory is the vendor, because only Oracle distributed runtimes carry the subscription liability; free certified OpenJDK builds do not. Distinguishing them is therefore the discovery step that directly sizes the exposure. The vendor can usually be read from the runtime's own version output, from the installation path and package metadata, and from the binaries' signing and provenance, each of which identifies whether a given runtime is an Oracle build or a free distribution.
| Signal | What it reveals |
|---|---|
| Version string output | Vendor name and build identifier |
| Installation path and package metadata | Distribution and how it was installed |
| Binary provenance and signing | Whether the build is Oracle or a free distribution |
| Release and update version | Whether the version requires a paid Oracle subscription for updates |
The version detail matters as much as the vendor, because Oracle's licensing turned on specific version and update boundaries over the years, and a runtime's exact build determines whether updates required a subscription. An inventory that records vendor and precise version together can therefore classify each runtime as free and clear, free but mislabelled, or genuinely Oracle and in scope, which is the classification that drives the compliance position.
What Oracle already knows about your downloads
Discovery is not only about what you can see; it is about anticipating what Oracle can see. Oracle holds telemetry from its own download endpoints, records of support portal access, and the history of any prior Java subscriptions, and it uses these signals to build a picture of an organisation's Java footprint before any formal engagement. This is the evidentiary basis behind most soft outreach, as detailed in the Java audit triggers analysis.
The implication for discovery is that your inventory must account for history, not just the present state. A runtime downloaded and later removed may still appear in Oracle's records, and the organisation should be able to explain its trajectory: when it was deployed, when it was removed, and what replaced it. Discovery that captures only the current estate leaves the organisation unable to answer the historical questions Oracle asks, which is why a defensible discovery includes the record of removals and replacements, not only the live inventory.
Turning discovery into a decision
A completed discovery converts directly into the two decisions that follow. For compliance, the inventory establishes exactly which runtimes are Oracle and in scope, which bounds the liability and forms the factual core of an audit defence. For strategy, the dependency map shows which runtimes can be removed immediately and which require a planned migration, which is the input to the migration playbook.
The decisive output is usually the realisation that the Oracle dependent footprint is far smaller than the total Java estate, because most runtimes are either already free distributions or attached to applications that run equally well on free builds. That realisation reframes the choice from accepting a workforce wide subscription to executing a bounded migration project, and it is only available to the organisation that did the discovery first.
The buyer side view
The buyer side view is that discovery is the highest return activity in Java licensing, because it is the cheapest step and it determines the value of every step after it. An hour spent finding and attributing runtimes saves far more than an hour spent negotiating from ignorance, because the inventory is what turns Oracle's assertions into your facts. The organisation that owns its Java map owns the conversation.
Run discovery across every layer, attribute every runtime to a vendor and version, map each to its dependent application, and account for history as well as the present state. Then use the inventory to bound the compliance position and scope the migration. Begin with the Java licensing pillar, understand the triggers in the audit triggers analysis, and engage the Java advisory service to run a discovery that stands up under Oracle scrutiny.
Scan across servers, desktops, container images, and build pipelines, recording version, vendor, path, and dependent application, then reconcile into one inventory. No single method reaches every layer, so several run in parallel. Read the version string for the vendor, inspect the path and package metadata, and check binary provenance. Only Oracle builds carry the subscription liability, so the vendor attribution sizes your compliance exposure. Because defending an audit, pricing a subscription, or planning a migration all depend on a complete inventory. The party with the better Java map controls the conversation, as the audit defence guide explains.Oracle Java deployment discovery: frequently asked questions
How do you find all Java installations in an organisation?
How can I tell Oracle Java apart from free OpenJDK?
Why is discovery the first step in Java licensing?