Java: It’s Time to Move Your Application to Java 11

In the past few years, several exciting things have happened in the Java world, among them is certainly the new version control. Previously, it could take anywhere between two or three years for a new version to be released. Now, there's a new cadence every six months in addition to the LTS for new versions of the JVM. Currently, there is already work to deliver Java 14, however, as the latest research reveals, the use of Java 8 remains very strong for the market. This post aims to encourage and discuss the reasons for upgrading to Java 11, the current Java LTS.

There are several Java surveys that show that Java 8 is still the most popular version among developers, such as the SNYK that shows Java 8 with 64% against 25% in Java 11 and Eclipse Foundation where the number is even more significant with 80% with Java 8 against 20% with Java 11.

Indeed, Java 8 brings terrific features, such as Lambda, new date and time, and Streams that make Java 8 the most loved version for Java developers. Furthermore, the release every six months is scary for some developers, but we also have the Long term support version that works, and it happens every three years, thus either we can release every six months or jump LTS to LTS three years.

We'll talk about the current LTS version and why we should move to it. The first reason for security purposes. There is no Java 8 public release anymore. Thus, Java 8 won't be continued to be patched for common vulnerabilities and exposures, CVE.

The second reason concerns performance. In the Java 11 (and since Java 9), there have been several improvements, such as:

• Next LTS version.

• Full support for Linux containers.

• Support parallel full garbage collection on G1.

• Free Application Class-Data Sharing feature.

• Heap allocation on alternative memory devices.

• New default set of root authority certificates.

• New ZGC and Epsilon garbage collectors.

• Ahead-of-time compilation and GraalVM.

• Transport Layer Security (TLS) 1.3.

 (You can read more about these on this blog.)

We can see several benchmarks that show an improvement of around 20% with these changes. Furthermore, we don't need to update the code to move from Java 8; we can run Java 8 code on the Java 11 JVM, and we can see some improvements such as memory and boot time.

This post won't talk about the news features of Java 11, but we'll focus on the benefits of moving to Java 11. To keep your code working, we need to be aware of the JEP 320: Remove the Java EE and CORBA Modules. If you are using dependencies you need to add that dependency in your favorite build tools. There are several tips about migration on this post.

Update a Java 8 Application

To show how easy it is to migrate a Java 8 project to Java 11, let's take a look at an example. The first our first post about Hello world at Platform.sh with Spring.

To update the application, we need to update a single file: the platform.app.yaml file. So, we take this file:

name: app

type: "java:8"

disk: 1024

hooks:

  build: mvn clean install

relationships:

  database: "database:mysql"

web:

  commands:

    start:  java -jar target/spring-boot-maven-mysql.jar --server.port=$PORT

We'll update this file to Java 11. Therefore, Platform.sh will generate a container using Java 11 version instead of Java 8.

xxxxxxxxxx

name: app

type: "java:11"

disk: 1024

hooks:

  build: mvn clean install

relationships:

  database: "database:mysql"

web:

  commands:

    start:  java -jar target/spring-boot-maven-mysql.jar --server.port=$PORT

The application is now ready, so it’s time to move it to the cloud with Platform.sh using the following steps:

• Create a new free trial account.

• Sign up with a new username and password, or login using a current  GitHub, Bitbucket, or Google account. If you use a third-party login, you’ll be able to set a password for your Platform.sh account later.

• Select the region of the world where your site should live.

• Select the blank template.

After this, Platform.sh will provision the whole infrastructure for you and offer a Git remote repository. Before access, remember to set your SSH keys. You only need to write your code — including a few YAML files that specify your desired infrastructure — then commit it to Git and push.

xxxxxxxxxx

git remote add platform <platform.sh@gitrepository>

git commit -m "Initial project"

git push -u platform master

In the next sample, let's use a Jakarta EE sample with the Payara server. We'll use the template from Platform.sh. We'll do a similar procedure with Spring in the application file. So, we'll take the application file:

xxxxxxxxxx

name: app

type: "java:8"

disk: 1024

hooks:

    build:  mvn clean package payara-micro:bundle

web:

    commands:

        start: java -jar -Xmx512m target/microprofile-microbundle.jar --port $PORT

Then, update the type to "java:11". Now, we'll run the application with Java 11.

xxxxxxxxxx

name: app

type: "java:11"

disk: 1024

hooks:

    build:  mvn clean package payara-micro:bundle

web:

    commands:

        start: java -jar -Xmx512m target/microprofile-microbundle.jar --port $PORT

Whether it's performance improvements that containers benefit a lot from or the fact that security updates are no longer made in version 8, I hope you see a benefit to upgrading to Java 11. In the next part of this series, we will talk a little about the API improvements that exist within Java 11.