back to all blogsSee all blog posts

OpenJDK 11 updates on Open Liberty 19.0.0.5 and beta status PostgreSQL support

image of author
Laura Cowen on May 24, 2019

In 19.0.0.5, we have an update to the Java 11 support in Open Liberty. To get it, run your app with the latest version of Open Liberty.

If you’re feeling curious about what’s coming soon in Open Liberty, take a look at the 'beta status' features in the latest development builds, including MicroProfile Context Propagation (which extends Java EE concurrency concepts to microservices), support for the PostgreSQL database, and a means of testing your app’s database connections with REST APIs.

Run your apps using 19.0.0.5

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

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

Or for Gradle:

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

Or if you’re using Docker:

docker pull open-liberty

Or take a look at our Downloads page.

Ask a question on Stack Overflow

Support for OpenJDK 11 with Hotspot

Support for TLSv1.3 has been turned on for OpenJDK 11.0.3 with Hotspot, meaning that Open Liberty will now work with both of the main JVMs (OpenJ9 and Hotspot).

Previews of early implementations available in beta status

You can now also try out early implementations of some new capabilities in the latest Open Liberty development builds:

These early implementations are not available in 19.0.0.5 but you can try them out by downloading the latest Open Liberty development build. Let us know what you think!

Support for PostgreSQL relational database

PostgreSQL is a very popular open source relational database that has a wide amount of adoption in the community. Now there is a first-class configuration support for using it with Open Liberty.

To use PostgreSQL with Open Liberty, first make sure one of the JDBC features is enabled:

<featureManager>
    <feature>jdbc-4.2</feature>
    <feature>jndi-1.0</feature> <!-- Required only if JNDI is desired to look up resources -->
</featureManager>

Then, configure a data source as follows:

<dataSource jndiName="jdbc/postgresql">
  <jdbcDriver libraryRef="PostgresLib" />
  <properties.postgresql serverName="localhost" portNumber="5432" databaseName="SAMPLEDB"
                         user="bob" password="secret"/>
</dataSource>

<library id="PostgresLib">
    <fileset dir="${server.config.dir}/jdbc"/>
</library>

Get the JDBC driver for PostgreSQL from Maven Central.

Get the Postgres Docker images from DockerHub.

For more about PostgreSQL, see PostgreSQL website.

Testing database connections in Liberty apps with REST APIs

How many times have you had to write a server-side test that gets a connection just to check if your configuration is valid and your app can connect to your database? Now by utilizing the REST API provided by the configValidator-1.0 beta feature, you can validate supported elements of your configuration via REST endpoints.

To enable these REST endpoints, add the configValidator-1.0 beta feature to any server using JDBC, JCA, or JMS technologies. For more information checkout this blog post.

<featureManager>
    <feature>configValidator-1.0</feature>
</featureManager>

MicroProfile Context Propagation 1.0 (formerly MicroProfile Concurrency 1.0)

MicroProfile Context Propagation (formerly MicroProfile Concurrency) allows you to create completion stages that run with predictable thread context regardless of which thread the completion stage action ends up running on.

MicroProfile Context Propagation provides completion stages that run with predictable thread context that also benefit from being backed by the automatically-tuned Liberty global thread pool. Configuration of concurrency constraints and context propagation is possible programmatically with fluent builder API where defaults can be established using MicroProfile Config.

To enable the MicroProfile Context Propagation 1.0 feature in your server.xml:

<featureManager>
    <feature>mpContextPropagation-1.0</feature>
    <feature>cdi-2.0</feature> <!-- used in example -->
    <feature>jndi-1.0</feature> <!-- used in example -->
    ... other features
</featureManager>

Example usage of programmatic builders:

ManagedExecutor executor = ManagedExecutor.builder()
    .maxAsync(5)
    .propagated(ThreadContext.APPLICATION, ThreadContext.SECURITY)
    .build();

CompletableFuture<Integer> stage1 = executor.newIncompleteFuture();
stage1.thenApply(function1).thenAccept(value -> {
    try {
        // access resource reference in application's java:comp namespace,
        DataSource ds = InitialContext.doLookup("java:comp/env/jdbc/ds1");
        ...
    } catch (Exception x) {
        throw new CompletionException(x);
    }
};
...
stage1.complete(result);

Example usage in a CDI bean:

// CDI qualifier which is used to identify the executor instance
@Qualifier
@Retention(RetentionPolicy.RUNTIME)
@Target({ ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER })
public @interface AppContext {}

// Example producer field, defined in a CDI bean,
@Produces @ApplicationScoped @AppContext
ManagedExecutor appContextExecutor = ManagedExecutor.builder()
    .propagated(ThreadContext.APPLICATION)
    .build();

// Example disposer method, also defined in the CDI bean,
void disposeExecutor(@Disposes @AppContext exec) {
    exec.shutdownNow();
}

// Example injection point, defined in a CDI bean,
@Inject @AppContext
ManagedExecutor executor;

...

CompletableFuture<Integer> stage = executor
    .supplyAsync(supplier1)
    .thenApply(function1)
    .thenApplyAsync(value -> {
        try {
            // access resource reference in application's java:comp namespace,
            DataSource ds = InitialContext.doLookup("java:comp/env/jdbc/ds1");
            ...
            return result;
        } catch (Exception x) {
            throw new CompletionException(x);
        }
    });

For more information: