Understanding Oracle Java Evidence Processing and Recognition in the ARL

Oracle Java recognition can be complex because a Java installation may generate multiple types of software evidence. The same device may report file evidence for Java executables, installer evidence for JDK or JRE packages, and evidence created by another Oracle product that includes an embedded Java runtime.

The Application Recognition Library, or ARL, evaluates the available evidence to identify the applicable Java product, version, publisher and commercial classification while reducing duplicate or false-positive recognition.

This article explains the main evidence-processing principles used for Oracle Java.

Types of Java evidence

1) File evidence

File evidence is collected from Java executable files and their associated metadata. The primary executable patterns considered for Oracle Java recognition are:

• java.exe
• javaw.exe

The ARL assesses attributes such as:

• File and product version
• Product name
• File description
• Company or publisher
• Installation path

The java.exe executable may be present in both JDK and JRE installations. Therefore, an executable alone may confirm the presence of Java without always proving whether the installation is a standalone JDK, a standalone JRE, or Java embedded within another product.

The FlexNet Inventory Agent can also collect detailed file metadata when Oracle Java scanning is enabled, including the installation path, product name, publisher, Java version and related properties.

 2) Installer evidence

Installer evidence may be generated by:

• Native Java installers
• MSI or package-manager installations
• FlexNet Inventory Agent Java inspection
• Oracle Universal Installer, or OUI
• Another software product containing an embedded Java runtime

Installer evidence reported with the raw evidence type Java is collected after the FlexNet Inventory Agent locates a Java executable and runs supported Java version commands. Consequently, this evidence normally has corresponding Java executable file evidence

How the ARL determines the Java product

Java Platform

When the available file metadata identifies Java or Java Platform but does not reliably distinguish JDK from JRE, the evidence may be associated with Java Platform.

This provides visibility that Java is present while avoiding an unsupported assertion that the executable represents a separate JDK or JRE installation.

 Java Development Kit

Evidence is evaluated for JDK recognition when reliable attributes identify terms such as:

• JDK
• Java Development Kit
• JDK-specific product metadata

Beginning with Oracle JDK 11, Oracle no longer offers separate JRE or Server JRE downloads. Runtime capabilities are provided as part of the JDK distribution

 Java Runtime Environment

Evidence may be associated with JRE when reliable metadata identifies:

• JRE
• Java Runtime Environment
• A supported JRE installer pattern

JRE-specific mapping is generally applicable to Java 10 and earlier, subject to the evidence containing sufficient product and publisher information.

Publisher validation

Java is also distributed or repackaged by vendors other than Oracle. To reduce incorrect attribution:

• Evidence is mapped to Oracle Java only when the available publisher or file metadata supports Oracle attribution.
• Evidence clearly identifying IBM, SAP, Red Hat, BellSoft or another Java distributor should not be automatically attributed to Oracle.
• Evidence without reliable publisher or company information may be ignored or left unrecognised when the vendor cannot be established with sufficient confidence.
• Version patterns known to be associated with repackaged Java distributions are reviewed separately rather than automatically mapped to Oracle.

The current ARL guidance records that Java evidence without publisher or company information is ignored, and that certain repackaged version patterns require special handling.

This validation is important because identical or similar Java executable names may be used across different Java distributions.

Handling Oracle Universal Installer (OUI) Evidence

Oracle Universal Installer (OUI) evidence may be generated when Java components are installed as part of other Oracle products. As a result, the presence of OUI evidence does not necessarily indicate that Oracle Java was installed as a standalone product.

Examples of Oracle Java-related OUI evidence patterns include:

• Oracle.JDK
• Oracle.JRE
• Oracle.JDK Enterprise
• Oracle.JRE Enterprise

For example, Oracle.JDK and Oracle.JRE with evidence type OUI have been identified as patterns that can originate from Oracle product installations rather than an independent Java installation. To reduce false-positive Oracle Java recognition, Oracle Java evidence with evidence type OUI will be ignored in ARL.

Why is OUI evidence ignored?

Ignoring Oracle Java OUI evidence helps:

• Reduce false-positive recognition of Oracle JDK and JRE.
• Avoid recognising Java as a standalone installation based solely on evidence generated by another Oracle product.
• Ensure Oracle Java recognition is based on stronger evidence associated with the actual Java installation.

 Evidence that may be ignored

Java evidence may be ignored when it does not provide sufficient confidence for reliable recognition. Examples include:

• Evidence with no publisher or company information.
• Files that cannot be validated as Java product evidence.
• Known repackaged or vendor-specific patterns that must not be attributed to Oracle.
• Generic Oracle component evidence that does not establish a standalone Java installation.
• OUI patterns known to be generated by another Oracle product.
• Supporting executables that do not independently prove installation of the Java product.

Ignoring evidence means that the record is not used to recognise an ARL application. It does not remove the raw inventory evidence collected from the device.

What customers may see

As Java recognition rules are refined, customers may observe:

• A Java application being associated with a more appropriate publisher.
• Evidence moving between public and commercial Java applications after build-level validation.
• Duplicate JDK or JRE recognition being suppressed by precedence.
• OUI-based false-positive recognition being removed.
• Previously unrecognised Java evidence becoming recognised after ARL enrichment.
• Evidence remaining unrecognised when the publisher or product cannot be determined reliably.

Changes in recognised installation counts do not necessarily mean that software was installed or removed. They may result from improvements to evidence mapping, classification or application precedence.

Recommended customer actions

Customers investigating an Oracle Java recognition result should review:

• Application Transparency to identify the evidence contributing to recognition.
• The file path, publisher, product name, file version and evidence type.
• Whether both file and installer evidence exist for the same installation.
• Whether the Java runtime is standalone or embedded within another product.
• The latest ARL version available in their environment.

If evidence appears to be incorrectly mapped, submit a Flexera Support case with:

• The recognised application name and Flexera application ID.
• Exported installer and file evidence.
• The relevant device inventory or NDI file.
• The Java installation path.
• Output from java -version or equivalent vendor information, where available.
• Details showing whether Java was installed independently or supplied with another product.

This information enables Flexera to distinguish a content-mapping issue from incomplete, stale or ambiguous inventory data.

Important note : ARL recognition provides software inventory and normalization information. It does not determine whether an organization requires an Oracle Java licence or establish its contractual obligations. Customers should assess recognized installations against their applicable Oracle agreements and obtain appropriate licensing guidance where necessary.