Oracle Java Audit Scripts: What They Are and How They Work

What Is the Oracle LMS Collection Tool?

The Oracle LMS Collection Tool — where LMS stands for License Management Services, the predecessor to Oracle's current Global Licensing and Advisory Services (GLAS) function — is a bundle of scripts that Oracle provides during a software compliance review. For Java-specific audits, Oracle provides a subset of these tools focused on discovering and characterising Java installations across your environment.

The scripts are typically delivered as a compressed archive (ZIP file) accompanied by a deployment guide. They are written in a combination of shell script (for Unix and Linux systems) and PowerShell or VBScript (for Windows systems), and they include read-only queries that scan your servers, collect installation data, and produce output files that are then submitted to Oracle's GLAS team for analysis.

Oracle characterises the scripts as diagnostics that collect information without modifying your systems. This is generally accurate — the scripts are not designed to make changes to your environment. However, "generally accurate" is not the same as "guaranteed," and your technical team should verify this claim independently before running the scripts in a production environment.

How Oracle's Scripts Discover Java Installations

The core function of Oracle's Java discovery module is to find every Java installation on every server in your estate. The discovery mechanism operates at two levels: filesystem scanning and registry inspection (on Windows).

Filesystem Scanning

On Unix and Linux systems, Oracle's scripts use standard operating system commands to search the filesystem for Java executable files. Common search patterns include searching for files named java in directories like /usr/bin, /usr/local/bin, /opt/java, and subdirectories under /usr/lib/jvm. The scripts may also search for JAVA_HOME environment variables that point to a Java installation directory.

The discovery is typically broad — it searches the entire filesystem or a wide set of likely directories rather than a predefined list of known installation paths. This breadth means the scripts may identify Java installations that are inactive, orphaned, or part of applications that were never in regular use.

Windows Registry Inspection

On Windows systems, in addition to filesystem scanning, Oracle's scripts query the Windows registry for Java version and installation information. The registry paths under HKLM\SOFTWARE\JavaSoft record Oracle Java installations as part of the standard installer process. This makes Windows discovery particularly reliable from Oracle's perspective: any Oracle Java that was installed using Oracle's standard installer will have left a registry entry that the scripts will find.

OpenJDK distributions installed via third-party installers may also write registry entries, but typically under different paths. The script's ability to distinguish Oracle Java from OpenJDK at the registry level depends on whether the distribution's installer writes Oracle-compatible registry keys, which most reputable distributions do not.

Version and Vendor Identification

For each Java executable discovered, the scripts execute the command java -version and capture the output. The version output contains information that identifies both the Java version number and — in most cases — the distribution vendor. Oracle Java's version output typically includes text like "Java HotSpot(TM) 64-Bit Server VM" and references to Oracle Corporation. OpenJDK distributions produce output that includes "OpenJDK" in the VM name and the distribution vendor's identifier.

However, version string interpretation is not always unambiguous. Older versions of Oracle Java (Java 8 updates from before 2019, in particular) used version strings that look similar to some OpenJDK distributions. In heterogeneous environments where both Oracle Java and OpenJDK are installed alongside each other, misclassification is possible. This is one of the key technical challenges in an Oracle Java audit: ensuring that OpenJDK installations are accurately excluded from the Oracle count, even when the version strings are ambiguous.

What Data the Scripts Actually Collect

Beyond the Java discovery function, Oracle's collection scripts gather additional data that Oracle uses to establish the licence requirement and context for the audit report. The standard Java audit data collection includes the following categories:

Installation Data

For each Java installation discovered, the scripts record the installation path, the Java version (major version and update number), the vendor identification from the version string, the installation date where available, and whether the installation is a JDK (Java Development Kit — intended for development) or a JRE (Java Runtime Environment — intended for running applications).

The JDK versus JRE distinction matters for some legacy licence metrics, though under the Universal Subscription model introduced in January 2023, both are in scope regardless of whether they are development or production installations.

Server Infrastructure Data

Oracle's scripts collect information about the server hardware and virtualisation layer. This includes hostname, operating system version, CPU architecture, number of physical processors, and — for virtualised environments — information about the virtualisation technology in use. This infrastructure data feeds into the licence metric calculation: some legacy Oracle Java metrics were processor-based rather than employee-based, and Oracle may use this information to calculate what your historical licence requirement would have been.

Active Use Indicators

In some versions of Oracle's collection scripts, the tools attempt to determine whether each Java installation is actively in use — for example, by checking whether the Java process appears in a list of running processes at the time the script is executed, or by examining application log files. This active-use data is less reliable than the installation inventory and is more likely to produce inconsistencies between Oracle's count and your internal data.

What the Scripts Do Not (and Should Not) Collect

Oracle's Java audit scripts, when correctly scoped for a Java-only compliance review, should collect only Java-related data. They should not collect information about Oracle Database installations, Oracle middleware products, Oracle applications, or other software on your servers unless the audit has been explicitly scoped to include those products.

In practice, you should review Oracle's scripts before deployment to verify that they are scoped as represented. If you find that scripts supplied for a Java audit are collecting data that goes beyond Java — scanning for Oracle Database version information, collecting Oracle Home directories, or querying for Oracle middleware installations — you have grounds to request a revised script set that is limited to the Java scope.

This is not a hypothetical concern. In some engagements, organisations have deployed Oracle's Java collection scripts only to find that Oracle subsequently raised compliance issues related to other Oracle products that the scripts incidentally collected data on. Reviewing the scripts before deployment is a practical necessity, not a bureaucratic precaution.

The Download Records Problem

Oracle's audit scripts are one data source. Oracle also maintains a separate and significant data source: its download records. Since 2019, when Oracle made the Oracle JDK free to download for development but required a commercial subscription for production use, Oracle has logged every download of its Java installers — including IP addresses, timestamps, and in many cases email addresses associated with Oracle Technology Network (OTN) accounts.

Oracle's GLAS team uses these download records as a cross-reference tool. When your data submission shows a certain number of Oracle Java installations, Oracle will compare that count against its records of how many Oracle Java installers were downloaded from your IP address ranges. If the download records suggest a significantly larger deployment than your submitted data shows, Oracle will ask for explanations — and the download records can be used to support a claim that installation counts were understated.

The implication for your audit response is that if you have migrated Oracle Java installations to OpenJDK alternatives since receiving the audit notice, you should document those migrations with specific dates and details. Oracle may challenge a submission that shows fewer installations than its download records suggest — your migration documentation is the evidence that resolves the discrepancy in your favour.

Running the Scripts: Recommended Process

When Oracle requests that you run its collection scripts, following a structured process protects your interests and improves the quality of the data you submit.

Step 1: Request and Review the Scripts

Ask Oracle to provide the scripts before you agree to run them. Oracle should be willing to share the scripts in advance — they are not proprietary secrets, and many versions are publicly available for inspection. Have your technical team review the script source code to confirm it is read-only and to understand exactly what data will be collected. If the scripts exceed the Java scope, request a revised version.

Step 2: Run in a Test Environment First

Before deploying the scripts across your production estate, run them on a representative test environment. This confirms that the scripts execute without errors in your specific platform and OS configuration, allows you to review the output files before they contain your full production data, and identifies any environment-specific issues — such as permission requirements or network access restrictions — that need to be resolved before production deployment.

Step 3: Run Your Own Discovery in Parallel

Simultaneously with reviewing Oracle's scripts, run your own Java discovery using your software asset management (SAM) tool or a purpose-built discovery tool. The objective is to produce your own count of Oracle Java installations — categorised by version and distinguished from OpenJDK — before Oracle's scripts produce theirs. Comparing your internal discovery results with Oracle's output tells you whether Oracle's scripts are correctly categorising all installations and whether there are discrepancies you need to address.

Step 4: Remediate Before Running in Production

If your internal discovery identifies Oracle Java installations that can be migrated to OpenJDK before you run Oracle's collection scripts in production, migrate them. This is particularly applicable to development, test, and non-critical production systems. Documented migrations reduce the scope of Oracle's count and therefore reduce the claimed licence requirement. See our audit response guide for the full remediation process.

Step 5: Submit with a Covering Statement

When you submit Oracle's script output, accompany it with a covering statement that describes your methodology, identifies any OpenJDK installations that are explicitly excluded, and notes any known limitations or coverage gaps (for example, servers that were unavailable during the scan period). The covering statement creates a documented baseline for your position that Oracle must respond to — rather than simply asserting its own interpretation of the data.

Handling Misclassified Installations

One of the most commercially significant issues in Oracle Java audits is the misclassification of OpenJDK installations as Oracle Java. If Oracle's scripts flag an OpenJDK distribution as Oracle Java SE, and that misclassification is not corrected before Oracle produces its audit report, the installation contributes to the claimed shortfall — and therefore to Oracle's licence demand — when it should not be in scope at all.

Common misclassification scenarios include Amazon Corretto installations on older versions where the version string includes "HotSpot" without clearly identifying Amazon, Eclipse Temurin installations on systems with multiple JDKs where Oracle's discovery picks up the wrong binary, and OpenJDK installations embedded within third-party application servers where the JDK vendor is not immediately apparent from the filesystem path.

For every installation flagged by Oracle's scripts that you believe is an OpenJDK distribution, provide Oracle with the specific evidence: the installation path, the full output of java -version, any embedded distribution metadata files (such as the release file in the JDK root directory that identifies the distribution), and documentation of the application it serves. Oracle's GLAS team is technically capable of verifying this evidence, and correctly documented OpenJDK installations should be accepted as out of scope.

After the Scripts: What Happens to Your Data

Once you submit Oracle's script output, Oracle's GLAS team processes the data and cross-references it against Oracle's records — including your contract history, your support entitlements, and the download records discussed above. Oracle then produces an audit report that states what it believes your Oracle Java licence requirement is, what it believes you have contracted, and the resulting gap.

As described in our negotiation tactics guide, this audit report is Oracle's opening commercial position. The technical challenge process — which uses the detailed data you now understand from this guide — is the primary mechanism for reducing the claimed shortfall before any commercial negotiation begins.

Oracle's annual support fees increase by 8% per year under standard support terms. Any Java SE subscription that results from the audit settlement will be subject to this 8% annual increase compounding over the term of the agreement. Understanding the full cost implications of any settlement requires modelling the total subscription cost with this annual escalation applied.

Conclusion

Oracle's Java audit scripts are a powerful data collection tool that Oracle uses to establish the factual basis for its compliance claims. Understanding what the scripts collect — Java installation data, infrastructure context, and active-use indicators — allows you to prepare your own internal data in advance, identify potential misclassifications, and ensure that OpenJDK installations are correctly excluded from Oracle's count.

The most important principle is straightforward: know what Oracle's scripts will find before Oracle finds it. Run your own discovery first, review Oracle's scripts before deploying them, remediate where possible, and submit with a covering statement that documents your position. This sequence consistently produces better audit outcomes than organisations that simply run Oracle's scripts and wait for the result.

Redress Compliance provides technical script review, internal Java inventory support, and end-to-end Oracle Java audit defence. We work exclusively on the buyer side with no commercial relationship with Oracle.