back to all blogsSee all blog posts

Relicensing to EPLv2 in Open Liberty

image of author
Michal Broz on Feb 7, 2023
Post available in languages: 日本語 ,

As part of the Open Liberty release, we are relicensing the runtime from EPLv1 to EPLv2. This release also includes various bug fixes.

In Open Liberty

View the list of fixed bugs in

Run your apps using

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


Or for Gradle:

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

Or if you’re using Docker:

FROM open-liberty

Or take a look at our Downloads page.

Ask a question on Stack Overflow

Open Liberty is now licensed under EPLv2

On December 7th, 2022, we published the Proposal to relicense Open Liberty to EPLv2 blog post to solicit feedback from the community about changing Open Liberty’s license from EPLv1 to EPLv2. Having received no negative feedback to the proposal, we’ve moved forward with the change. As a result, Open Liberty is released under the EPLv2 license. For more information about the reasoning behind and implications of moving from EPLv1 to EPLv2, refer to the proposal blog post.

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

  • Use mininum jdkSourceLevel of 1.8 for JDK 20+

    In JDK 20, javac has removed support for Java 1.7 compiling. This change causes the following errors in JSP when jdkSourceLevel="17" (Java version 1.7) is specified: JSPG0049E: /xxxxxxxxx.jsp failed to compile :
    error: Source option 7 is no longer supported. Use 8 or later.

    When Java 20 or higher is the runtime, the jdkSourceLevel specified by the user is overwritten to 18 if a lower level is specified. After the fix, when Java 20 or higher is used and a jdkSourceLevel is set to 17 or lower, the value is overwritten to 18.

  • Default keystore file not getting detected on file monitoring

    An issue was present that prevented the default keystore file from being reloaded when a change occurred if the updateTrigger attribute used mbean (the default value).

    The issue has been resolved and the file monitoring now properly occurs for this scenario, causing the file to be reloaded as expected.

  • JDBCDriverService; issue with Boolean parameters

    A change in the Microsoft JDBC driver has caused a regression when boolean values are used for attributes in the property. This change causes an error similar to the following example: W DSRA8021W: Warning: error setting 'encrypt'=true: java.lang.IllegalArgumentException: argument type mismatch
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    A change has been delivered that converts the boolean value to the now expected String, resolving the issue.

  • IndexOutOfBoundsException can occur during a resource outage.

    A java.lang.IndexOutOfBoundsException might occur during a backend resource outage. During an outage, connections that are marked to be destroyed should not be reused. Although the bad connection is removed, a following match can cause it to try to be reused, throwing the following exception:

    StackTrace=java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
            at java.util.ArrayList.rangeCheck(
            at java.util.ArrayList.remove(

    The issue has been resolved and the java.lang.IndexOutOfBoundsException no longer occurs.

  • JTOpen Toolbox driver 11.1 JDBC connections fail from Open Liberty to IBM i

    When using the IBM JTOpen toolbox driver 11.1 to establish a JDBC connection with an IBM i system, the connection fails with the following error:

    {exception=The application server rejected the connection. (Password is not set.) DSRA0010E: SQL State = 08004, Error Code = -99,999, id=jdbc/database}

    and stacktrace:

    [INFO] [WARNING ] DSRA8021W: Warning: error setting 'password'=******: java.lang.NoSuchMethodException: [C.<init>(java.lang.String)
    [INFO]  at java.base/java.lang.Class.getConstructor0(
    [INFO]  at java.base/java.lang.Class.getConstructor(
    [INFO]  at

    The runtime has been updated to handle char[] values for passwords, resolving the issue.

  • Messaging client hangs during shutdown

    There exists a small timing window when an application might try to connect to a remote messaging engine while the server-acting-as-client is creating a new keystore. During the shutdown of the messaging client, a new outbound connection might be created that is never cleaned up. The next server shutdown then hangs indefinitely.

    The issue has been resolved by ensuring that no new outbound connection is allowed while the messaging client is shutting down.

  • A syntax error in JSP compile should consistently output error JSPG0077E

    The JSPG0077E error message was not being output to messages.log and console.log in all cases of a JSP Syntax Error (JspCoreException). This message was missing if the syntax error is hit in a JSP that previously wasn’t compiled and precompile is disabled.

    The issue has been resolved and the JSPG0077E error message gets correctly printed in the log.

  • Stopping liberty Windows service immediately after starting results in hang condition

    When a Liberty server is registered as a Windows service, if the service is stopped immediately after being started, a hang condition occurs.

    The issue has been resolved and the server no longer hangs when the service is immediately stopped after being started.

  • Scripts do not respect the enable_variable_expansion indicator in server.env

    As documented, the server command script allows variable expansion in the server.env file when the comment # enable_variable_expansion is found in the file. However, the rest of the scripts under wlp/bin ignore the # enable_variable_expansion comment, and the expected variable expansion fails to take place.

    This issue has been resolved, and all scripts in wlp/bin directory properly support variable expansion when the # enable_variable_expansion comment is set in the server.env file.

  • PKCE parameters not copied by oauthForm.js

    The consent page, accessed through the /authorize endpoint, does not pass all parameters from the original request. This causes the PKCE’s code_challenge and code_challenge_method parameters to be missing, resulting in a CWOAU0033E error from the authorization endpoint.

    This issue has been resolved and the PKCE’s parameters are accepted.

Get Open Liberty now