Java discovery and scanning tools: a practical guide.

Every Oracle Java licensing problem — every audit defence, every renewal, every migration — begins with the same question: what Java do we actually have? Most organisations cannot answer it. They have a vague sense of their Java estate and a precise contract with Oracle, and the gap between the two is exactly where exposure lives. Discovery closes that gap, and it must be done before Oracle does its own version of it.

Why discovery comes first

Discovery is not a preliminary chore — it is the foundation of every decision that follows. You cannot size your exposure, defend an audit, plan a migration or negotiate a renewal without an accurate inventory. Three realities make this non-negotiable:

• The metric is all-or-nothing. A single Oracle JDK requiring a subscription, anywhere in the estate, obliges your entire employee count. Discovery is how you find that one install before it finds you.
• Self-knowledge beats Oracle's version. In an audit, the organisation that arrives with a complete, evidence-based inventory controls the conversation. The one that does not is led by Oracle's numbers.
• Java hides. It is bundled inside applications, baked into container images, embedded in appliances, installed on forgotten servers and frozen in VM snapshots. None of it shows up unless you go looking.

Across more than 340 Java engagements, the single most common reason a claim is larger than it should be is an incomplete inventory — on both sides. A rigorous discovery exercise is the precondition for our 68 percent average claim reduction.

What you are actually looking for

"Find the Java" is too vague to act on. Effective discovery records specific attributes for every Java installation, because licensing status turns on detail:

• Vendor and distribution. Oracle JDK, or a free distribution such as Eclipse Temurin, Amazon Corretto, Azul Zulu, Microsoft Build of OpenJDK? Only Oracle's distribution carries Oracle licensing risk.
• Exact version and build. Not just "Java 8" but the precise build — the difference between Java 8u202 and 8u211 is the difference between a free build and one under post-2019 commercial update terms.
• Licence basis. Which licence the build shipped under — BCL, OTN or NFTC — determines whether production use is free or requires a subscription.
• Location and host. Server, desktop, VM, container, appliance — and whether the host is production, test or dormant.
• Installation type. Standalone JDK, JRE, application-bundled runtime, or container-image layer.
• Source. Whether it was downloaded directly from Oracle, supplied by a vendor, or built from OpenJDK source.

A finding without these attributes is just a rumour. A finding with them is evidence.

Native discovery methods

You do not need to buy a tool to start. Native methods cover a great deal of ground:

The version command

Running java -version on a host reports the vendor and build — Oracle's output explicitly names Oracle, while OpenJDK distributions name themselves. The limitation is that it only reports the Java on the system path; additional installations elsewhere on the machine are missed.

Filesystem search

Searching the filesystem for the Java executable — find on Linux and Unix, directory and registry searches on Windows — locates installations that are not on the path: bundled runtimes inside application directories, multiple parallel JDKs, and copies installed by other software.

Package and registry inventory

Operating-system package managers on Linux, and the installed-programs registry on Windows, list Java packages that were installed through standard mechanisms. This catches managed installs but misses anything unzipped manually or bundled inside an application.

Container and image inspection

For containerised estates, inspect base images and registries directly — examine Dockerfiles for Oracle JDK base images, and scan image layers for Java binaries. A single Oracle-JDK base image can be the source of thousands of running instances.

Native methods are free and immediate, but they scale poorly across a large estate and are easy to apply inconsistently. They are excellent for spot checks and for validating a sample — less so as the sole basis for a complete inventory.

SAM and discovery tools

Software Asset Management (SAM) and IT discovery platforms automate the scan across the estate. Well-known categories include the major SAM suites and the discovery modules built into IT service-management platforms. Used well, they provide breadth and repeatability that native methods cannot.

But they come with important caveats specific to Java:

• They report presence, not licence status. A SAM tool will tell you Oracle JDK 11 is installed on 400 hosts. It will not, on its own, tell you whether that triggers a subscription — that judgement requires reading the version against its licence terms and your contract.
• They miss what they are not pointed at. Agentless scans depend on credentials and network reach; bundled and embedded Java is often missed unless the tool is specifically configured to look inside application directories.
• Vendor-tool data should not be handed straight to Oracle. Raw scan output frequently overstates exposure — counting free distributions, test systems and dormant hosts indiscriminately. It is an input to analysis, not a finished answer.

The right model is to use a SAM or discovery tool for breadth and automation, then apply licensing expertise to interpret what the scan found. The tool produces the map; a specialist reads it. Our comparison of discovery tooling for Java goes deeper on tool selection.

Oracle's own scripts

Oracle provides scripts and tooling — and during an audit, the LMS or GLAS team will typically ask you to run Oracle's scripts and return the output. It is essential to understand what this means before you do it.

Oracle's scripts are designed to serve Oracle's interests. They collect detailed data, and the output flows directly into Oracle's exposure calculation. Running them is sometimes a contractual obligation under an audit clause — but how, when and with what scope you run them is not something to decide casually. Two principles apply: never run Oracle's scripts before you have completed your own independent inventory and understand your position, and never return raw output without first reviewing exactly what it says. An organisation that hands over Oracle's script results without preparation has effectively let Oracle write its own claim. This is one of the clearest reasons to have independent advice in place before an audit progresses — see Java audit defence.

How Oracle detects your Java

Discovery is partly about anticipating what Oracle already knows. Oracle does not need access to your network to form a view of your Java usage:

• Download records. Oracle JDK downloads from Oracle's site require an account, and those downloads are logged. A history of Oracle JDK downloads against your organisation's accounts is one of the most common triggers for a soft-audit letter.
• Update and telemetry signals. Java's update mechanisms communicate with Oracle infrastructure, providing signals about which builds are in use.
• Support and account history. Past licences, support tickets and prior purchases all inform Oracle's view of how likely you are to be using commercial Java.
• Self-disclosure. Soft-audit questionnaires ask you to describe your own Java usage. Answers given without a verified inventory are Oracle's richest source of all.

Understanding these channels reframes discovery as a defensive necessity: you want your inventory to be more complete and more accurate than the picture Oracle can assemble from the outside. See how Oracle detects Java usage for the full picture.

Building an audit-ready inventory

The output of discovery should be a single, defensible record. An audit-ready Java inventory has these properties:

• Complete. Covers servers, desktops, VMs, containers, appliances, and non-production and dormant hosts. Snapshots and DR replicas included.
• Attributed. Every entry records vendor, exact build, licence basis, location, installation type and source.
• Classified. Each install is marked free (covered by NFTC, BCL public use, or a free distribution), licensed (genuinely covered by an entitlement), or exposure (requires a subscription and is not covered).
• Evidenced. Findings are backed by scan output and command results that can withstand scrutiny.
• Current. Dated, and refreshed on a schedule — an estate changes constantly, and a year-old inventory is a liability.

This inventory is the asset that drives everything else: it sizes your true exposure, it underpins an audit defence, it scopes a migration, and it gives you facts to negotiate against. The discipline of keeping it current is the core of a continuous Java management programme.

Common discovery pitfalls

• Stopping at production. Test, development, training and DR environments run Oracle JDK too, and they count. A production-only scan understates exposure.
• Trusting java -version alone. It reports only the path Java. Multiple JDKs per host are routine and are missed by a single command.
• Ignoring bundled Java. Application-bundled and appliance-embedded Java is the most-missed category — and the responsibility for it depends entirely on the vendor's distribution rights.
• Treating scan output as a conclusion. Raw SAM data overstates exposure. It needs licensing interpretation before it means anything.
• Discovering once. A one-off inventory decays immediately. Estates change; discovery must be continuous.
• Running Oracle's scripts unprepared. Returning Oracle's script output before completing your own analysis hands Oracle control of the numbers.

Frequently asked questions

Do I need a paid tool to discover Java?

Not to start. Native methods — the version command, filesystem search, package and registry inventory, image inspection — cover real ground. Paid SAM and discovery tools add breadth and automation, which matters at scale, but interpretation still requires licensing expertise.

Will a SAM tool tell me if I owe Oracle money?

No. A SAM tool reports what Java is installed. Whether a given build triggers a subscription depends on its exact version, its licence terms and your contract — an analysis the tool does not perform.

Should I run Oracle's discovery scripts?

Only after completing your own independent inventory, and only after reviewing exactly what the output contains. Oracle's scripts feed Oracle's claim; never return raw output unprepared.

How does Oracle know what Java we use?

Through download records, update telemetry, support and account history, and your own answers to soft-audit questionnaires. Oracle can form a view without ever touching your network.

How often should we run discovery?

Continuously, or at minimum on a regular schedule. Estates change constantly; a stale inventory is worse than none because it creates false confidence.

Conclusion

Java discovery is not a technical formality — it is the single most important act of self-defence in Oracle Java licensing. The organisation that knows exactly what Java it runs, down to the build and the licence basis, controls every conversation that follows: it can size its exposure honestly, defend an audit on facts, scope a migration precisely and negotiate from a position of knowledge. The organisation that does not is at the mercy of Oracle's numbers. Start with native methods, scale with SAM tooling, interpret with licensing expertise, and keep the inventory continuously current. Find your Java before Oracle does — that single discipline is worth more than any tool.