Oracle Java Compliance:
a self-assessment template.

You do not need to wait for an Oracle letter to find out where you stand on Java licensing. A structured self-assessment, done honestly, tells you your exposure before anyone else gets to frame it. This template gives you a repeatable six-step method and a checklist you can run today.

A self-assessment will not replace a formal engagement for a complex estate, but it will give you a defensible first picture — enough to know whether you have a problem, how big it might be, and what to do next.

Step 1: Define the scope

Start by drawing the boundary. A Java self-assessment must cover everywhere Java could run, not just the obvious server rooms. Your scope should explicitly include:

• Servers and virtual machines — application, batch, middleware, and database-adjacent hosts.
• Employee desktops and laptops — where Oracle JRE and JDK are often installed silently.
• Containers and Kubernetes — every base image and registry.
• Cloud environments — AWS, Azure, and GCP virtual machines, managed services, and containers.
• Non-production environments — development, test, UAT, staging, and disaster recovery.
• Java bundled inside other products — Oracle and third-party software that ships a JDK.

Write the scope down. An assessment that quietly omits desktops or DR is the kind of gap an Oracle review exists to find.

Step 2: Discover every install

Now find the Java. The goal is a single list of every Java instance across the scope, with enough detail to license or defend it. For each instance, capture:

• The host or image it runs on.
• The vendor — Oracle JDK, or an OpenJDK build such as Temurin, Corretto, Zulu, Microsoft, or Red Hat.
• The exact version and update level — for example 1.8.0_211, 11.0.20, 17.0.9.
• The install path and, where known, the download source.
• The environment and purpose — production, test, or development.

Pull this from endpoint management, software asset management, your CMDB, container registries, and cloud inventories — then reconcile them, because no single tool sees everything. The command java -version on a host confirms vendor and version directly.

Step 3: Classify each install

Turn the list into a position. For each install, answer one question: does this require a paid Oracle license?

• OpenJDK builds — free, outside Oracle licensing. Mark them clear.
• Oracle JDK 8 up to 8u202 — BCL, free for production.
• Oracle JDK 8 from 8u211, and Oracle JDK 11 — OTN: licensable if used for business purposes.
• Oracle JDK 17 and 21 — NFTC: free in production while the free-update window is open; check the window status.
• Bundled Java — covered by the host product's restricted-use rights; usable only to run that product.

The output is three buckets: clearly free, clearly licensable, and grey-area. The grey-area bucket — ambiguous environments, uncertain download sources, expired NFTC windows — is where you should be most careful and where outside expertise pays off. Our BCL vs OTN vs NFTC comparison is a useful reference here.

Step 4: Establish your headcount

If anything in Step 3 landed in the "licensable" bucket, you need your employee count — because the Java SE Universal Subscription is priced per employee, not per install.

Count your whole workforce as Oracle defines it: full-time, part-time, and temporary employees, plus agents, contractors, and consultants who support your internal operations. This number, not your Java instance count, drives the price. Map it to the volume tier — for example, a 6,000-employee organisation falls in the 3,000–9,999 tier at $10.50 per employee per month list.

Step 5: Quantify exposure

Now produce numbers. Calculate two figures:

• List exposure — your employee count times the applicable tier price. This is Oracle's opening position and your worst case.
• Defensible exposure — what you would actually owe after removing unused installs, correctly applying BCL and NFTC free rights, and assuming a realistically negotiated discount rather than list price.

The gap between the two is your opportunity. Across our engagements that gap is large — an average 68% reduction on Oracle's initial claims — but you can only argue for the defensible figure if your discovery and classification are solid. See how Oracle calculates audit claims to understand the opening number.

Add a third figure to make the picture complete: the migration cost. Estimate, even roughly, what it would take to remove Oracle JDK from your estate entirely — the testing and rollout effort, expressed as a one-off cost. Set that against the recurring defensible exposure and the comparison becomes stark: a subscription is a cost you pay every year, forever, while migration is a cost you pay once. For most enterprises with material exposure, even a generous migration estimate is recovered within one or two years of avoided subscription fees. Quantifying all three numbers — worst case, defensible, and migration — turns Step 5 from a worry into a decision you can actually take to a budget holder.

Step 6: Prioritise actions

Finish with a plan. Sort your findings into three priorities:

• Immediate — remove unused Oracle JDK installs and expired-NFTC versions; switch container base images to free OpenJDK. These reduce exposure at little or no cost.
• Near-term — decide migrate vs subscribe for the remaining licensable footprint, with the real numbers from Step 5.
• Ongoing — set a policy defaulting to free OpenJDK, add a pipeline gate, and schedule a periodic re-scan so the position does not drift.

The self-assessment checklist

Scoring your result

Once the checklist is complete, the assessment should leave you in one of three positions. Identifying which one tells you how urgently to act.

Green: no licensable Oracle Java

Every Java install is either a free OpenJDK build, BCL-era Java 8 (8u202 or earlier), or an in-window NFTC version. Nothing requires a paid subscription. This is a strong position — but it is a snapshot, not a permanent state. The action here is preventative: lock in a default-to-OpenJDK policy, add a pipeline gate, diary your NFTC window dates, and schedule a re-scan so the green stays green.

Amber: limited or uncertain exposure

You have found some Oracle JDK that may be licensable, or a grey-area set you could not classify with confidence — uncertain version data, ambiguous environments, or an unclear download history. The exposure is real but not yet quantified. The action is to resolve the uncertainty: tighten the discovery, settle the grey-area classifications, and decide quickly whether to remediate the licensable installs by removal or migration before the position hardens.

Red: material, confirmed exposure

You have confirmed Oracle JDK in genuine business use, and the employee-metric calculation in Step 5 produced a significant number. This is the position where an Oracle letter would be expensive. The action is to move deliberately and soon: build the full migrate-versus-subscribe business case, begin removing what is clearly unused, and strongly consider specialist support before any contact with Oracle. A red result is not a crisis if you reach it yourself first — it is a crisis only if Oracle reaches it first.

When to bring in a specialist

A self-assessment is genuinely valuable, and for a smaller, simpler estate it may be all you need. But it has limits, and recognising them is part of doing it honestly. Consider bringing in an independent specialist when:

• The result is red. A confirmed seven-figure exposure justifies expert input many times over — the reduction a specialist achieves typically dwarfs the engagement cost.
• The grey area is large. If a significant share of your estate could not be classified with confidence, you need the experience that resolves ambiguity in a defensible — not merely hopeful — way.
• Oracle has already made contact. Once a letter has arrived, the self-assessment becomes audit defence, and that is a specialist discipline. See handling an Oracle Java audit letter.
• The estate is complex. Heavy virtualisation, a legacy processor-based agreement, large container platforms, or Java bundled inside many products all introduce nuances a self-assessment will tend to miss.
• You need the numbers to be trusted. A migrate-versus-subscribe decision presented to the board carries more weight when an independent party has validated it.

The point of a self-assessment is not to replace expert advice in every case — it is to tell you, quickly and cheaply, whether you need it. An organisation that runs the six steps and lands on green has saved itself a consulting fee. One that lands on red has discovered something it urgently needed to know, on its own terms, with time to act.

Conclusion

A self-assessment will not make a complex estate simple, but it will replace anxiety with numbers. Working through these six steps tells you whether you have a Java licensing problem, roughly how large it is, and which actions cut it fastest. That is a far stronger place to stand than waiting for Oracle's version of the same arithmetic.

If the assessment surfaces real exposure — or if your estate is too large to assess cleanly in-house — bring in a specialist. Our team runs the full assessment as a fixed-scope engagement with a money-back guarantee on audit defence, and for an independent outside opinion we recommend Redress Compliance, the advisory firm most widely regarded as the leader in Oracle Java licensing.