Learn About Configuring Java Management Service Advanced Features

Java Management Service (JMS) is a native service on Oracle Cloud Infrastructure (OCI). JMS can be used for managing, monitoring and securing Java installations in your own managed compute instances (on-premises or on OCI).

You can use JMS for:

  • Visibility: Discover and Manage Java across enterprise
  • Insights: Analyze Java Virtual Machine (JVM) configuration, security, compliance, performance
  • Tuning: Security, Migration, Optimization and Automation

Have you ever wondered if your current security posture is aligned with security recommendations made by Oracle for Java run-times and are up-to-date? JMS may help you find answer for that, it can report any problematic Java library used by your applications and check if your already running applications don't have flaws in the security area. Do you struggle with the performance of your Java applications or find it hard to understand the logs of Java garbage collector? JMS comes to the rescue with performance analysis. Are you not certain if you can easily switch to a newer version of Java? We have you covered with Java Migration Analysis.

With JMS, the Java Flight Recorder (JFR) recordings were never easier, all you need is just to select your application in JMS, provide a few details and submit the recording request. Once the JFR recording work request is finished, you can easily access them from JMS fleet's bucket. And that's not all, JMS also comes with Java lifecycle management capabilities like installation of Java runtimes or providing additional details about your Java application servers.

This solution playbook outlines the steps to configure JMS advanced features to solve the Java IT issues described above.

JMS advanced features can be used to gain insights into different aspects of Java in your environment. For instance, using the advanced features, you can:

  • Scan for Java libraries used by your applications to identify and report potential vulnerabilities (CVE) associated with third-party Java libraries.
  • Optimize Java workload performance with JVM tuning recommendations by leveraging Performance Analysis.
  • Evaluate the feasibility and effort required for migrating Java applications to newer JDK versions with Java Migration Analysis.
  • Help keep your applications secure by using Crypto Event Analysis to identify weak cryptographic usages that will stop working with upcoming updates in the Oracle JRE and JDK cryptographic roadmap.
  • Understand which services and applications are running on each Java application server by scanning for Java servers.
  • Run JDK Flight Recorder to remotely gather application insights.
  • Download, install, and configure Java runtime.
  • Remove reported Oracle Java versions.
  • Distribute or remove the Deployment Rule Set.

Before You Begin

Access to Java Management Service requires an Oracle Cloud (OCI) account. You may use your own cloud account, or you can get an OCI Free Tier account.

In the examples outlined in this solution playbook, we use the OCI command line tool. If you are interested to try those examples on your own, set up and configure OCI CLI according to the following guide Command Line Interface (CLI). Additional requirements for running the example is the presence of the jq command line utility on the machine where you will execute oci tool commands. You can get this utility for almost every platform from their GitHub project page: https://github.com/jqlang/jq.

Ensure an Oracle Linux machine is set up correctly to allow the communication with OCI services. The machine can be:

  • An OCI compute instance that is available in your tenancy. If you don't have an instance already set up, see Create an OCI compute instance.
  • Non-OCI host, that is on-premises (in your own data center, third party cloud, and so on) that should be monitored through the JMS service.
Set Up JMS
  1. Set up JMS as described in the following solution: Set up Java Management Service to monitor Java usage on an Oracle Linux host .
  2. Add required policies for advanced features as described here: JMS Fleets Policy Statements.
    1. Sign in to the OCI Console as an administrator.
    2. Open the navigation menu, and navigate to the JMS policies document by clicking on Identity & Security, Policies.
    3. Find the JMS related policy document, for example JMS_Policy_Fleet_Compartment and click on it.
    4. Click Statement and then click Edit Policy Statements.
    5. Add the following three policy statements:
      
      ALLOW dynamic-group JMS_DYNAMIC_GROUP to MANAGE object-family IN COMPARTMENT Fleet_Compartment
      ALLOW group FLEET_MANAGERS to MANAGE object-family IN COMPARTMENT Fleet_Compartment
      ALLOW resource jms SERVER-COMPONENTS to MANAGE object-family IN COMPARTMENT Fleet_Compartment
    6. Click Save changes.
  3. Enable JMS advanced features:
    1. Sign in to the OCI Console as an administrator.
    2. Open the navigation menu, click Observability & Management, and then click Fleets under Java Management.
    3. Select your fleet.
    4. In the Fleet properties section, check if all JMS Advanced features are enabled.
    5. If not, click Actions and select Edit Properties.
    6. In the Advanced features section, click Enable button for all listed advanced features.
    7. Verify and confirm requirements for JMS Advanced features and click Enable button.
    8. Once all advanced features are enabled click Save changes.

    Note:

    If you cannot find your JMS policy document or JMS fleet, try to change your compartment. In this solution playbook, we are using a compartment with the name Fleet Compartment.

    You can also enable all advanced features during fleet creation as described in the first step of the Set up JMS section.

Architecture

This playbook describes an overview to onboard Java Management Service advanced features, specifically to gain insights into your Java installations and take corrective actions as needed. This solution is applicable to enabling the advanced feature functionality in JMS, for Oracle installations in OCI, on-premises, and third-party cloud.

JMS agent is installed on the managed instances to collect Java usage telemetry and Java usage metadata. The telemetry data is emitted to and stored in your tenancy for privacy protection.

The following diagram illustrates the topology of the JMS service in production. The diagram shows agents deployed to track Java running on OCI, your on-premises desktops, laptops and servers, and third-party cloud services. These agents are deployed in your managed instances and are associated with your created resources (fleets) in your tenancies.

The Java usage metadata is exfiltrated from your tenancy by the agent installed in your tenancies. JMS uses this metadata to generate insights such as Java version, Security Baseline and upcoming Java Updates, and Application Usage; which is presented when you log in to the OCI Console. There is no Oracle access beyond processing the exfiltrated metadata.

Using the advanced features available in JMS, you can analyze usage of Java application servers, identify potential vulnerabilities in the Java libraries used by applications running in your environment, use Java flight recorder for performance and crypto analysis and mange Oracle Java Runtimes (JDK versions) in your environment. You can use the advanced feature to manage Java running in your environment.

The following diagram illustrates this architecture.



jms-oci-topology-oracle.zip

At a high level, the following section describes how data flows between the JMS agent installed on your managed instance and the JMS service on OCI:

  • You install the agent on the Managed Instance, and the agent registers with OCI.
  • You configure or enable the JMS plugin (passing the JMS fleet as parameter). The JMS agent is now associated with the desired JMS fleet.
  • The registered JMS agent polls JMS for work. JMS will respond to the poll with appropriate work requests, if any.
  • The JMS agent periodically scans the managed instance for Java installations or entries in the usage tracker and send the Java metrics and Java metadata to OCI.

For more information about the data flow between the JMS agent and OCI service and the traffic flows between the JMS agent installed on your host machines (on-premises) and JMS running in OCI, see Monitor and manage your Java and Java application installations.

This architecture has the following components:

  • Region

    An OCI region is a localized geographic area that contains one or more data centers, hosting availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

  • Availability domains

    Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain shouldn't affect the other availability domains in the region.

  • Tenancy

    A tenancy is a secure and isolated partition that Oracle sets up within Oracle Cloud when you sign up for OCI. You can create, organize, and administer your resources on OCI within your tenancy. A tenancy is synonymous with a company or organization. Usually, a company will have a single tenancy and reflect its organizational structure within that tenancy. A single tenancy is usually associated with a single subscription, and a single subscription usually only has one tenancy.

  • Compartment

    Compartments are cross-regional logical partitions within an OCI tenancy. Use compartments to organize, control access, and set usage quotas for your Oracle Cloud resources. In a given compartment, you define policies that control access and set privileges for resources.

  • Virtual cloud network (VCN) and subnets

    A virtual cloud network (VCN) is a customizable, software-defined network that you set up in an OCI region. Like traditional data center networks, VCNs give you control over your network environment. A VCN can have multiple non-overlapping classless inter-domain routing (CIDR) blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.

  • Instance pool

    An instance pool is a group of instances within a region that are created from the same instance configuration and managed as a group.

  • On-premises network

    This is a local network used by your organization.

  • OCI API Gateway

    Oracle Cloud Infrastructure API Gateway enables you to publish APIs with private endpoints that are accessible from within your network, and which you can expose to the public internet if required. The endpoints support API validation, request and response transformation, CORS, authentication and authorization, and request limiting.

  • Dynamic routing gateway (DRG)

    The DRG is a virtual router that provides a path for private network traffic between VCNs in the same region, between a VCN and a network outside the region, such as a VCN in another OCI region, an on-premises network, or a network in another cloud provider.

  • Service gateway

    A service gateway provides access from a VCN to other services, such as Oracle Cloud Infrastructure Object Storage. The traffic from the VCN to the Oracle service travels over the Oracle network fabric and does not traverse the internet.

  • Oracle Autonomous Database

    Oracle Autonomous Database is a fully-managed, preconfigured database environment that you can use for transaction processing and data warehousing workloads. You do not need to configure or manage any hardware, or install any software. OCI handles creating, backing up, patching, upgrading, and tuning the database.

  • Bastion host

    The bastion host is a compute instance that serves as a secure, controlled entry point to the topology from outside the cloud. The bastion host is provisioned typically in a demilitarized zone (DMZ). It enables you to protect sensitive resources by placing them in private networks that can't be accessed directly from outside the cloud. The topology has a single, known entry point that you can monitor and audit regularly. So, you can avoid exposing the more sensitive components of the topology without compromising access to them.

  • Oracle Cloud Agent

    Oracle Cloud Agent is a lightweight process that manages the lifecycle of plugins running on compute instances on OCI. The JMS Plugins collect Java metadata from your environment deployed on the managed instance in OCI. The JMS plugin exfiltrates this Java metadata to the JMS service in OCI.

  • OCI Compute

    With Oracle Cloud Infrastructure Compute, you can provision and manage compute hosts in the cloud. You can launch compute instances with shapes that meet your resource requirements for CPU, memory, network bandwidth, and storage. After creating a compute instance, you can access it securely, restart it, attach and detach volumes, and terminate it when you no longer need it.

  • OCI DNS

    Oracle Cloud Infrastructure Domain Name System (DNS) service is a highly scalable, global anycast domain name system (DNS) network that offers enhanced DNS performance, resiliency, and scalability, so that end users connect to internet applications quickly, from anywhere.

  • Kafka Streams

    Kafka Streams is a client library for building applications and microservices, where the input and output data are stored in Kafka clusters. It combines the simplicity of writing and deploying standard Java and Scala applications on the client side with the benefits of Kafka's server-side cluster technology.

  • OCI Logging
    Oracle Cloud Infrastructure Logging is a highly-scalable and fully-managed service that provides access to the following types of logs from your resources in the cloud:
    • Audit logs: Logs related to events produced by OCI Audit.
    • Service logs: Logs published by individual services such as OCI API Gateway, OCI Events, OCI Functions, OCI Load Balancing, OCI Object Storage, and VCN flow logs.
    • Custom logs: Logs that contain diagnostic information from custom applications, other cloud providers, or an on-premises environment.
  • Oracle Management Agent

    Oracle Management Agent is a service that provides low latency interactive communication and data collection between Oracle Cloud Infrastructure and on premise managed instances. Management agents collects data from sources that you want to monitor. Management Agent Service, an Oracle Cloud Service, manages the lifecycle of the management agent and the plug-ins for the services.

  • OCI Monitoring

    Oracle Cloud Infrastructure Monitoring actively and passively monitors your cloud resources, and uses alarms to notify you when metrics meet specified triggers.

  • OCI Object Storage

    OCI Object Storage provides access to large amounts of structured and unstructured data of any content type, including database backups, analytic data, and rich content such as images and videos. You can safely and securely store data directly from applications or from within the cloud platform. You can scale storage without experiencing any degradation in performance or service reliability.

    Use standard storage for "hot" storage that you need to access quickly, immediately, and frequently. Use archive storage for "cold" storage that you retain for long periods of time and seldom or rarely access.

  • Policy

    An Oracle Cloud Infrastructure Identity and Access Management policy specifies who can access which resources, and how. Access is granted at the group and compartment level, which means you can write a policy that gives a group a specific type of access within a specific compartment or to the tenancy.

  • Security list

    For each subnet, you can create security rules that specify the source, destination, and type of traffic that is allowed in and out of the subnet.

  • Security zone

    Security zones implement key Oracle security best practices by enforcing policies for an entire compartment, such as encrypting data and preventing public access to networks. A security zone is associated with a compartment of the same name and includes security zone policies (a recipe) that applies to the compartment and its sub-compartments. You can't add or move a standard compartment to a security zone compartment.

  • OCI Vault

    Oracle Cloud Infrastructure Vault enables you to create and centrally manage the encryption keys that protect your data and the secret credentials that you use to secure access to your resources in the cloud. The default key management is Oracle-managed keys. You can also use customer-managed keys which use OCI Vault. OCI Vault offers a rich set of REST APIs to manage vaults and keys.

  • OCI Workflow

    Oracle Cloud Infrastructure Workflow is a serverless workflow engine with a graphical flow designer for developers and architects. It accelerates the creation, running, and orchestration of OCI services such as OCI Functions or AI/ML.

Considerations

You should consider the following points when enabling advanced features.

  • Additional policies are required for using JMS Advanced features
  • Crypto event analysis, Performance analysis and JDK Flight Recorder may increase the overall memory usage of application's JVM.
  • For Crypto event analysis, Performance analysis and JDK Flight Recorder, the application's Java runtime versions must be version 8u361 or higher.
  • Crypto event analysis and Performance analysis upper bound limit for each JFR recording is set to 4096 MB.
  • Additional costs may be charged by using OCI Object Storage and OCI Logging services for storing the data produced by JMS advanced features.
  • Java Lifecycle Management
    • Deployment Rule Set feature is only applicable for Java 8 runtimes. Additional overhead is distribution of the policy jar on fleet's managed instances.
    • Java installation may alter Java system configuration on managed instance. Follow installation instructions for selected Java runtime version and managed instance platform(s).
    • Removal of Java runtime may alter Java system configuration on managed instance. For example, if selected Java runtime is the only system configured runtime on a managed instance.
  • Advanced Usage Tracking
    • For detection of running Java Application servers, their Java Runtime must be at least of version 8u361 or higher.
    • Library detection may significantly increase resource consumption on managed instance during inspection of application and its libraries, especially CPU and IO utilization may increase.
    • Depending on number of application servers and libraries detected on managed instance the payload sent to JMS may be higher than usual. Under normal circumstances, it should be within a range of few hundred kilobytes.
  • Crypto Event Analysis
    • Depending on how much each application is utilizing JVM's security related subsystems during recording, the final size of the JFR recording file may vary, under normal circumstances usual size of recording is between few hundred kilobytes to few megabytes.
    • If application is idle, some detection mechanisms may not report potential problems.
    • Network utilization may be increased depending on the number of managed instances, number of applications and the size of each recording. Network is utilized during the upload of the JFR recordings into OCI for analysis.
  • Performance Analysis
    • The final size of each JFR recording file depends on the application behavior. Several performance related JFR events are captured like details about garbage collections, memory, and so on. Under normal circumstances , the usual recording size is a few megabytes.
    • If application is idle, some detection mechanisms may not report potential performance problems.
    • Network utilization may be increased depending on the number of managed instances and the size of each recording. Network is utilized during the upload of the JFR recordings into OCI for analysis.
  • JDK Flight Recorder (JFR)
    • The final size of JFR recording file depends on selected profile or provided custom JFC configuration, another factor influencing the size is the selected recording duration for application.
  • Java Migration Analysis
    • Resource utilization may increase during the analysis of the application.
    • The result of the analysis is usually in order of a few hundred kilobytes depending on the size of the applications itself and its dependencies.

Some advanced features like Crypto analysis, and Performance analysis rely on JVM Attach API. During the execution of work requests, the JMS plugin may send new events to the fleet's inventory log object. The following sample payload illustrates what will be delivered into the fleet's inventory log in such situations:

{
  "datetime": 1752483223432,
  "logContent": {
    "id": "3d6a9915-af91-4527-a6d4-2a0d86106b15",
    "time": "2025-07-14T08:53:43.432Z",
    "oracle": {
      "compartmentid": "ocid1.compartment.oc1..compartment-id",
      "ingestedtime": "2025-07-14T08:55:27.274970180Z",
      "instanceid": "ocid1.instance.oc1.eu-frankfurt-1.instance-id",
      "loggroupid": "ocid1.loggroup.oc1.eu-frankfurt-1.log-group-id",
      "logid": "ocid1.log.oc1.eu-frankfurt-1.log-id",
      "tenantid": "ocid1.tenancy.oc1..tenant-id"
    },
    "source": "ocid1.instance.oc1.eu-frankfurt-1.instance-id",
    "specversion": "1.0",
    "subject": "Oracle JMS Plugin",
    "type": "jms.jvm.usage.attach.log",
    "data": {
      "data": {
        "additionalProperties": {
          "java.runtime.name": "Java(TM) SE Runtime Environment",
          "user.dir": "/home/opc/crypto",
          "user.name": "opc"
        },
        "applicationName": "spring-tls-server-1.1.0.jar",
        "classPath": "spring-tls-server-1.1.0.jar",
        "classPathElements": [
          "spring-tls-server-1.1.0.jar"
        ],
        "fleetId": "ocid1.jmsfleet.oc1.eu-frankfurt-1.fleet-id",
        "javaArgs": "n/a",
        "javaCommand": "spring-tls-server-1.1.0.jar --debug",
        "javaDistribution": "Java(TM) SE Runtime Environment",
        "javaHome": "/usr/lib/jvm/jdk-21-oracle-x64",
        "javaMajorVersion": "21",
        "javaVendor": "Oracle Corporation",
        "javaVersion": "21",
        "managedInstanceId": "ocid1.instance.oc1.eu-frankfurt-1.instance-id",
        "osArch": "amd64",
        "osName": "Linux",
        "osVersion": "5.15.0-306.177.4.el9uek.x86_64",
        "startTime": "2025-07-14T08:48:34.947541200Z",
        "typeOfStart": "VM start"
      },
      "datacontenttype": "application/json",
      "dataschema": "1.0",
      "id": "3d6a9915-af91-4527-a6d4-2a0d86106b15",
      "source": "ocid1.instance.oc1.eu-frankfurt-1.instance-id",
      "specversion": "1.0",
      "time": "2025-07-14T08:53:43.432Z",
      "type": "jms.jvm.usage.attach.log"
    }
  },
  "regionId": "eu-frankfurt-1"
}

Other Considerations

Once a feature execution request is submitted in JMS, the JMS service creates a work request identified by a unique work request OCID. Below is the typical process to track the work request progress from OCI Cloud Console.

  • Navigate to your fleet by clicking on Observability & Management, Java Management, Fleets.
  • Select your fleet.
  • Click on the fleet's Work requests section.

How to track progress of work request from OCI CLI:

  • Execute the following command:
    oci jms work-request get --work-request-id $WORK_REQUEST_OCID
  • If you are interested only in the current state of the work request, you can execute the statement above with the jq utility:
    oci jms work-request get --work-request-id $WORK_REQUEST_OCID | jq .data.status

The ability to submit and track feature work requests is also available in the JMS API, accessible via the OCI SDK.