Support for Java 24, file-based health checks with MicroProfile Health, and more in 25.0.0.4-beta

Navaneeth S Nair on Apr 8, 2025

announcements , microprofile , java-se , release , beta , monitoring , java-ee ,

Post available in languages:

This beta release adds Java 24 support, access logging with OpenTelemetry, and file-based health checks for MicroProfile Health. Java EE 7 and 8 support for MicroProfile Health 4.0 and new InstantOn features are also included.

The Open Liberty 25.0.0.4-beta includes the following beta features (along with all GA features):

Run your Liberty apps with Java 24
Send Liberty HTTP access logs to OpenTelemetry using MicroProfile Telemetry 2.0
File-based health checks and Java EE 7 and 8 compatibility for MicroProfile Health 4.0
InstantOn Support for J2EEManagement, AppClientSupport and WsSecurity

Run your Liberty apps with Java 24

Released on 18 March 2025, Java 24 introduces many new features and enhancements over previous versions of Java. However, since Java 24 is not a Long-Term Support (LTS) release, support for it will end when the next version of Java is supported. It offers many features worth checking out.

Java 24 includes the following changes:

Take advantage of the changes in Java 24 in Open Liberty now and get more time to review your applications, microservices, and runtime environments on your favorite server runtime!

To start using Java 24 with Open Liberty, download the latest Java 24 release, and install the 25.0.0.4-beta version of Open Liberty. Then, edit your Liberty server.env file to point JAVA_HOME to your Java 24 installation and start testing. The 25.0.0.4-beta release introduces beta support for Java 24. As we work toward full Java 24 support, bear with any of our implementations of these functions that might not be ready yet.

For more information on Java 24, see the following resources:

Send Liberty HTTP access logs to OpenTelemetry using MicroProfile Telemetry 2.0

MicroProfile Telemetry 2.0 (mpTelemetry-2.0) enables OpenTelemetry to collect and export traces, metrics, and logs.

You can now use the mpTelemetry-2.0 feature to collect Liberty HTTP access logs to OpenTelemetry. This new log source is in addition to the previously available Open Liberty runtime log sources (messages, traces, ffdcs, audit) and application logs generated by the java.util.logging (JUL) API.

To enable the MicroProfile Telemetry 2.0 feature to collect HTTP access logs, enable the feature and configure the httpEndpoint and optionally the httpAccessLogging configuration elements. Include the new accessLog value in the source attribute of the mpTelemtry configuration element. Also set the accessLogFields attribute to default or logFormat for the mpTelemetry configuration element, as shown in the following server.xml example:

Copied to clipboard

<featureManager>
    <feature>mpTelemetry-2.0</feature>
    ...
</featureManager>

<httpAccessLogging id="accessLogging" logFormat='%h %u %{t}W "%r" %s %b %D %{R}W'/>
<httpEndpoint id="defaultHttpEndpoint" accessLoggingRef="accessLogging" httpPort="9080" httpsPort="9443"/>

<mpTelemetry accessLogFields="logFormat" source="message,trace,ffdc,accessLog"/>

File-based health checks and Java EE 7 and 8 compatibility for MicroProfile Health 4.0

The MicroProfile Health 4.0 feature (mpHealth-4.0) enables a runtime for the Open Liberty server that previously supported only Jakarta EE 9 or later. In this beta release, the mpHealth-4.0 feature is now also supported within Java EE 7 and EE 8 environments. Also, a file-based health check mechanism is introduced as an alternative to using the /health/* REST endpoints.

The MicroProfile Health technology is most effective when the application is deployed onto a Kubernetes based environment where 'Liveness', 'Readiness' and 'Startup' Probes can be used. In such a deployment scenario, applications that are deployed might be on different Java and Jakarta EE levels. This configuration can result in a mixture of mpHealth-x.x features across different servers and different Kubernetes probe configurations. The mpHealth-4.0 feature is now compatible for use with Java EE 7 and Java EE 8 alongside its existing support for Jakarta EE 9 and Jakarta EE 10 environments. This feature hence unifies Open Liberty server configurations and Kubernetes Health Check probe configurations.

In addition to the existing strategy of querying the /health/live, /health/ready, /health/started REST endpoints, the 25.0.0.4-beta release introduces an alternative file-based health check functionality. When this function is enabled, the live, ready, and started files are created under the ${server.output.dir}/health directory. The ${server.output.dir} defaults to wlp/usr/servers/<server>. For more information, see Directory locations and properties.

The started file is created when the application startup health checks return an UP status. Similarly, the live and ready files are created when the application liveness and readiness health checks return an UP status. The runtime then continues querying the liveness and readiness health checks at a user-defined interval. If the status returns UP, the last modified time of the file is updated. If a file is not updated, then it indicates that a DOWN status was returned.

This file-based functionality is only enabled if a user configures the fileUpdateInterval configuration attribute for the mpHealth configuration element or the MP_HEALTH_FILE_UPDATE_INTERVAL environment variable. If both the environment variable and the fileUpdateInterval attribute are configured, the server.xml takes precedence at run time. The configuration accepts a number followed by an optional ms or s to denote the time unit. If no time unit is specified, it defaults to seconds. Invalid values default the interval to 10 seconds.

The following example shows the server.xml configuration:

Copied to clipboard

<server>
  <features>
    <feature>mphealth-4.0</feature>
  </features>
  <mpHealth fileUpdateInterval="10s"/>
</server>

With file-based checks, you can use the exec command strategy instead of the httpGet or gRPC strategy when you configure the Kubernetes health check probes. For best results, configure the startup probe to check for the existence of the started file. Also, set the probe interval for the liveness and readiness probes to at least 1.5 times greater than the fileUpdateInterval configuration. The exec command checks for the existence of the file and checks if the file is modified within the duration of the probe interval. The ${server.output.dir} in an Open Liberty container is /opt/ol/wlp/output/defaultServer or simply /output.

For example, if an OpenLiberty application image is configured and deployed where the fileUpdateInterval attribute is set to 10 seconds, you can use a Kubernetes configuration similar to the following example:

Copied to clipboard

  probes:
    startup:
      exec:
        command:
          - /bin/sh
          - '-c'
          - file=/output/health/started; cat $file
      failureThreshold: 5
      initialDelaySeconds: 15
      periodSeconds: 15
      timeoutSeconds: 5
    liveness:
      exec:
        command:
          - /bin/sh
          - '-c'
          - file=/output/health/live; x=$(cat $file) && mts=$(stat --format=%.3Y $file | tr -d ".") && if [ $(expr $(date +%s%3N) - $mts) -gt 15000 ] ; then (exit 1) ; else (exit 0) ; fi
      failureThreshold: 3
      initialDelaySeconds: 10
      periodSeconds: 15
      timeoutSeconds: 5
    readiness:
      exec:
        command:
          - /bin/sh
          - '-c'
          - file=/output/health/ready; x=$(cat $file) && mts=$(stat --format=%.3Y $file | tr -d ".") && if [ $(expr $(date +%s%3N) - $mts) -gt 15000 ] ; then (exit 1) ; else (exit 0) ; fi
      failureThreshold: 3
      initialDelaySeconds: 10
      periodSeconds: 15
      timeoutSeconds: 5

Notice that in the liveness and readiness probes, the periodSeconds is set to 15, or 1.5x the fileUpdateInterval, and the check that the file was last modified within the 15 seconds, or the -gt 15000 part of the command.

InstantOn Support for J2EEManagement, AppClientSupport and WsSecurity

Open Liberty InstantOn provides fast startup times for MicroProfile and Jakarta EE applications. With InstantOn, your applications can start in milliseconds, without compromising on throughput, memory, development-production parity, or Java language features. InstantOn uses the Checkpoint/Restore In Userspace (CRIU) feature of the Linux kernel to take a checkpoint of the JVM that can be restored later. InstantOn supports a subset of Open Liberty features. As of the 25.0.0.4-beta release, the following features are enhanced to support InstantOn.

Try it now

To try out these features, update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 24, Java SE 21, Java SE 17, Java SE 11, and Java SE 8.

If you’re using Maven, you can install the All Beta Features package using:

Copied to clipboard

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.11.3</version>
    <configuration>
        <runtimeArtifact>
          <groupId>io.openliberty.beta</groupId>
          <artifactId>openliberty-runtime</artifactId>
          <version>25.0.0.4-beta</version>
          <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

You must also add dependencies to your pom.xml file for the beta version of the APIs that are associated with the beta features that you want to try. For example, the following block adds dependencies for two example beta APIs:

Copied to clipboard

<dependency>
    <groupId>org.example.spec</groupId>
    <artifactId>exampleApi</artifactId>
    <version>7.0</version>
    <type>pom</type>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>example.platform</groupId>
    <artifactId>example.example-api</artifactId>
    <version>11.0.0</version>
    <scope>provided</scope>
</dependency>

Or for Gradle:

Copied to clipboard

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'io.openliberty.tools:liberty-gradle-plugin:3.9.3'
    }
}
apply plugin: 'liberty'
dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[25.0.0.4-beta,)'
}

Or if you’re using container images:

Copied to clipboard

FROM icr.io/appcafe/open-liberty:beta

Or take a look at our Downloads page.

If you’re using IntelliJ IDEA, Visual Studio Code or Eclipse IDE, you can also take advantage of our open source Liberty developer tools to enable effective development, testing, debugging and application management all from within your IDE.

For more information on using a beta release, refer to the Installing Open Liberty beta releases documentation.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

See all blog posts