Java Virtual Machine

This topic was edited by a BMC Contributor and has not been approved.  More information.

Related topics
Product names
Publisher page
  • [BEA|BEA]
  • [GNU|GNU]
  • [IBM|IBM]
  • [Oracle|Oracle]
  • [OpenJDK|OpenJDK]
Application Deployment Software
TKU 2024-Mar-1
More information
Publisher links

Product Description

A Java Virtual Machine (JVM) is a set of computer software programs and data structures which implements a specific virtual machine model, this model accepts a form of computer intermediate language, commonly referred to as Java bytecode, which conceptually represents the instruction set of a stack-oriented, capability architecture. This code is most often generated by Java language compilers, although the JVM can also be targeted by compilers of other languages.

JVMs using the "Java" trademark may be developed by other companies as long as they adhere to the JVM specification published by Sun (and related contractual obligations), the most common and well known JVMs are distributed by Sun, IBM and BEA.

Because JVMs are available for many hardware and software platforms, Java can be both middleware and a platform in its own right, this use of the same bytecode for all platforms allows Java to be described as "compile once, run anywhere", as opposed to "write once, compile anywhere", which describes cross-platform compiled languages.

The JVM also enables such unique features as Automated Exception Handling which provides 'root-cause' debugging information for every software error (exception) independent of the source code.

Sun retains control over the Java trademark, which it uses to certify implementation suites as fully compatible with Sun's specification.

Though there are a number of different JVM's distributed by different publishers, to be a fully compatible implementation of a JVM the numbering needs to be consistent with Sun's major numbering system.

Software Pattern Summary

Product ComponentPatternOS TypeVersioningPattern Depth
Java PlatformJavaVMUnix, WindowsNoneInstance (grouped by full command path)
JRockit PlatformJavaVMDetailsActive, Path and Package
IBM Java Platform
GNU Java Platform
Sun Java Platform
OpenJDK Java Platform

Platforms Supported by the Pattern

The patterns support Java Virtual Machine instances running on Unix, Linux and Windows operating systems.


Triggering for all of the four products is performed using the same regex check on the DiscoveredProcess's cmd attribute. Once the JavaVM pattern has been triggered and a Software Instance created a second pattern (JavaVMDetails) will perform additional checks to try to identify the specific version of the type of Virtual Machine that is running.

Software Instance Triggers

SI Creation

Trigger NodeAttributeConditionArgument

regex '(?i)\bjava[w]?(?:\.exe)?$'

Software Instance node update with version / publisher information (BMC Discovery 8.2.x and below)

Inferred NodeStateCondition
SoftwareInstancecreated, confirmedtype = "Java Virtual Machine"

Runtime Environment node update with version / publisher information (BMC Discovery 8.3.x and above)

Inferred NodeStateCondition
RuntimeEnvironmentcreated, confirmedtype = "Java Virtual Machine"

Simple Identification Mappings

The only simple identifier within the pattern identifies the Java Update Scheduler found on Windows with the Sun version of Java only.

NameRegex on cmd
Sun's automatic Java Update Schedulerregex'(?i)\bjusched.exe$'

NOTE: There are no Simple Identification definitions for a Java process on either Unix or Windows platform as a Software Instance is created for each Java process on a scanned host.


Versioning Approaches

Following the creation (or scan-based update) of a Java VM Software Instance a second pattern is triggered that attempts to gather Java VM version and publisher information.

Version information for this product can be gathered using one of two possible methods.

Active Versioning

Active versioning method employs a two step process when attempting to determine the version of java binary the pattern has triggered on.

While Active Versioning IBM Java Virtual Machine instead of creating separate instance for version output, uses it's specific mechanism that allows

new JVM to attach to already running instance, this causes temporary files to created in '/tmp' directory. If we use additional argument passed to java binary

 '' no temporary files will be created. We will know publisher only after running of such command. So we will use mentioned argument in all

commands for UNIX-type OS, other(not IBM) JVM's will just ignore that argument.

  1. Determine the full path to the java binary
  2. If the full path has been obtained, execute the binary with '-version' and '-fullversion' arguments.

NOTE: The active version command is executed only where we are able to identify the Java process with a full explicit path. If we did not perform a check for the path the command that is executed would either return an error message or could be performed against a default version of java found in the PATH/CLASSPATH variable - both of these circumstances would return incorrect or unexpected results.

The first step uses two possible approaches only one of which is enabled by default.

Step One

Primary Approach (Enabled by default)

The command-line is parsed to determine whether the path obtained is an absolute path.

  • Regex to check path on Windows:
  • Regex to check path on Unix:
^/[^ ]*/java$

Secondary Approach

On Unix platforms (Solaris and Linux), the pmap command is used against the process id (pid) of the triggering process and the output is parsed for the full path to the java binary.

  • Command to run on Unix:
test -f <sucmd_path> && echo exists

This approach works only in cases where the appliance has credentials that give the logged-in user super-user privileges.

If the full path to the java binary has been obtained then the pattern will attempt to twice execute the Java binary that was triggered, once with the "-version" argument and then with the "-fullversion" argument.
The full path to the java binary is stored in javacmd_path variable.

Step Two

  • Executed Unix commands:
%javacmd_path% -version

java -version

%javacmd_path% -fullversion

java -fullversion

  • Executed Windows commands:

%javacmd_path% -version

java -version

%javacmd_path% -fullversion

java -fullversion

NOTE: As we have had reports of the above commands causing increased resource utilization through the executed processes 'hanging' on certain Solaris and Linux hosts, both 'java -fullversion' and 'java -version' are executed within a wrapper when scanning those hosts.
The wrapper used is as follows:

(ulimit -t 10
%javacmd_path% -version 2>&1)

Step Three

The output of 'java -version' is parsed to determine the Java VM publisher, and mapped against known publishers using a mapping table.

Following this, the output of 'java -fullversion' is parsed using regular expressions. The regular expressions used are in order of how common the output of the command is.

  • Most common output format: (?i)version\s*"(\d+(?:\.\d+)*(?:_\d+)?(?:-\w\d+)?)
  • Format only present with IBM Java VM: (?i)version\s*"\S+\s(\d+(?:\.\d+)*)
  • Least common output format: version.+?(\d\+\.\d\+(?:\.\d\+)*(?:_\d\+)?)
  • Other format: (?i)version\s*\"(\d+(?:\.\d+)*)\+(\d+(?:\.\d+)*)\"

Path Versioning

If the Active Versioning Command does not return any version information then we check the installation path to see if we can extract version information.

* Windows Path Regex:





* Unix Path Regex:



An additional processing technique is then used on the resulting value to normalize the version so that it is separated using periods rather than - or _.

Depending on the deployment of the product we have found that this approach provides a version number between 1 and 4 levels of depth, i.e. x through to x.x.x.x.

NOTE: Dealing with Windows Shortened Path

The JavaVM pattern checks whether the scanned Full Path is a Windows Shortened Path. In the case that it is, it engages in a process to retrieve the Long Path. The Long Path must be retrieved in order to perform 2021-07-01_05-34-12_.Java Virtual Machine vv1#Path Versioning later on.

The pattern extracts the Java Root and Java Short variables by applying two Regular Expressions to the Trigger Process Path.

Regular Expression employed to extract Java Short: \\([^\\]*)\\bin\\java(?:w)?\.exe$

Regular Expression employed to extract Java Root: (.*)\\Java Short\\bin\\java(?:w)?\.exe$

The pattern then executes an Active Command in order to retrieve the Long Path.

Active Command employed to retrieve Long Path: dir /x Java Root

The pattern finally extracts the Long Path by applying a Regular Expression to the result of the Active Command.

Regular Expression employed to extract Long Path: Java Short\s+(.*)\r

After retrieving the Long Path, the Full Java Path is reconstructed by substituting the Shortened Path with the newly retrieved Long Path in the Full Java Path itself.

Publisher/Type Identification

As noted above, following the creation (or scan-based update) of a Java VM Software Instance a second pattern is triggered that attempts to gather Java VM publisher information and version. This information gathering pattern updates the Java VM Software Instance identifying which publishers' Virtual Machine implementations it is ('Unknown' if this information cannot be obtained).

The pattern has two means in identifying the publisher and thus the type of JVM in use.

First, the pattern parses the result of the "java -version" or "java -fullversion" command with the following regular expression:

  • (?i)(hotspot|gnu|ibm|bea|sun|openjdk)

If that fails, the pattern parses the trigger process command with the following regular expression:

  • (?i)(\bibm|\bjrockit|\bsun|\boracle|\bopenjdk)

If the pattern is able to extract a known distributor from the path or command, then we normalize its name, as we cannot be certain that it is always spelt in a consistent manner. We normalize it by removing any capitalisation from the string, and then we check it against a table, which contains the mapping from the known identifiers in the field and their corresponding name.

Normalised StringPublisher


red hatRed Hat
zuluAzul Systems
zingAzul Zing

The result of the table query is then stored and used to query another table to identify the specific JVM type.

Normalised StringPublisher
BEAJRockit Platform
IBMIBM Java Platform
GNUSun Java Platform
SunSun Java Platform
OracleSun Java Platform
SAPSAP Java Platform


Oracle distribute the Sun Java platform with its products. As such, if we are unable to identify the publisher from the version command but we can identify Oracle in the command path, then we will be able to identify that the JVM in use is Sun's

Detecting Installation Type

Following the creation (or scan-based update) of a Runtime Environment Node a second pattern is triggered that attempts to gather more information about the Java VM. This pattern will attempt to find whether the installation type is a JDK (Java Development Kit) or JRE (Java Runtime Environment).

This information is found by checking for the existence of the javac (Java Compiler) file on the file system in the same location where the java file is present. The existence of the javac file tells us that the installation is a JDK since the java compiler comes only with the JDK. If the file is absent then the installation is a JRE. It is also possible that pattern is unable to retrieve file information if it does not get a full path to the triggering process or the underlying security does not allow BMC Discovery to access information about the file. In this case we cannot really determine the installation type and it is kept blank.

The installation type will be populated in the edition attribute of the JVM SI or Runtime Environment node. It takes the following values:-


Application Model Produced by Software Pattern

Product Architecture

The architecture of a Java Virtual Machine remains the same no matter who the publisher is. It is a cross platform technology that allows programs that have been compiled under a JDK to be run on a computer with a compatible JVM.

The JVM will usually be run as an executable with the path to the specific application class or jar file to be found in the arguments.

Software Pattern Model

Java Virtual Machine pattern is an infrastructure component pattern.
The model that is created using this pattern represents the number of instances of JVM on the scanned host grouped by their installation path.
This pattern does not model the specific application that is being executed by the JVM - if this is of interest then it would be modeled using a separate pattern, for example WebSphere Application Server.

NOTE: There are no Simple Identification definitions for a Java process on either Unix or Windows platform as a Software Instance is created for each Java process on a scanned host.


A Runtime Environment Node is created for modeling the Java Virtual Machine instances. 

Performance Optimization

In the initial implementation, a single pattern was used for both identification and version / publisher information gathering. On hosts that are running large number of java processes, this approach was proven to impact the performance of BMC Discovery (Foundation). This release introduces an optimization whereby two patterns are now used, one for identification and the other for version / publisher information gathering. This division of tasks decreases the overall number of internal ECA engine events therefore improving the performance of the pattern module.


The pattern has been tested against multiple installations of various Java Virtual Machines on a number of different Operating Systems.

Was this page helpful? Yes No Submitting... Thank you