back to all blogsSee all blog posts

New important bug fixes in Open Liberty 21.0.0.8 and a new home for OpenJ9 Java Builds

image of author
Ryan Storey on Aug 6, 2021
announcements , java-se , release ,
Post available in languages:

Whilst there are no new features in Open Liberty 21.0.0.8, there are several important new bug fixes, as well as some exciting news for those of you running Open Liberty on OpenJ9.

Run your apps using 21.0.0.8

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>21.0.0.8</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[21.0.0.8,)'
}

Or if you’re using Docker:

FROM open-liberty

Or take a look at our Downloads page.

Ask a question on Stack Overflow

A new home for OpenJ9 Java Builds

For those of you currently running Open Liberty on AdoptOpenJDK builds of OpenJ9, things are changing. From now on, OpenJ9 based Java builds will be built and hosted directly by IBM. The IBM Semeru Runtimes are free production-ready open source binaries built with the OpenJDK class libraries and the Eclipse OpenJ9 JVM. It’s the same high performant, lightweight JVM, same class libraries, and same license you’re used to, but with a cool new name.

Download for free from IBM Developer

Notable bugs fixed in this release

We’ve spent some time fixing bugs. The following sections describe just some of the issues resolved in this release. If you’re interested, here’s the full list of bugs fixed in 21.0.0.8.

  • grpcClient-1.0 dynamic enablement unexpected behavior

    Previously, the grpcClient-1.0 feature could not be enabled dynamically after server startup. This was caused by an implementation bug - a mismatch between the ServiceLoader and OSGi lifecycles. The feature has been updated to remove its ServiceLoader reliance, allowing it to function correctly when it’s enabled after server start.

  • gRPC monitoring requires the enablement of both grpc-1.0 and grpcClient-1.0

    Previously, when monitoring-1.0 was enabled along with either of grpc-1.0 or grpcClient-1.0, a bundle resolution error was encountered. There was no issue if both grpc-1.0 and grpcClient-1.0 were enabled. This happened because the gRPC monitoring private feature had simultaneous dependencies on both grpc-1.0 and grpcClient-1.0. This issue was resolved by splitting up the internal gRPC monitoring implementation so that it can be used with the gRPC features independently.

  • Update JSP Logic to Avoid Race Condition Regarding trackDependencies

    A bug was discovered with the trackDependencies property in JSP when handling concurrent requests. This meant that dependents were not tracked, and the JSP would fail to update when any changes were made to these dependents. This issue was resolved by fixing a race condition regarding one of `JSP’s variables.

  • Passivating remote EJB Stub fails when rmicCompatible=true

    When the com.ibm.websphere.ejbcontainer.rmicCompatible JVM property is set, a ClassCastException occurs when passivating then activating a stateful session bean that contains a reference (stub) to an EJB 3.x style remote interface that does not extend java.rmi.Remote. The issue has been fixed by using the ORB during passivation to convert the stub to a serialized string that my be restored during activation.

  • Port MYFACES-4065/MYFACES-4187 to JSF 2.2

    Occasionally, in jsf-2.2 - StringIndexOutOfBoundsException would be thrown if JSF tried to handle an empty string as a resource. This would result in a error like below:

java.lang.StringIndexOutOfBoundsException: String index out of range: 0
at java.lang.String.charAt(Unknown Source)
at org.apache.myfaces.application.ResourceHandlerImpl.createResource(ResourceHandlerImpl.java:118)
at javax.faces.application.ResourceHandlerWrapper.createResource(ResourceHandlerWrapper.java:47)

Now a NullPointerExcepton will be thrown if a resourceName is null.

  • ubuntu upgrade re-enabled openliberty@defaultServer

    When upgrading ubuntu from 21.0.0.1-1ubuntu1 to 21.0.0.5-1ubuntu1, openliberty@defaultServer was unexpectedly re-enabled, however the expected behaviour is that it should remain disabled. This issue was resolved by making sure the defaultServer service was only enabled if no openliberty@ services exist, and to not enable the service if it already exists.

  • Dynamic reconfig of discovery endpoint not updating endpoints in all cases

    Previously, if a Social client was reconfigured, replacing the valid discoveryEndpointUrl with an empty string, and then reconfiguring it again with a good discovery endpoint, the endpoint would not be updated and users would receive a 403 error in the response when they attempt to access a social login protected app. This issue was resolved by ensuring that the discoveryEndpointUrl and discoverey endpoints are properly dynamically updated.

Get Open Liberty 21.0.0.8 now

Available through Maven, Gradle, Docker, and as a downloadable archive.