Home  /  Deployment Discovery  /  Discovering Java Inside Third Party Applications
Deployment Discovery

Discovering Java Inside Third Party Applications

Some of the most dangerous Oracle Java in an estate is Java nobody chose to install, bundled inside vendor applications in private directories. This is a buyer side guide to finding those embedded runtimes and resolving who licenses them before a 2026 audit does it for you.

Many enterprise applications ship a private Oracle Java runtime that never reaches the asset register and surfaces first in an audit. Inspect application directories for embedded runtimes, identify the vendor, and resolve per product whether the application vendor covers the runtime or the obligation falls to you.

The exposure no inventory expected

Some of the most dangerous Oracle Java in an estate is Java nobody chose to install. A large share of enterprise applications ship with their own bundled Java runtime, tucked into a private directory inside the product, and a meaningful number of those runtimes are Oracle Java. Because no administrator deliberately installed it, this Java rarely appears in the asset register, rarely has a named owner, and is exactly the kind of install that surfaces for the first time during an audit. In the per employee world Oracle moved to in January 2023, a single embedded Oracle Java runtime, discovered by Oracle rather than by you, can be framed as a reason to license your entire workforce.

This is why bundled Java deserves its own discipline within discovery. The stakes are the same as for any other install, list pricing from 5.25 to 15.00 dollars per employee per month across every full time and part time employee, every contractor, and every temporary worker, and a three year lookback in the intensified 2026 audits. But the detection problem is harder, because the runtime is hidden inside another product and the licensing question is tangled up with the vendor that shipped it.

Where bundled Java hides

Embedded runtimes live in application installation directories rather than in the system wide locations a standard scan checks. A business application, a middleware product, a monitoring agent, or an internal tool may each carry its own private Java, often a version chosen by the vendor and frozen at whatever update level the product shipped with. Because the runtime is private to the application, package managers do not track it and a host level software inventory may not list it. Finding it requires inspecting the directories of installed applications directly, looking for runtime binaries that belong to a product rather than to the operating system.

The buyer side move

Inspect installed application directories for private Java runtimes, identify the vendor of each, and ask one question per product: does the application vendor's own license cover this runtime, or does the obligation fall to you. Never assume the answer is in your favor or against it.

The licensing question is not yours alone

Bundled Oracle Java sits in a genuinely nuanced position. In some cases the application vendor licenses the embedded runtime as part of its product, and your use of it is covered by your agreement with that vendor. In other cases the vendor ships Oracle Java but the obligation to license it for your use falls to you. The answer depends on the specific arrangement between the application vendor and Oracle, and on the terms of your agreement with the application vendor. This is precisely the kind of question where assumption is expensive in both directions: conceding an obligation that the vendor actually covers wastes money, and ignoring one that falls to you creates audit exposure.

A structured approach to embedded runtimes

  1. Find them. Scan installed application directories for private Java runtimes, not just system wide installs.
  2. Identify the vendor and version. Capture the vendor identifier so Oracle Java is separated from free distributions, exactly as you would for any install.
  3. Attribute each to its product. Record which application shipped each runtime, because the licensing answer depends on the product.
  4. Resolve the licensing question per product. Determine whether the application vendor covers the runtime or whether the obligation is yours, using the vendor agreement and the product documentation.
  5. Document the conclusion. Keep evidence of who covers what, so an audit finding can be answered with a record rather than a scramble.
Indicative bundled Java outcomes, by product arrangement
ArrangementWho licenses the runtimeYour action
Vendor covers embedded Oracle JavaThe application vendorDocument and retain proof
Obligation passes to youYouSize and contain it
Embedded free distributionNo Oracle obligationRecord and move on

A short worked example

Consider an anonymized utility that ran a bundled Java sweep across its application estate. It found private Oracle Java runtimes inside several products. On inspection, two were covered by the application vendors' own licensing, which the utility documented and set aside. One product shipped Oracle Java for which the obligation fell to the customer, a contained finding the utility sized and addressed deliberately. The rest of the embedded runtimes turned out to be free distributions. Without the bundled sweep, the covered runtimes would have been conceded needlessly and the one genuine obligation would have waited to surface in an audit. The figures are indicative, but the order of operations turned a hidden risk into a managed one.

Why this layer rewards doing it first

Bundled Java is the layer where running discovery before Oracle pays off most clearly, because it is the layer Oracle is most likely to use for leverage and the one organizations are least likely to have mapped. When you find the embedded runtimes yourself, resolve the licensing per product, and document the conclusions, an audit question about a bundled runtime is answered from a record you already hold. When Oracle finds it first, the same runtime becomes an opening to argue for a far larger number. The work is unglamorous directory inspection, but it removes one of the most common surprises in an Oracle Java audit.

The questions to ask each application vendor

When an embedded Oracle Java runtime turns out to be your obligation rather than the application vendor's, the vendor relationship becomes part of your defense. Ask each vendor that ships Oracle Java a direct set of questions: does your license for this product include the embedded Oracle Java runtime, and if so, on what terms and for what use. If it does not, can the product run on a free OpenJDK distribution instead of the bundled Oracle Java, and is that configuration supported. Many products are perfectly capable of running on a free runtime, and a supported switch removes the obligation entirely. Getting these answers in writing matters, because a vendor statement that its product supports a free distribution, or that its license covers the embedded Oracle Java, is evidence you can hold against an audit finding. The bundled layer is one where the application vendor, not Oracle, often holds the key, and asking the right questions can convert a hidden obligation into no obligation at all.

Reducing bundled exposure over time

Once mapped, bundled Oracle Java should be reduced wherever a product supports it. The cleanest path is to reconfigure applications that can run on a free OpenJDK distribution to do so, removing the embedded Oracle Java obligation entirely. Where a product genuinely requires Oracle Java and the obligation falls to you, size that requirement precisely and fold it into the same contained residual you maintain for the rest of the estate, rather than letting it stand as a separate, unmanaged risk. Make embedded runtimes a standing check in your software procurement process too, so that new products are evaluated for bundled Oracle Java before they enter the estate, not after an audit finds them. Over time this turns the bundled layer from a recurring source of surprise into a controlled category, where every embedded runtime is known, attributed, and either covered, removed, or deliberately licensed.

Building bundled checks into procurement

The most durable defense against bundled Java exposure is to catch it at the point of purchase. When a new application is evaluated, ask before signing whether it ships a Java runtime, which distribution, and who carries the licensing responsibility for it. A product that bundles Oracle Java and passes the obligation to the customer carries a hidden cost that should be weighed in the buying decision, especially because that cost, under the per employee model introduced in January 2023, can in principle be framed against your entire counted population. Recording the answer at procurement means the embedded runtime enters your inventory already attributed and resolved, rather than surfacing years later in an audit with the three year lookback working against you. Embedding this single question into the procurement checklist closes the most common path by which unmanaged Oracle Java enters an estate in the first place.

How auditors use bundled Java

It is worth understanding why bundled Java is so attractive to an auditor. A standard discovery run that an organization performs on itself often misses embedded runtimes, which means the customer frequently does not know they are there. When an auditor finds an Oracle Java runtime inside a vendor product that the customer never accounted for, it serves two purposes at once. It demonstrates that the customer's own inventory was incomplete, which undermines confidence in every other number the customer presents, and it adds a fresh install to the population Oracle wants to price. The combination is powerful, because a single overlooked embedded runtime can be used to argue both that the estate is larger than claimed and that the customer cannot be trusted to have found everything. The defense against this is simply to have found the bundled runtimes first, attributed each to its product, and resolved the licensing question, so that when the topic arises you can show a complete, reconciled record. An auditor who sees that you already mapped the embedded layer loses both the surprise and the implication of incompleteness, and the conversation stays on the genuine, contained set rather than expanding on the strength of one missed runtime.

The bottom line

Java inside third party applications is the exposure no inventory expected, hidden in private directories and tangled with the vendors that shipped it. Find the embedded runtimes, identify the vendor and version, attribute each to its product, resolve the licensing question per product, and document the result before an audit forces it. For how to tell which embedded runtimes even matter, read distinguishing Oracle Java from OpenJDK in the wild, and for why finding all of this first is the whole game, see finding Oracle Java in your estate before Oracle does. To download the full method, read our Oracle Java licensing guide for 2026.

Find the Java hiding in your software.

Download our Oracle Java licensing guide for 2026 to see how to sweep for embedded runtimes, attribute each to its product, and resolve who actually licenses the Java bundled in your vendor software.

Download the guide

Tell us the real numbers.

Fixed Fee from $18,000 or Gainshare, a share of verified savings or avoided exposure with zero retainer and no risk to you. We sit between you and Oracle and we never take vendor money.

Get a Quote

The Java Audit Brief

Weekly intelligence on Oracle Java licensing moves and the buyer side defenses that work.

Services · Pricing · Case Studies · White Papers · The Java Audit Brief · Licensing Guide
Get a Quote · Book a Strategy Call · New York · London Not affiliated with Oracle Corporation. Independent buyer side advisory only.