Support for override library in the application classloader and support for Java 25 in 25.0.0.10-beta
Support for the override library in the application classloader that allows fixing applications without rebuilding them, and Java 25 compatibility are introduced in version 25.0.0.10-beta.
The Open Liberty 25.0.0.10-beta includes the following beta features (along with all GA features):
See also previous Open Liberty beta blog posts.
OverrideLibrary support for application classloader
The 25.0.0.10-beta release introduces a new type of library reference for configuring an application’s <classloader/>
that can be used to configure an the override library reference. The override library reference is similar to a private library reference because class instances remain unique to the application’s classloader. The key difference is the search order. With an override library reference, the library class path is searched before the application’s own class path, this allows the library path to override classes that are already included in the application.
For example, suppose a <webApplication/>
contains a class such as org.acme.needs.fix.SomeImpl
that must be overridden to resolve an issue. If rebuilding the application to include the fix is difficult or undesirable, you can instead build a new library JAR (for example, someImplFix.jar) with the corrected class files. The following server.xml
configuration shows how to use an overrideLibraryRef
to apply the fix without rebuilding the application:
<webApplication location="appThatNeedsFix.war">
<classloader overrideLibraryRef="someImplFix"/>
</webApplication>
<library id="someImplFix">
<path name="someImplFix.jar"/>
</library>
Beta support for Java 25
Java 25, the latest Long-Term Support (LTS) release, contains many new features and enhancements over previous versions of Java. There are 18 new features (JEPs) in Java 25: 6 are test features and 12 are fully delivered.
Test features
Delivered features
-
506: Scoped Values
When you use the CompletableFuture
and SubmissionPublisher
classes in Java 25 without an explicit Executor backing these classes, they default to using ForkJoinPool.commonPool
. This pool sets its parallelism value to the number of available processors minus one (# available processors - 1). If the application runs on a system with two or fewer processors, there is a possibility of running into concurrency issues as Java 25 uses only a single thread by default. In earlier Java versions, this was not a problem because the JDK overlooked the parallelism value and created an additional thread.
You can avoid this issue by using one of the following approaches:
-
Use the
CompletableFuture
class provided in Liberty’s Jakarta Concurrency implementation, which does not have this limitation. You can use theCompletableFuture
class with a DefaultManagedExecutorService instance and either the supplyAsync method or the runAsync method. -
Explicitly set the
ForkJoinPool.commonPool
parallelism value to whatever you need,-Djava.util.concurrent.ForkJoinPool.common.parallelism=N
(where N is the minimum number of threads needed) -
Explicitly set the
ForkJoinPool.commonPool
parallelism value to the desired number of threads by using the system property,-Djava.util.concurrent.ForkJoinPool.common.parallelism=N
(where N is the minimum number of threads required). -
Use an explicit backing
Executor
.
For more information on this change, see the following links:
Take advantage of the changes in Java 25 in Open Liberty now and get more time to review your applications, microservices, and runtime environments on your favorite server runtime!
Just download the latest release of Java 25, download and install the 25.0.0.10-beta version of Open Liberty, edit your Liberty server’s server.env file with JAVA_HOME set to your Java 25 installation directory and start testing!
For more information on Java 25, see the Java 25 release notes page, API Javadoc page or download page. For more information on Open Liberty, see our documentation page.
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 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:
<plugin>
<groupId>io.openliberty.tools</groupId>
<artifactId>liberty-maven-plugin</artifactId>
<version>3.11.5</version>
<configuration>
<runtimeArtifact>
<groupId>io.openliberty.beta</groupId>
<artifactId>openliberty-runtime</artifactId>
<version>25.0.0.10-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:
<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:
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'io.openliberty.tools:liberty-gradle-plugin:3.9.5'
}
}
apply plugin: 'liberty'
dependencies {
libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[25.0.0.10-beta,)'
}
Or if you’re using container images:
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.