Java compliance risks: the top 10 exposure points.

Oracle Java exposure is rarely the result of a deliberate decision to under-license. It accumulates quietly — a JDK pulled in as a dependency, an NFTC window that quietly expired, a forgotten developer install. This guide ranks the ten exposure points that most often become real audit claims, and explains how to close each one before Oracle finds it first.

Why exposure hides

Java exposure is hard to see for three structural reasons. First, Java is everywhere — it runs application servers, middleware, batch jobs, desktop tools, and embedded components, often invisibly. Second, the licence depends on build and version, two facts that no one records by default. Third, since the 2023 employee metric, a single non-compliant install is priced against your entire workforce, so even tiny gaps carry large claims.

The result is that most organisations genuinely do not know their Java position. The ten risks below are where the gap between belief and reality is widest.

1. OTN-licensed Oracle JDK 11 in production

This is the single most common exposure point. Oracle JDK 11 was distributed under the Oracle Technology Network (OTN) licence, which permits free development and testing but explicitly forbids free production use. Because Oracle JDK 11 downloads as freely as any other build, organisations deploy it into production without realising a subscription is required.

How to close it: identify every Oracle JDK 11 installation, separate genuine production use from dev/test, and either migrate production instances to a free OpenJDK 11 build or bring them under a subscription. This one risk alone accounts for a large share of seven-figure Java claims.

2. Oracle JDK 8 past its free window

Oracle stopped providing free public commercial updates for Oracle JDK 8 in April 2019. Any Oracle JDK 8 build that has received patches for business use since then, or that needs ongoing security updates, requires a subscription.

Oracle JDK 8 is also the stickiest version in most estates — legacy applications pin to it. How to close it: inventory all Oracle JDK 8, and for each instance either migrate to a free OpenJDK 8 build (Temurin, Corretto, Zulu all ship one) or license it. Free OpenJDK 8 builds remove the exposure entirely.

3. Expired NFTC free windows

Oracle JDK 17 and 21 are free under the NFTC — but only until roughly one year after the following LTS release. When that window closes, those builds, and any updates taken after the cut-off, require a subscription.

The risk is that a build deployed while free silently becomes subscription-requiring with no action on your part. How to close it: record the NFTC expiry date for every Oracle JDK 17/21 install, and plan either a migration to a free OpenJDK build or a subscription before the window closes.

4. Java bundled inside other software

Many applications ship their own Java runtime. Sometimes that bundled Java is an Oracle JDK, and sometimes the third-party vendor's agreement with Oracle does not extend a licence to you, the end customer. When it does not, the bundled Oracle Java becomes your compliance liability.

How to close it: for every application that bundles Java, identify the bundled runtime's vendor and version, and confirm in writing whether the software vendor's licence covers your use. Where it does not, treat that Java as you would any other Oracle JDK install. Our guide to third-party bundled Java covers this in full.

5. Oracle Java in containers and images

Container base images frequently embed a JDK, and it is easy to inherit an Oracle JDK without noticing. Worse, containers multiply: one non-compliant base image becomes hundreds of running instances across a Kubernetes cluster.

Oracle's metric does not charge per container — it charges per employee — but a single Oracle JDK in a widely used image still establishes a subscription requirement. How to close it: audit base images, standardise on images built with a free OpenJDK distribution, and add a build-pipeline check that rejects images containing Oracle JDK.

6. Oracle JDK in cloud and auto-scaling

Cloud estates on AWS, Azure, and Google Cloud spin instances up and down constantly. If a machine image or deployment template contains an Oracle JDK, every scaled instance carries it. Cloud also blurs ownership — teams self-serve infrastructure faster than any inventory keeps up.

Note that the major clouds offer their own free OpenJDK builds — Amazon Corretto on AWS, and freely usable OpenJDK builds on Azure and Google Cloud. How to close it: bake free OpenJDK into golden images and launch templates, and scan running cloud instances for Oracle JDK on a schedule.

7. Developer and test installations

Developers install JDKs freely, and Oracle JDK is a frequent default. Under the OTN licence, dev and test use of Oracle JDK 11 can be free — but the boundary between “test” and “production” is often blurred, and an Oracle JDK that started on a developer laptop can end up in a production pipeline.

How to close it: standardise the developer toolchain on a free OpenJDK distribution, so Oracle JDK never enters the estate through the development door in the first place.

8. No inventory of what runs Java

The most fundamental risk is not a specific install — it is the absence of an inventory. If you cannot state, for every machine, which Java vendor and version it runs, you cannot know your exposure, and you cannot defend an audit. Oracle's audit tooling will produce that inventory for you, on Oracle's terms, if you have not.

How to close it: build and maintain a Java inventory — vendor, version, licence, production flag — covering servers, desktops, containers, and cloud. This is the foundation every other control sits on.

9. Acquisitions and inherited estates

Acquire a company and you inherit its Java estate — and its Java non-compliance — along with extra headcount that raises your employee metric. Many organisations discover inherited Oracle JDK exposure only when an audit lands.

How to close it: make Java licensing a standard line item in technology due diligence, and run a Java inventory of any acquired entity within the first weeks of integration. Our guide on Java compliance after acquisition covers the integration steps.

10. The download-record trail

When you download Oracle JDK builds or pull updates from Oracle, those events are logged against your account. Oracle can — and does — use download history as the opening evidence in a soft audit: a letter that says, in effect, “our records show you downloaded these builds; please confirm your licensing”.

How to close it: understand what your Oracle account download history shows, stop pulling Oracle JDK builds you do not intend to licence, and route all Java acquisition through free OpenJDK channels that leave no Oracle trail.

Closing the gaps

The ten risks share one root cause and one fix. The root cause is the absence of a vendor-and-version Java inventory. The fix, in order, is: discover what you actually run; classify each install against its licence; remediate by migrating subscription-requiring workloads to free OpenJDK where possible; and govern with build-pipeline and procurement controls that stop Oracle JDK re-entering the estate.

Done in that order, most organisations find their genuine subscription requirement shrinks to a small fraction of what an Oracle quote would imply — and several find it falls to zero. A structured 20-point compliance checklist turns this into a repeatable exercise, and our Java compliance assessment does it for you.

Independent help

Finding exposure before Oracle does is worth far more than finding it during an audit. Across more than 340 Java licensing engagements, independent advisers have delivered a 68% average reduction in audit claims and over $180M in total client savings — most of it from exposure identified and remediated early.