back to all blogsSee all blog posts

Java 17 support and a number of significant bug fixes in Open Liberty 21.0.0.10

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

The release of Open Liberty 21.0.0.10 offers the long-awaited Java 17 support and its many new enhancements and functionality! This release also provides several important new bug fixes.

In Open Liberty 21.0.0.10:

View the list of fixed bugs in 21.0.0.10

Run your apps using 21.0.0.10

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

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

Or for Gradle:

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

Or if you’re using Docker:

FROM open-liberty

Or take a look at our Downloads page.

Ask a question on Stack Overflow

Java 17 Support

The long awaited release of Java 17 is out and is the first LTS (long term support) release since Java 11’s release back in September 2018. It offers a lot of new functionality and environmental changes that you will want to check out. Because it is a milestone release, we know you are excited and ready to try it out with your existing applications and microservices, or maybe write a new one, all running on your favorite server runtime, Open Liberty!

There have been a lot of changes introduced between Java 11 and 17. Here are some of the noteworthy highlights:

Phasing out the --illegal-access JVM option

By far one of the the biggest impacts to Java development happened over the past couple releases. Java introduced a key play to move Java applications firmly into the modular programming world of the Java Platform Module System (JPMS).

For a quick history review of JPMS, please re-visit the Introduction of the Java Platform Module System (JPMS) section of our Open Liberty and Java 11 blog.

Starting in Java 16 with JEP 396, strong encapsulation of the JDK internal elements took another step. This effectively means the "kill" switch default for the JVM option --illegal-access was changed from permit, permitting module access violations, to deny, denying this access and instead throwing an IllegalAccessException when a violation occurs.

Then, in Java 17 with JEP 403, they took strong encapsulation further. Now, while the JVM option --illegal-access is still recognized as a valid JVM argument, it is effectively hard coded to deny, its passed in value is ignored and the following warning message is issued.

OpenJDK 64-Bit Server VM warning: Ignoring option --illegal-access=permit; support was removed in 17.0

Not to worry though. You still have more time if your applications or dependencies are not completely ready to run in the modularized Java world. There are some more precise JVM arguments, primarily --add-opens and --add-exports, that can help bridge the gap until you, and your applications, are fully modular ready. These arguments allow the individual module exceptions to the JPMS rules that your applications might need.

For more information on this topic, please review the Strong Encapsulation in the JDK documentation or checkout one of the other helpful links in the Java 17 resources sections below.

How to run Open Liberty on Java 17

You will need a copy of Java 17. To try this out, download Java 17 Temurin from adoptium.net.

Then you will need Open Liberty 21.0.0.10, or newer. To run your applications on Open Liberty 21.0.0.10, check out Run your apps using 21.0.0.10.

There are a number of ways to control the Java executable used by the Open Liberty server. The following list describes the order of precedence:

  • JAVA_HOME in ${server.config.dir}/server.env

  • JAVA_HOME in ${wlp.install.dir}/etc/server.env

  • JAVA_HOME set in the environment

  • searching the PATH in the environment

For more information, please visit our server configuration documentation.

Happy Java 17 experimenting!

Java 17 resources

For further reading on Java 17, here are a few resources you might find useful:

For migration to Java 17, please check out Oracle Java 17 migration blog and Getting started with JDK 17.

For Java 17 release roadmaps and availability refer to the Adoptium release roadmap and Oracle commercial JDK roadmap.

And finally, for a comprehensive discussion on Java modules with a little hands on practice, read this article from Baeldung.

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.10.

  • SPNEGO does not work with Java 11 or higher

    In the release of Open Liberty 21.0.0.9, a regression was introduced which prevented the Krb5LoginModule class from being found when authenticating using Kerberos on Java 11 or higher. This issue caused some users to be presented with an Error 403 or Authentication Failed when authenticating using the spnego-1.0 feature. This issue was fixed by changing how classes are loaded to work with Java 11 and higher releases.

  • Multiple Vulnerabilities in Apache Commons Compress affect Open Liberty (CVE-2021-33517 CVSS 5.5, CVE-2021-36090 CVSS 7.5)

    commons-compress is vulnerable to CVE-2021-36090 and CVE-2021-35517. For both of these CVE’s, when processing specially crafted ZIP and TAR archives, the commons-code can attempt excessive memory allocations, leading to an out-of-memory condition. This has been resolved in Open Liberty 21.0.0.10 by moving commons-compress to version 1.21.

  • Liberty is vulnerable to Information Disclosure (CVE-2021-29842 CVSS 3.7)

    In the 21.0.0.9 release, an Information Disclosure vulnerability was discovered which could cause sensitive information to unintentionally be revealed. This issue has now been fixed in Open Liberty 21.0.0.10.

  • Servlet ReadListener does not receive all HTTP request data

    An issue was discovered where in rare cases an app’s javax.servlet.ReadListener could be invoked with onAllDataRead() prematurely, before all of the bytes sent along with the request have been made available to the ReadListener. In an affected scenario, onDataAvailable() would be incorrectly invoked after the premature onAllDataRead() to provide notification for any remaining request data. This issue has been fixed with an update to the HTTP implementation which prevents HTTP request bodies from being prematurely marked as complete.

  • JAX-RS 2.0 and 2.1 implementation is executing resource method when Content-Type or Accept header contains invalid values

    An issue was discovered in 21.0.0.9 which meant that Liberty’s JAX-RS (2.0 and 2.1) implementation would execute resource code when bad requests were made using invalid Content-Type or Accept headers, rather than returning a 400 (Bad Request). A fix has now been implemented to ensure that if a request is made with invalid Content-Type or Accept headers, the implementation returns a 400 (Bad Request).

  • ContainerRequestContext.getAcceptableLanguages() - fails with IllegalArgumentException when invalid locales are specified in the Accept-Language header

    A bug was discovered which meant that ContainerRequestContext.getAcceptableLanguages() would throw an IllegalArgumentException when requests were made with invalid locales specified in the Accept-Language header. This getAcceptableLanguages() call should succeed and return the list from the headers as submitted. This issue has now been fixed to ensure that the Accept-Language header is handled consistently.

  • JSF throws ClassNotFoundException for o.a.m.el.convert.ValueExpressionToValueBinding

    Previously, A JSF application using Application.createValueBinding(String) and jsf-2.2 or jsf-2.3 could encounter a ClassNotFoundException for the internal MyFaces class ValueExpressionToValueBinding, even if that class wasn’t directly referenced by the app. This issue occured because the org.apache.myfaces.el.convert package was not made available (by Liberty’s jsf-2.2 and jsf-2.3 features) to the thread context classloader. This visibility issue was fixed by updating those bundles.

  • RuntimeCodebase cannot be located on collocated call

    When an app invokes a remote enterprise bean in the same Liberty server, the call will be routed internally (collocated) rather than via the network. If the calling app, and the called app have different versions of the same class, negotiation is required between them via the RuntimeCodebase object. An issue was discovered where the RuntimeCodebase was not available for collocated calls. This issue was fixed in Open Liberty 21.0.0.10, meaning that Yoko now supports these collocated calls.

Get Open Liberty 21.0.0.10 now

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