📋 Executive Summary
When Oracle conducts a Java license audit, one of the most critical — and misunderstood — elements is the request to run their LMS/GLAS Collection Tool scripts. These automated diagnostics scan your entire environment for Oracle Java installations, capture version details, and generate the evidence Oracle uses to build compliance claims. With Oracle aggressively enforcing the Java SE Universal Subscription (employee-based model at ~$15/user/month) and Gartner predicting that 1 in 5 Java-using organizations will face an audit by 2026, understanding these scripts is no longer optional — it's essential audit defense.
This guide explains exactly what the scripts do, what data they collect, how Oracle uses the results, and — most importantly — how to handle script requests in a way that protects your organization's interests. Whether you're facing a formal Java audit or a soft audit inquiry, this playbook is your preparation guide.
📑 Table of Contents
- What Are Oracle's Java Audit Scripts?
- How the Scripts Work — Technical Overview
- What Data Oracle Collects and Why
- Oracle's Motives and Use of Script Data
- Best Practices for Handling Audit Script Requests
- Alternatives: Proactive Self-Assessment
- 2026 Context: Escalating Java Enforcement
- Recommendations
- Frequently Asked Questions
1. What Are Oracle's Java Audit Scripts?
Oracle's audit scripts are part of the broader Oracle LMS Collection Tool suite — scripts and programs provided by Oracle's Global Licensing and Advisory Services (GLAS, formerly LMS) team. They are designed to collect detailed data about Oracle software usage on your servers. For Java specifically, Oracle has included modules in these scripts to find and report on every Oracle Java installation across your environment.
Think of these scripts as Oracle's automated inventory tool during an audit. Rather than relying on manual customer-provided lists (which Oracle considers time-consuming and inaccurate), they use automated scanning to identify installations of Oracle products, including Java SE, across all accessible machines.
File System Scanning
Searches common installation paths (/usr/java, /opt/java, Program Files\Java, etc.) and checks Windows registry entries for installed JRE/JDK versions.
Version Identification
Executes java -version on each discovered instance to capture exact version, update level, and vendor (Oracle vs. OpenJDK).
Installation Inventory
Counts distinct Java binaries, identifies update levels, and checks for commercial features like Java Mission Control or Flight Recorder.
Output Generation
Produces log/CSV files that Oracle's auditors analyze to identify unlicensed installations and calculate compliance claims.
Importantly, these scripts are usually read-only diagnostics — they should not make changes to your system, only collect information. Oracle typically asserts that running them won't harm your systems. Nonetheless, caution is advised, and you should always review scripts before executing them in production environments.
Oracle's scripts are not publicly downloadable — they are provided specifically for audits or on special request. Oracle updates them approximately twice per year to account for new product versions and licensing rule changes. If presented with a script, always ask Oracle which version it is and whether it's the most current. An outdated script might erroneously flag something that is no longer an issue under updated rules. Our Java Audit Defense team reviews every script package our clients receive to ensure accuracy.
🛡️ Received a request to run Oracle's Java audit scripts? Don't execute until you've consulted experts.
Java Audit Defense →2. How the Scripts Work — Technical Overview
From a technical perspective, Oracle's Java audit script is part of a larger toolkit that can cover multiple Oracle products — databases, middleware, and Java. Understanding the mechanics helps you maintain control during the process.
Script Package Structure
Oracle typically provides a bundle (zip or tar file) containing scripts for various technologies. You may receive a single package that, when run, checks for all Oracle software. The package typically contains:
| Component | Platform | Purpose |
|---|---|---|
| Shell scripts (.sh) | Unix / Linux | Scan file system, execute version commands, enumerate packages |
| Batch files (.bat/.cmd) | Windows | Scan Program Files, read registry keys, capture version data |
| SQL scripts (.sql) | Database hosts | Query Oracle database configurations (not Java-specific, but often bundled) |
| Configuration files | All | Define scan paths, output formats, and product-specific parameters |
| Output templates | All | CSV/log file formats for structured data collection and submission |
The Scanning Process — Step by Step
Step 1: Installation Path Scanning
The script scans common Java installation directories across the file system. On Unix/Linux, this includes paths like /usr/java, /opt/java, /usr/lib/jvm, and any custom locations. On Windows, it reads the registry keys under HKLM\SOFTWARE\JavaSoft and searches Program Files\Java directories. The script also checks environment variables (JAVA_HOME, PATH) and looks at known indicators of Java — such as installed system packages (e.g., RPMs on Linux).
The goal is to locate every instance of Java on the server — not just the "primary" installation, but any secondary, bundled, or forgotten copies. This includes Java that came embedded with application servers like WebLogic or third-party applications.
Step 2: Edition & Vendor Identification
Once a Java installation is found, the script executes java -version or similar commands to capture the version string. This is crucial because the output reveals:
Oracle JDK/JRE output typically includes:
java version "1.8.0_381"
Java(TM) SE Runtime Environment (build 1.8.0_381-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.381-b09, mixed mode)OpenJDK output typically includes:
openjdk version "17.0.9" 2023-10-17
OpenJDK Runtime Environment (build 17.0.9+9)
OpenJDK 64-Bit Server VM (build 17.0.9+9, mixed mode)The "Java HotSpot(TM)" designation and the version/update number are what Oracle uses to determine if an installation requires a paid subscription. Oracle JDK 8 beyond update 202, for example, requires a commercial license. The script collects all this version data for every discovered instance.
Step 3: Counting, Summarization & Environmental Data
The script counts distinct Java installations per server and may attempt to identify whether binaries were recently executed (by checking file timestamps or scanning running processes). It enumerates every instance and correlates it with the number of physical or virtual servers — e.g., "Java installed on X out of Y servers scanned."
The scripts also capture environmental data: server hostname, CPU information, operating system, and hardware configuration. While not Java-specific, this data helps Oracle identify machines and cross-reference with licensing models. For the employee-based subscription model, CPU data is less relevant, but Oracle may check for commercial features like Java Mission Control or Flight Recorder, which historically indicated use of Oracle Java Advanced features under older licensing terms.
Step 4: Output Generation
The output is typically a set of text or CSV files. One file might list all Java versions found on each host. Another might summarize installation counts by version and vendor. Oracle's analysts load this data into their internal reporting tools to determine what requires licensing.
The output files are meant to be returned to Oracle via a secure audit portal. However — and this is critical — you should always review the output before sending it to Oracle. The raw data is your environment's information, and you have every right to verify its accuracy before submission. Our Java Advisory team analyzes script output for misidentifications and over-detections before any data reaches Oracle.
Oracle updates these scripts regularly (typically twice per year) to account for new Java versions and licensing rule changes. For instance, after Java 17's release with different licensing terms, the script was updated to detect Java 17+ installations. If you're presented with an older script version, it might erroneously flag installations that are no longer compliance issues under current rules. Always confirm you're running the most current version and document which version was used.
3. What Data Oracle Collects and Why
Understanding exactly what data the scripts collect — and what Oracle does with each data point — gives you control over the audit narrative.
| Data Point | How Collected | Why Oracle Wants It |
|---|---|---|
| Java version & update level | java -version output | Determines if the version requires a paid subscription (e.g., Oracle JDK 8u202+ requires license) |
| Vendor identification | Version string analysis (HotSpot vs. OpenJDK) | Distinguishes Oracle Java from free alternatives — only Oracle builds trigger compliance claims |
| Installation path | File system scan, registry | Identifies how many distinct installations exist, including forgotten or bundled copies |
| Server hostname | System command (hostname) | Maps Java installations to specific machines for cross-referencing with infrastructure data |
| CPU / hardware info | System commands, /proc/cpuinfo | Relevant for older per-processor metrics; less critical under employee model but still collected |
| Operating system | System identification | Platform context for accurate reporting and potential cross-product audit expansion |
| Running Java processes | Process listing (ps, tasklist) | May indicate active use vs. dormant installation — strengthens Oracle's compliance argument |
| Commercial features | Presence of Mission Control, Flight Recorder files | Under older licensing terms, these features required separate licensing; still flagged for completeness |
Scripts can and do overdetect or misclassify Java installations. Common examples include: flagging AdoptOpenJDK or Eclipse Temurin as Oracle Java; counting multiple entries for the same physical installation; detecting Java bundled with Oracle WebLogic or Oracle Database (which may carry different licensing rights); and finding old, unused Java versions on decommissioned-but-not-wiped systems. Never accept Oracle's script output at face value. Always review and validate results before submission. See our Java Compliance Assessment for expert analysis.
4. Oracle's Motives and Use of Script Data
Why does Oracle insist on running scripts? Because the data gives them a high-resolution view of your Java usage that you may not even be aware of. The scripts are Oracle's primary discovery mechanism for identifying what they call "compliance gaps" — areas where you're using more Oracle software than your entitlements cover.
How Oracle Builds the Compliance Claim
Oracle's auditors follow a predictable pattern with script data:
Typical Oracle Audit Claim Construction
1. Discovery: "We found 120 installations of Oracle Java across 80 servers."
2. Entitlement check: "You have zero active Java SE subscriptions."
3. Employee-model application: "Under the Java SE Universal Subscription, your 5,000 employees require licensing."
4. Back-fee calculation: "You owe subscriptions for all employees for the past 2 years = $1.8M in back fees plus ongoing subscription costs."
5. Resolution pitch: "However, if you sign a 3-year subscription now, we can discuss a resolution."
The scripts tilt the playing field in Oracle's favor: they know exactly what to look for and where, whereas many customers are caught off guard by how much Oracle Java is discovered. One common scenario is Java found in places the customer didn't expect — bundled with an application server, embedded in a third-party product, or left on a retired system that was never properly decommissioned.
Oracle's standard audit clauses now explicitly require customers to run Oracle's data measurement tools and provide the results. In practice, this means if you're formally audited, you will be asked (or contractually required) to run the LMS Collection Tool. This is why proactive self-assessment before an audit arrives is so valuable — you get the same data Oracle would, but with time to remediate issues before Oracle sees them. Organizations that have already migrated to OpenJDK and cleaned up legacy installations face far less exposure when audit scripts run.
📋 Don't let Oracle build the narrative. Our team reviews script output, identifies misclassifications, and builds your defense position before you respond.
Java Advisory →5. Best Practices for Handling Audit Script Requests
If Oracle requests that you run their audit scripts — whether during a formal audit or a soft audit — here are the best practices for protecting your organization:
1. Negotiate Scope in Writing Before Running Anything
Before executing any script, ensure you have a written agreement with Oracle on scope. Specify which systems the script will run on. You typically want to limit it to only those systems reasonably expected to have Java — not a blanket "run everywhere" sweep. Oracle will push for all servers, but you can negotiate. For example: run on all servers and a representative sample of desktops, but exclude network devices or systems confirmed to be Java-free.
Also clarify the timeframe: the script runs once, data is collected, and that's it. No ongoing access. And ensure an NDA is in place so Oracle cannot use data outside the audit scope — particularly for sales lead generation within other Oracle divisions.
2. Review the Script Code Internally Before Execution
Ask Oracle to provide the script files in advance — ideally human-readable shell scripts, not opaque binaries. Have your IT security team and system administrators review the code to confirm it's safe (no deletion commands, no external data transmission, no modification of system settings). This review sometimes also reveals exactly what Oracle is looking for — if you see the script searching certain paths, you know where Oracle thinks Java might be located.
If Oracle provides a binary-only tool, request documentation of what it does. You have the right to understand what runs in your production environment.
3. Run in a Test Environment First
If feasible, run the scripts on a test system or representative subset of servers first. This accomplishes two things: it ensures the scripts don't disrupt production operations (while typically lightweight, scripts can briefly spike CPU when scanning large file systems), and it gives you a preview of findings before running on your full estate. If the test reveals unexpected Java installations, you have time to investigate and potentially remediate before the full scan.
4. Monitor and Supervise Execution
When running in production, supervise the process directly. Run during a maintenance window if possible. Follow Oracle's instructions precisely so they can't claim the scan was performed incorrectly, but don't use the most invasive options if Oracle provides alternatives. For example, if the script offers options to scan specific directories only, use those options rather than allowing an unrestricted full-disk scan.
Ensure your team runs the script — never allow Oracle personnel direct access to your systems. Oracle depends on your IT staff to execute the scripts and return the output.
5. Capture, Review, and Validate All Output Before Submission
After running the scripts, you will have output files (logs, CSVs, etc.). Secure copies for yourself immediately. Do not send anything to Oracle without thorough review. This is your environment's data — you have every right to see it first.
Go through the results carefully, ideally with an independent licensing expert. Look for:
• Misidentifications: OpenJDK flagged as Oracle Java (AdoptOpenJDK, Eclipse Temurin, Amazon Corretto, etc.)
• Duplicates: Multiple entries for the same physical installation
• Bundled Java: Oracle Java embedded with Oracle Database or WebLogic — which may carry different licensing rights
• Decommissioned systems: Old Java on retired servers that were never cleaned up
• Development/test instances: Non-production Java that may have different licensing implications
Proactively correct misidentifications before responding to Oracle: "We reviewed the data and noted that 15 entries are non-Oracle Java distributions; here are the details…"
6. Limit Data to the Agreed Scope
Provide Oracle only with the requested data and nothing more. If the script collects broad information by default (e.g., a list of all installed software on the server — the LMS tools sometimes conduct broad sweeps), filter the output and only provide Java-specific information. There is no need to hand over unrelated software inventory data that could prompt questions beyond Java's scope or trigger additional audit inquiries for other Oracle products.
If Oracle insists on raw, unfiltered output, ensure the audit NDA explicitly prevents Oracle from using any data outside the agreed audit scope.
In a formal audit, your Oracle contract likely requires you to cooperate with Oracle's data collection tools. You may not be able to refuse to run the scripts entirely, but you can negotiate scope, timing, and review procedures. In a soft audit (informal review or "license health check"), you are not obligated to run Oracle's scripts. You can choose to provide your own scan data instead, or decline entirely. Be especially cautious with "free assessment" offers — these are often fishing expeditions that can rapidly escalate to formal audits if any potential gaps are uncovered. Consult your legal counsel on your specific contractual obligations before running any Oracle-provided tools.
6. Alternatives: Proactive Self-Assessment
One powerful strategy is to run Oracle's audit scripts on your own before an audit arrives — or use equivalent third-party tools to conduct an independent self-assessment. Licensing experts can interpret the script output to determine your compliance position, giving you the same data Oracle would get, plus time to remediate.
Run Oracle's Scripts Internally
You can request Oracle's LMS Collection Tool proactively (or obtain it through your Oracle account). Running it internally gives you visibility into what Oracle would find, allowing you to uninstall unlicensed Java, migrate to OpenJDK, or document your compliance position before any audit.
Use Third-Party SAM Tools
Software Asset Management tools from vendors like Flexera, Snow, and Certero now include specific Oracle Java discovery capabilities. Some (like Certero) are Oracle LMS/GLAS-verified, meaning Oracle's audit team can accept their data during official audits. This provides continuous visibility without needing Oracle's scripts.
Engage Independent Experts
Our Java Compliance Assessment service runs comprehensive discovery, interprets results against current licensing rules, and provides a detailed compliance report with remediation recommendations — all before Oracle contacts you.
Build Continuous Monitoring
Rather than one-time scans, implement ongoing Java monitoring. Include Java version checks in your configuration management (Ansible, Puppet, SCCM) and establish alerts when new Oracle Java installations appear. This prevents "shadow Java" from accumulating unnoticed.
Proactive Assessment — Real-World Outcome
A 3,000-employee manufacturing company engaged our Java Compliance Assessment service proactively. Running discovery scripts internally, we found 87 Oracle Java installations across 54 servers. Upon analysis: 23 were misidentified OpenJDK builds, 18 were Java bundled with Oracle Database (covered under existing database licenses), 31 were obsolete installations on decommissioned workloads, and only 15 required remediation — which was accomplished by migrating to Eclipse Temurin within 4 weeks. When Oracle's soft audit inquiry arrived 3 months later, the company confidently responded with a clean environment and documented compliance position. Potential exposure avoided: $540,000/year in subscription costs.
7. 2026 Context: Escalating Java Enforcement
Java audit script handling has become more critical than ever in 2025–2026. Oracle's Java enforcement has intensified dramatically, driven by the transition to the employee-based licensing model and Oracle's focus on Java as a major revenue stream.
Employee-Based Model Amplifies Script Impact
Under the Java SE Universal Subscription (introduced January 2023), Oracle charges based on total employee count — not the number of Java installations. This means even a single Oracle Java installation found by audit scripts triggers licensing obligations for your entire workforce. A company with 5,000 employees would owe approximately $900,000 per year (5,000 × $15 × 12) regardless of whether 1 or 1,000 servers have Java. This makes script results far more consequential than under the previous per-processor or Named User Plus models.
Key implication: Removing or replacing every Oracle Java installation before an audit runs is the most effective defense. Even one missed installation on a forgotten server can trigger organization-wide licensing. Our Java Advisory clients prioritize comprehensive cleanup before any Oracle engagement.
Audit Volume Increasing — 1 in 5 Predicted by 2026
Industry analysts predict that at least 20% of organizations using Java will face an Oracle audit by 2026. Oracle has dramatically ramped up both formal audits (via GLAS/LMS with full script deployment) and soft audits (via sales teams offering "Java usage reviews"). The line between a friendly license discussion and a formal audit has blurred — every Oracle inquiry about Java is effectively a pre-audit signal.
Oracle also increasingly uses third-party partners via its Joint Partner Engagement program, particularly in EMEA and APAC regions. These partners are typically Oracle resellers who earn commissions on any licenses you must purchase — creating a conflict of interest that CIOs should be aware of.
Scripts Now Cover Java 17+ and Modern Distributions
Oracle's latest Collection Tool versions have been updated to detect Java 17, 21, and subsequent LTS releases, each of which has different licensing implications. Java 17 was released under a modified license that permitted free use in production until the next LTS (Java 21), after which it reverted to requiring a subscription. Java 21+ is free under the Oracle No-Fee Terms and Conditions (NFTC) license for the current release, but organizations on older versions may still face exposure.
The scripts now also better distinguish between Oracle GraalVM (commercial), Oracle JDK, and Oracle OpenJDK builds — each with different licensing status. Understanding these distinctions is essential for interpreting script results accurately. Consult our Java licensing changes guide for the latest model details.
🚨 Java is now Oracle's top audit focus area. Don't wait for the inquiry — assess your exposure proactively.
Java Compliance Assessment →8. Recommendations
✅ Java Audit Script Action Plan
- Develop an internal "audit script playbook." Document procedures for scope negotiation, internal review, execution, and analysis. Ensure IT staff have guidance to follow rather than responding ad hoc under pressure.
- Train your team on the chain of command. If anyone from Oracle requests to run a script or tool on production systems, it must go through your centralized compliance manager. Prevent well-meaning administrators from running tools as informal favors for Oracle representatives.
- Run self-assessment scans regularly. Use Oracle's scripts internally (or third-party SAM tools) to maintain continuous visibility into your Java estate. Quarterly scans prevent "shadow Java" from accumulating unnoticed.
- Maintain a clean environment. Regularly remove outdated or unused Oracle Java. Uninstall Java from any server that no longer needs it. The fewer Oracle Java instances the scripts find, the less Oracle has to work with. Consider enterprise-wide migration to OpenJDK alternatives.
- Never submit raw script output without review. Always capture results, validate for misidentifications, correct errors, and have an independent expert review before sending anything to Oracle.
- Validate results with licensing experts. Experts can differentiate between "Java bundled with Oracle WebLogic" (covered under different rights) and "standalone Oracle Java requiring separate subscription." This distinction can mean millions in avoided costs.
- Limit data provided to scope. Filter output to Java-only information. Don't volunteer unrelated software inventory that could expand the audit. Ensure your NDA prevents Oracle from using data outside the agreed scope.
- In soft audits, control the process entirely. You are not obligated to run Oracle's scripts during informal reviews. Provide your own scan data on your terms, or decline the review entirely if the timing isn't right.
- Monitor Oracle's script versioning. Confirm you're running the most current version. Outdated scripts may flag false positives. Document which script version was used for audit trail purposes.
- Engage independent audit defense early. Our Java Audit Defense team has reviewed hundreds of LMS script packages. We know what Oracle looks for, where scripts overdetect, and how to build the strongest compliance position before Oracle's auditors draw conclusions.
Frequently Asked Questions
java -version output showing "OpenJDK Runtime Environment") and proactively correct the data before submitting to Oracle. Respond with specifics: "We reviewed the data and noted that entries #12, #23, and #41 are Eclipse Temurin (OpenJDK) distributions, not Oracle Java — here is the documentation." This forces Oracle to accept your corrections. Our Java Compliance Assessment specifically audits for misidentifications before any data reaches Oracle.Related Oracle Articles
Explore more articles in this topic area:
Case Study 192m Saved on Java Licensing for a US Pharmaceutical Company
Case Study
Case Study Java Advisory Services Aegean Airlines 2m Claim Resolved at Z...
Case Study
Case Study Java Advisory Services Avis Car Rental 4 7m Claim Resolved at...
Case Study
Case Study Java Advisory Services Crown Equipment 4m Claim Resolved at Z...
Case Study
Case Study Java Advisory Services Csaa Insurance 1 5m Claim Resolved at ...
Case Study
Case Study Java Advisory Services Homebridge 700k Claim Resolved at Zero...
Case Study
Don't Face Oracle's Java Audit Scripts Alone
Our Java audit defense experts have reviewed hundreds of LMS script packages. We know what Oracle looks for, where scripts overdetect, and how to protect your organization.
Related Resources
Java Licensing & Audit Defense Case Studies
How we help enterprises eliminate risk and save millions on Java compliance.
ArticleJava Audit: What You Can Expect
Step-by-step walkthrough of Oracle's Java audit process and how to prepare.
ArticleSoft vs. Formal Java Audits
Key differences between Oracle's informal reviews and formal LMS audits.
ArticleCommon Java Audit Triggers
What prompts Oracle to audit your Java and how to minimize risk.
ArticleAlternative Java Options: OpenJDK & Others
Exploring free Java distributions to reduce Oracle licensing exposure.
ArticleJava Licensing Changes: Top 20 Insights for 2026
Employee-based model strategies, audit defense, and renewal tactics.
ArticleOracle Java SE Licensing Changes
Evolution from free downloads to the Universal Subscription employee model.
ArticleOracle LMS Collection Tool: Comprehensive Guide
Full guide to Oracle's audit scripts — risks, best practices, and CIO strategies.
ArticleOracle Audit Trends & Key Focus Areas
Current audit trends for 2025–2026 and how to stay compliant.
Knowledge HubOracle Licensing Knowledge Hub
Complete resource library for Oracle licensing guidance and advisories.
Fredrik Filipsson
Fredrik Filipsson brings over 20 years of experience in enterprise software licensing, including direct roles at IBM, SAP, and Oracle. As co-founder of Redress Compliance, he has helped hundreds of Fortune 500 organizations navigate Oracle audits, optimize Java licensing, and secure favorable terms with major software vendors.