WebSphere Application Server & Liberty

The Semeru Runtime Open Edition 18.0.1 was released on April 25, 2022 bringing Java 18 features running on the Eclipse OpenJ9 JVM. This release is the first Java 18 release for Semeru Runtimes. Although we hadn't intended to skip the GA release, we made the decision to skip it so we could resolve some bugs discovered late in our release process.

You can find these binaries at our download site.

One of the exciting things about this April update release with Java 18 is that we've included early access binaries for the Mac M1 platform (MacOS on AArch64), also available for Java 11.0.15 and 17.0.3 . The binaries for this platform are stable enough for evaluation, but we aren't yet ready to recommend them for production use. In particular, these early access binaries do not yet use compressed references (a technique that stores 64-bit heap references in just 32-bits so long as your heap doesn't exceed a certain size). We'll be making more improvements for this platform in upcoming releases, but we are interested in any user feedback, so please try them out if you're interested in this platform!

Since this release is our first for Java 18, here is the list of the key JEPs (Java Enhancement Proposals) that are included :

• 400: UTF-8 by Default
• 408: Simple Web Server
• 413: Code Snippets in Java API Documentation
• 416: Reimplement Core Reflection with Method Handles
• 418: Internet-Address Resolution SPI
• 420: Pattern Matching for switch (Second Preview)
• 421: Deprecate Finalization for Removal

There have been lots of articles describing these JEPs and how to use, for example, the switch pattern matching, so I won't bother duplicating all the great material that's already out there. Instead, I'd like to focus on what I think are the most important parts of this release for projects that primarily ship on or with LTS (Long Term Support) releases. We just saw Java 17 come out a few short months ago and Java 18 is not an LTS release, so why is this release important?

There are many good reasons to pay attention to the "Feature" releases that come out every six months between LTS releases. One of the most important ones is that you get an early view on things that might require you to make changes in your application when you do pick up a new Semeru Runtime version. For example, there are some JEPs in that list you may want to take note of, in particular:

• 400: UTF-8 by Default
• 421: Deprecate Finalization for Removal

These JEPS suggest things are changing in ways that may affect your applications, so you may need to plan for them so that your next LTS migration is smooth. Let's look into each of them.

JEP 400: UTF-8 by Default

As the name describes, JEP 400 changes the default charset used by the JDK to be UTF-8. In earlier Java versions, the default charset was set at startup using a variety of platform-specific heuristics, such as the current locale setting. You can find out the default charset used by your current JDK by examining the file.encoding property. For example, you can run this command:


If you see a different charset than UTF-8, or you're worried about what will happen when you start to run your application on Java 18, then you can do some testing using your current JDK simply by overriding the file.encoding property to UTF-8:


However, it's not just your program's runtime behaviour that may be affected. The way your program is compiled by javac can be affected by the change to the default charset in Java 18. So you will also want to test how compiling your program may be affected when you move to Java 18. Just like you can set the file encoding on your current JDK when you run your application, you can also set a similar parameter on your javac command to test the affect of the default charset change without upgrading to Java 18:


I especially recommend developers for IBM platforms to test the effect of the default change in charset as UTF-8 may not be the default charset you'll see on POWER or Z. You may not see any problems, but when things change, it's better to be sure than to be caught by surprise!

Another change in this JEP that could catch some users is that calling Charset.forName("default") will now throw an UnsupportedCharsetException. This call is used in some applications to get the default charset, but it's no longer the accepted way to do it (instead you should call Charset.defaultCharset(). More details on why this change to the default charset has been made can be found in the JEP document itself.

JEP 421: Deprecate Finalization for Removal

This JEP marks finalization as deprecated which, in and of itself, won't break anyone (though deprecated, finalization is still present and enabled by default in Java 18). But it does tell you the direction things are going in. Many Java applications in the world rely on finalizers, usually in an attempt to clean up resources when an object dies. But finalizers are fragile because they aren't guaranteed to run and there are lots of arcane rules about them because they also have to deal with garbage collection and exceptions that bring high complexity into the runtime.

Plus, better (reliable!) ways, like try-with-resources and cleaners, to clean up resources have been available in Java for a long time now. While this JEP won't break your application, it tells you that you should start planning now to eliminate any dependency you have on finalization. That includes communicating with your dependent library and other package maintainers to make sure they're on the path to removing any finalization dependency. Given the size and complexity of
the Java ecosystem, it could take a while for all the libraries you depend on to both eliminate their dependency and be picked up by their downstream consumers (and ultimately, you). Although it's unlikely to happen quickly, I recommend you start planning now so you won't be caught by surprise when finalization is actually removed by some future JEP!

Once you're using Java 18, you can use the --finalization=disabled option to learn what the impact is going to be to your application (this option is new with Java 18). More details are in the JEP description, so check it out!

You can help to improve Java !

Another benefit to trying out feature releases, even if you would only ship your applications on an LTS release, is to be able to provide feedback on how some new features are being implemented. You may have noticed that one of the JEPS is marked as "Preview". These preview JEPS represent new features being added to Java that aren't yet part of the core platform (although the "Preview" features typically have JCK tests associated with them so that all Java SE implementations need to support them). The "Preview" and "Incubator" status simply means that the feature isn't locked in stone and can be changed if feedback is given that warrants a change.

If you don't try them out to see how they might apply for your work, then you won't be able to take advantage of the opportunity! There is usually a large amount of work associated with the JEPS in preview and incubation and we would really like to make sure that we get them right for our users. Without your feedback, all we can do is apply our best reasoning and, in some cases, guesses about how the features will be used. Once these features exit preview and incubator status, they become part of the Java platform and more difficult to change in significant ways. Any feedback you can offer, even just to point out ways you think you might use them, can be invaluable to our development teams and raise the likelihood that these features will eventually provide useful benefits for your Java applications.

Wrapping up

That's it for this article. Whether you're one of those users that picks up the latest and greatest Java release once it's available, or someone who only really works with LTS releases, I hope you'll download and try out the IBM Semeru Runtimes for Java 18 and we welcome your feedback!

Have a question or need to reach us about Semeru Runtimes? Open an issue at our GitHub repo!
#Java
#semeru
#runtime