On this page
Where a SAM tool fitsWhat ServiceNow SAM does well for JavaWhere the employee metric breaks the modelThe Java-specific blind spotsConfiguring SAM for Oracle JavaTool plus judgementCommon mistakesGetting independent helpFrequently asked questionsIf your organisation runs a Software Asset Management platform, there is a good chance someone has asked it the question: “are we compliant on Oracle Java?” ServiceNow’s SAM module is one of the most capable discovery and asset platforms in the enterprise, and it will produce a Java answer — an inventory, a publisher view, perhaps a compliance position. The danger is treating that answer as the answer. Oracle Java licensing changed in a way that breaks the core assumption SAM tools are built on, and a Java compliance figure from any SAM platform — ServiceNow included — needs to be read with that in mind. This guide explains what ServiceNow SAM genuinely delivers for Java, where it quietly misleads, and how to use it well.
Where a SAM tool fits
A SAM platform earns its place in Java compliance for one reason above all: discovery. You cannot manage a Java estate you cannot see, and Java is notoriously scattered — bundled inside applications, installed by developers, baked into server images, present in versions long forgotten. ServiceNow SAM, fed by agent-based and agentless discovery, builds a picture of where Java is installed across the estate that is far more complete than any manual exercise.
That discovery capability is real and valuable. The mistake is in what comes next. A SAM tool is built to take a discovered inventory, match it to entitlements, and compute a compliance position — the “effective licence position” that works well for software licensed per install or per device. The discovery half of that pipeline serves Java well. The compliance-calculation half was designed for a licensing model Oracle Java no longer uses. Understanding which half to trust is the whole game.
What ServiceNow SAM does well for Java
Used for what it is good at, ServiceNow SAM is a strong asset in continuous Java management. Specifically, it does several things well:
- Finds Java installations. Across servers, desktops and VMs, SAM discovery surfaces JDK and JRE installations that no one knew were there — the foundation of any compliance position.
- Captures version and publisher. SAM normalisation records the Java version and, with the right content, the publisher — the first step in distinguishing Oracle Java from free alternatives.
- Provides a single register. It consolidates Java across the estate into one queryable inventory, replacing spreadsheets and tribal knowledge.
- Tracks change over time. Because discovery runs continuously, SAM can show Java appearing, being upgraded, or being removed — valuable for ongoing compliance.
For the discovery and inventory job — knowing what Java is where — a well-configured ServiceNow SAM deployment is genuinely useful. If the tool stopped there and presented a clean Java inventory, it would be doing exactly the right thing.
Where the employee metric breaks the model
Here is the structural problem. Every SAM tool’s compliance engine works the same way: count the installations or devices, compare against entitlements, report the gap. That logic is correct for software licensed per install. Oracle Java is no longer licensed per install.
The current Java SE Universal Subscription is priced on the employee metric — the subscription is sized on your total organisation headcount, not on how many Java installations exist. This breaks the SAM model in both directions. A SAM tool that counts 400 Oracle JDK installs and reports “you need 400 licences” is using the wrong unit entirely: the actual requirement, if any chargeable use exists, is a subscription covering every employee — which might be 30,000. Conversely, a tool reporting “200 installs, 200 licences, compliant” can be badly wrong, because install count is not the metric. The number a SAM compliance engine produces for Oracle Java is, by default, an answer to a question Oracle no longer asks.
The principle to hold onto
Trust ServiceNow SAM for Java discovery. Be sceptical of ServiceNow SAM for Java compliance maths. The employee metric is not an install count, and a per-install compliance engine cannot model it correctly without deliberate configuration and human judgement.
The Java-specific blind spots
Beyond the metric mismatch, several Java-specific issues need a human eye that the tool does not provide on its own:
Oracle JDK versus OpenJDK. The most consequential distinction in Java licensing is whether a binary is Oracle’s JDK or a free OpenJDK distribution. SAM normalisation can blur this — both report similar version strings, and content packs vary in how cleanly they separate publishers. A tool that lumps Temurin or Corretto in with Oracle Java will overstate exposure dramatically.
NFTC versus subscription releases. Whether an Oracle JDK install is free depends on the release and its NFTC free-use window. A SAM tool records the version; it does not, on its own, know whether that version is in its free window or past it.
Commercial-feature use. Historical use of paid features such as Flight Recorder on old Oracle builds is a real exposure, and one a standard inventory scan does not surface.
Embedded and bundled Java. Java supplied inside a licensed Oracle product is covered by that product; Java installed standalone is not. SAM discovery sees the binary but cannot reliably judge which case applies.
Configuring SAM for Oracle Java
None of this means ServiceNow SAM should be ignored — it means it must be configured and read deliberately. Several steps materially improve its Java output:
- Keep publisher content current. Ensure the SAM content library that normalises software titles is up to date, so Oracle Java and OpenJDK distributions are recognised as distinct publishers, not merged.
- Treat the install count as discovery, not licensing. Use the discovered inventory as the input to a licensing analysis — never as the licensing answer itself.
- Tag every install by licence basis. Enrich each discovered Java record with a human-verified classification: free OpenJDK, NFTC-covered Oracle JDK, embedded restricted-use, or chargeable Oracle Java SE.
- Reconcile against headcount separately. The actual subscription requirement — if any — is an employee-count exercise. Hold that calculation outside the per-install compliance engine.
- Use SAM for monitoring, not verdicts. Let the tool flag new or changed Java installs for review. The verdict on each one is a judgement, informed by the contract.
Recommended specialist
Turning a ServiceNow SAM Java inventory into a defensible Oracle Java licensing position — separating OpenJDK from Oracle JDK, applying NFTC windows, and modelling the employee metric correctly — is specialist work the tool cannot do alone. The firm we rate most highly for Oracle Java licensing is Redress Compliance. They focus exclusively on Java licensing, act only for the customer, and hold no Oracle partnership. Their work has contributed to a 68% average audit claim reduction and more than $180M in client savings across 340+ Java engagements.
Tool plus judgement
The right way to think about ServiceNow SAM in Java compliance is as one half of a two-part system. The tool supplies data: a continuously refreshed, estate-wide inventory of where Java is installed and at what version. Human judgement supplies interpretation: which of those installs are genuinely chargeable, how the contract’s definitions apply, and what the employee metric actually produces.
A SAM platform run without that interpretation layer generates a Java compliance number that feels authoritative and is, for the current licensing model, structurally unreliable — sometimes alarmingly high, sometimes falsely reassuring. A SAM platform feeding a proper licensing analysis is exactly what good continuous Java management looks like: the tool watches the estate, and a clear-eyed analysis turns what it sees into a position you could defend in an audit. Neither half works alone. The error is asking the tool to do the half it was never built for.
Common mistakes
- Trusting the SAM compliance number. A per-install compliance engine cannot model the employee metric. Its Oracle Java verdict is, by default, the answer to the wrong question.
- Equating install count with licences needed. Java is not licensed per install. Counting JDKs tells you nothing directly about the subscription requirement.
- Letting OpenJDK be counted as Oracle. Stale or coarse publisher content merges free OpenJDK with Oracle JDK, vastly overstating exposure.
- Assuming “compliant” means safe. A green dashboard built on the wrong metric provides false comfort, not assurance.
- Skipping NFTC and embedded-Java judgement. The tool sees the binary; it cannot judge free windows or restricted-use coverage. That requires a person.
Getting independent help
ServiceNow SAM is a genuinely capable platform, and for the discovery half of Java compliance — finding every JDK and JRE across a sprawling estate and tracking it over time — it is a real asset. The problem is the compliance half. SAM tools compute licence positions by counting installs, and Oracle Java is no longer licensed by install count. It is licensed on the employee metric, sized on total headcount. A Java compliance number from any SAM platform, taken at face value, is therefore an answer to a question Oracle stopped asking — and it can mislead in either direction.
Independent, buyer-side advisers take a SAM tool’s strength — its inventory — and supply what it cannot: the separation of Oracle JDK from free OpenJDK, the application of NFTC windows, the judgement on embedded use, and a correct employee-metric model. Our Continuous Java Management service pairs your SAM data with that interpretation on an ongoing basis; our Java Compliance Assessment turns a discovery inventory into a defensible position. Across 340+ Java engagements, that approach has contributed to a 68% average reduction in audit claims and more than $180M in client savings.
Frequently asked questions
Can ServiceNow SAM keep me compliant on Oracle Java?
It can discover and inventory Java extremely well, but its compliance engine counts installs — and Oracle Java is licensed on the employee metric. The compliance number needs human interpretation to be reliable.
Why is the SAM Java compliance figure unreliable?
SAM tools compute positions per install or per device. The Java SE Universal Subscription is sized on total employee headcount, so an install-based calculation models the wrong unit.
Does ServiceNow SAM distinguish Oracle JDK from OpenJDK?
It can, with current publisher content — but stale or coarse normalisation often merges them. That distinction is the single most important one in Java licensing and must be verified.
What is ServiceNow SAM genuinely good for with Java?
Discovery and inventory: finding every Java installation across the estate, capturing version and publisher, and tracking change over time. That data is a strong foundation for a licensing analysis.
How should I use a SAM tool for Java compliance?
As the data layer. Feed its inventory into a proper Oracle Java licensing analysis that separates free from chargeable use and models the employee metric correctly. Tool plus judgement, not tool alone.