What Java 18 has to offer

Java 18 was released on March 22, 2022. These are the nine JEPs (Java Enhancement Proposal) implemented.

JEP-400: UTF-8 by Default

Java APIs for reading and writing files can be called with a specific character set for encoding and decoding. If none is specified, the default will be used. Until this JEP however, the default depended on the type of operating system, the used locale, and other configurations.

This JEP consistently specifies that UTF-8 is the default, regardless of the aforementioned conditions, thus ensuring a more consistent behavior across systems.

JEP-408: Simple Web Server

This JEP provides a command-line tool to start a minimal webserver to serve static files only. I must admit I was quite surprised to see this JEP actually being implemented. One of its main reasons to be implemented was to take the burden out of configuring a full-fledged web server. This seems to target especially developers of junior or academic level. Maybe the availability of such tools and the ease of starting up a webserver in other languages have led the Oracle team to decide the need for such a solution.

As this is feature is completely new, I have written about its options and functionality in more detail here.

JEP-413: Code Snippets in Java API Documentation

This JEP is quite interesting and deserves an article in its own right. It allows the validation of code snippets written in Javadoc. It also provides styling options like syntax highlighting.

For this means, a new tag @snippet has been introduced. It allows for better formatting of the code. Moreover, as it has better styling support the need for use of certain html tags (e.g. <pre>) is decreasing.

Snippets can both be inline, as we use to know them, as well as external. Watch this channel to get a detailed review of all the @snippet options soon.

JEP-416: Reimplement Core Reflection with Method Handles

This JEP was born purely out of the fear of a maintenance nightmare waiting to happen. Since the introduction of method handles way back in Java 7 there are now three ways to perform reflective operations:

• native VM methods
• Stubs that are dynamically generated by the compiler
• method handles

With the upcoming changes that Project Valhalla will bring (value objects/primitive classes for example) this would mean that three different branches of reflection code would need to be maintained.

In order to limit this, it has been decided to solely use method handles for reflection. These changes have no impact on user source code, but there could be a small performance penalty if method Method, Class, and Field instances are not held in static instances.

JEP-417: Vector API (Third Incubator)

This is the third iteration of this API, which was first introduced in JDK 16. Changes from the previous version included the support for ARM Scalar Vector Extensions and performance improvements for vector operations that support hardware masking.

JEP-418: Internet-Address Resolution SPI

Defines an SPI (Service Provider Interface) for hostname and address resolution. The current implementation uses an operating system native version, while this JEP allows for a pluggable architecture which we have seen in many different places in Java already (e.g. JDBC)

JEP-419: Foreign Function & Memory API (Second Incubator)

This JEP is in its second iteration and the changes in this version are mainly dealing with some API changes. Seems that it is considered stable and JEP-424, in which this functionality will become a preview feature, is targetted for JDK 19.

JEP-420: Pattern Matching for switch (Second Preview)

This is the second preview for pattern matching for switch. Since the previous version, the dominance and exhaustiveness checking have undergone some minor changes.

JEP-421: Deprecate Finalization for Removal

The removal of finalization from the Java language has been going on for some time. The finalize method was deprecated back in Java 9. Finalization has some known issues: it is not guaranteed to be called at all, it swallows any exceptions it might encounter, there is no registration mechanism, improper use of the method might lead to the resurrection of garbage collection ready objects, to name a few.

A number of alternatives have been added to the language to discourage its use. try-with-resources, for example, will guarantee that a resource (e.g. a file) be closed when it runs out of scope which is a much better approach than (hoping for) closing the resource in a finalize method.

For other cleanups, Java introduced the Cleaner object in Java 9. This allows you to register your objects with a Cleaner. The cleaning actions are run once your registered object becomes Phantom-reachable. While this has been around for some years I did notice that it is a little-known feature among Java developers and it is something I would like to address in a future article.

This JEP involves two things. First off, it offers a new command-line option —finalization=disabled. This will prevent finalize method from being executed and allows you to check if your code does still behave as expected once finalization is completely removed from the language. The allows you prepare for when this time comes.

The second enhancement this JEP offers is that it deprecates all finalizers, and finalization-related methods, in the standard Java API. This does not mean they are removed or replaced by Cleaners yet, it is just another step in the long, long road to complete removal from the JDK.

What’s next

I was a bit disappointed to see that none of the newer pattern-matching JEPs made it into Java 18. So I am rooting that either of them makes it into Java 19 as a preview function. My guess would be on pattern matching for records. I especially like the destructuring part of it.

While it used to talk about array pattern-matching as well, that sadly seems to have disappeared from the text.

But at the time of this writing, only one JEP is officially known for Java 19 due in September 2022. Keep an eye on new ones being added here.