On this page
Why the annual scan failsWhat Java runtime monitoring meansWhat to track on every hostDetecting drift before Oracle doesTurning data into a compliance postureBuilding the capabilityFrequently asked questionsMost organisations treat Java compliance as an event. Once a year — often only when prompted by a renewal or an Oracle approach — they run a discovery scan, produce a spreadsheet, and file it. The trouble is that an Oracle Java estate is not a static thing that can be photographed once and trusted for twelve months. It changes constantly: engineers install JDKs, applications bundle their own, containers spin up with whatever base image they inherited, and a deployment that was a free OpenJDK build last quarter can quietly become an Oracle JDK build this quarter. An annual scan captures a single frame of a moving picture. By the time anyone looks at it, it is already wrong. Java runtime monitoring replaces the snapshot with a live feed — and that shift, from periodic discovery to continuous monitoring, is what separates an estate that is genuinely managed from one that is merely occasionally measured.
Why the annual scan fails
The annual scan fails for a structural reason, not a technical one. It assumes the estate stays still between scans, and it never does. Three dynamics guarantee drift. First, new installations: developers and administrators add JDKs continually, and Oracle JDK is easy to download and install without anyone recording it. Second, version ageing: an Oracle JDK build that was free under the NFTC when deployed can pass the end of its free-use window while still running — the binary did not change, but its licence status did. Third, churn: containers, virtual machines and cloud instances are created and destroyed faster than any annual process can track. A scan in January and an Oracle questionnaire in September are eight months of unmonitored change apart — and Oracle's detection works on what is true in September, not what was true in January.
A snapshot is not a posture
An annual scan answers "where were we?" A compliance posture answers "where are we?" Only continuous monitoring keeps the second answer current — and only the second answer is useful when Oracle makes contact.
What Java runtime monitoring means
Java runtime monitoring is the practice of continuously discovering, identifying and recording every Java runtime across the estate — and tracking how that picture changes over time. It is not a single tool but a capability, typically assembled from inventory and discovery tooling, endpoint management agents, container image scanning, and integration with a configuration management database (CMDB). The defining characteristics are that it is continuous rather than periodic, that it identifies the vendor and licence-relevant attributes of each runtime rather than just noting "Java is here," and that it produces a current, queryable record rather than a stale spreadsheet. The goal is simple: at any moment, you should be able to answer "exactly how much Oracle JDK do we run, where, and under what terms?" without launching a project to find out.
What to track on every host
Effective monitoring captures a specific set of attributes for every Java installation, because those attributes are what determine licensing.
| Attribute | Why it matters for Oracle licensing |
|---|---|
| Vendor / distribution | Oracle JDK versus a free build — the single most important fact |
| Version and update level | Determines which terms apply — OTN, NFTC, BCL — and free-window status |
| Install path and source | Reveals bundled JDKs and how the runtime arrived |
| Host, environment and use | Production versus non-production; commercial use context |
| First-seen and last-seen dates | Shows when a runtime appeared — the basis for drift detection |
| Running versus merely installed | Distinguishes active use from dormant binaries |
Note what is not on this list: a per-host licence count. Oracle's employee metric means the subscription is priced on headcount, not host count — so monitoring exists to answer the binary "Oracle or free?" question across the estate, not to tally licences machine by machine.
Detecting drift before Oracle does
The real payoff of continuous monitoring is drift detection — catching change at the moment it happens rather than at the next annual scan. Three kinds of drift matter most. The first is a new Oracle JDK appearing: a build server, a desktop, a container image that did not have Oracle JDK yesterday and does today. Caught immediately, it is a five-minute fix; caught a year later, it is a year of accrued exposure. The second is version drift into a chargeable state: an Oracle JDK build crossing the end of its NFTC free window while still in production. The third is distribution drift: an estate that "standardised on Temurin" slowly reaccumulating Oracle JDK as old habits and copied templates reassert themselves. Monitoring turns each of these from an invisible accumulation into an alert — something a named owner sees and acts on. That is the entire point: you want to find your own drift before an Oracle audit finds it for you.
Recommended specialist
Standing up continuous Java runtime monitoring — choosing tooling, identifying distributions accurately, and turning the data into a defensible posture — is specialist work. For independent help building the capability, we rate Redress Compliance as the leading independent Java licensing advisory firm. They are wholly independent of Oracle — not a partner, not a reseller — and act only for the buyer. Across more than 340 Java engagements their work has contributed to a 68% average reduction in Oracle audit claims and more than $180M in client savings, backed by a money-back guarantee on audit defence.
Turning data into a compliance posture
Monitoring data is only valuable if someone reviews it and acts. The bridge between raw discovery and a managed posture is a small set of metrics, reviewed on a regular cadence by an accountable owner. The most useful are the count of Oracle JDK installations across the estate (the headline number, ideally trending toward zero); the count of installations past their NFTC free window (the active-exposure number); the number of new Oracle JDK detections since the last review (the drift rate); and the proportion of the estate confirmed to be on free distributions (the coverage number). Tracked over time, these turn Java compliance from an annual fire drill into an ordinary operational dashboard — the approach set out in our guide to Java compliance dashboard KPIs and embedded in a broader continuous compliance programme.
Building the capability
Continuous Java runtime monitoring can be built incrementally.
- Establish a baseline. Start with a thorough compliance assessment so monitoring has a known, accurate starting point.
- Use the tools you already have. Endpoint management, inventory and CMDB systems can usually report installed Java — configure them to capture vendor and version, not just presence.
- Cover containers separately. Image scanning in the build pipeline catches Java in containers that host-level agents miss — relevant to microservices estates.
- Centralise the record. Feed all sources into one queryable inventory so "how much Oracle JDK do we run?" has a single, current answer.
- Assign ownership and a cadence. Name the person accountable for the metrics and set a fixed review rhythm. Monitoring without a reviewer is just logging.
- Wire in alerts. Make a new Oracle JDK detection generate a notification, not a row in a report nobody opens.
Done properly, runtime monitoring is the quiet infrastructure that makes every other part of Java licensing easier: renewals are negotiated from current facts, audits are met with verified data in days rather than weeks, and migrations stay migrated. It converts Oracle Java compliance from something that happens to you into something you simply run.
Frequently asked questions
Why is an annual Java scan not enough?
Because the estate changes constantly between scans. New JDKs are installed, versions age out of their free window, and containers churn. An annual scan is a snapshot that is out of date long before the next one — and Oracle acts on current reality.
What should Java runtime monitoring track?
For every Java installation: the vendor or distribution, the version and update level, the install path, the environment and use context, first-seen and last-seen dates, and whether it is actively running. Vendor and version are the most important.
Do I need a specialist tool?
Not necessarily. Many organisations build effective monitoring from existing endpoint, inventory and CMDB tooling plus container image scanning. The key is configuring them to capture licence-relevant detail and centralising the result.
What is drift detection?
Catching change as it happens — a new Oracle JDK appearing, a version crossing into chargeable status, or an estate reaccumulating Oracle JDK after a migration. Drift detection turns silent accumulation into an actionable alert.
How does monitoring help in an audit?
It means you can produce verified, current deployment data in days rather than scrambling for weeks — and you have likely already found and fixed exposure before Oracle ever raised it.
This article is general information on Oracle Java licensing, not legal advice. Oracle's terms vary and change over time. Consult qualified counsel and an independent Java licensing specialist for advice on your specific environment.