Changes in Java 18

 

Java 18 released on 22nd March, 2022. It is the first not-LTS version since Java 17. We can split changes in 4 categories:

Core library improvements and updates

JEP 400: UTF-8 by Default

UTF-8 is a variable-width character encoding widely used on the web for electronic communication. Note that charset is a kind of character encoding capable of encoding all of the web’s characters. In Java 18, the default charset of the platform is now UTF-8. This is a change from Java’s previous default charset, which was determined by the host operating system and locale. The main reason for this update is that UTF-8 has become the most widely used charset in the world, so making it an explicit choice in Java simplifies things quite a bit. Trying to store a text like this リリー in Windows and Linux would be different, since Windows by default uses Windows-1252 format.

JEP 408: Simple Web Server

An out-of-the-box static HTTP file server with easy setup and minimal functionality, reducing developer activation energy, making the JDK more approachable, and offering a default implementation via the command line together with a small API for programmatic creation and customization.

The easiest way to start the provided web server is the jwebserver command. It starts the server on localhost:8000 and provides a file browser for the current directory:

$ jwebserver

Binding to loopback by default. For all interfaces use “-b 0.0.0.0” or “-b ::”. Serving /home/sven and subdirectories on 127.0.0.1 port 8000 URL http://127.0.0.1:8000/

EP 416: Reimplement Core Reflection with Method Handle

Reduces the maintenance and development cost of reflection support for future language features. It also simplifies the Hotspot VM code.

JEP 418: Internet-Address Resolution SPI (Service-provider Interface)

Makes it possible to replace the default operating-system native resolver, which usually results in a blocking operating-system call(it usually consults the hosts file and the configured DNS servers), with a developer-provided alternate resolver.

 

Tooling improvements

JEP 413: Code Snippets in Java API Documentation

Introduce an @snippet tag for JavaDoc’s Standard Doclet, to simplify the inclusion of example source code in the API documentation.

Until now, if we wanted to integrate multiline code snippets into JavaDoc, we had to do this quite cumbersomely via <pre>…</pre> – optionally in combination with {@code … }. 

With the @snippet tag, we can write the comment as follows:

/**

 * How to write a text file with Java 7:

 *

 * {@snippet :

 * try (BufferedWriter writer = Files.newBufferedWriter(path)) {

 *   writer.write(text);

 * }

 * }

 */

Previews and Incubators

JEP 417: Vector API – third incubator

Introduces a platform-agnostic, reliable way of clearly and concisely expressing a wide range of vector computations for supported CPU architectures.

JEP 419: Foreign Function and Memory API – second incubator

Greatly simplifies the tools and knowledge required to create Java programs that utilize native. This will allow Java developers access to specialized non-Java libraries. 

JEP 420: Pattern Matching for switch – second preview

Improves Java development productivity by expanding the expressiveness and applicability of switch expressions and statements. Allowing pattern matching in switch will make expressing complex data-oriented queries more concise and safer.

The enhancements since the first preview are:

  • Dominance checking now forces a constant case label to appear before a guarded pattern of the same type, for readability
  • Exhaustiveness checking of switch blocks is now more precise with sealed hierarchies where the permitted direct subclass only extends an instantiation of the (generic) sealed superclass

Deprecations

JEP 421: Deprecate Finalization for Removal

Deprecate finalization for removal in a future release. Finalization remains enabled by default for now, but can be disabled to facilitate early testing. In a future release it will be disabled by default, and in a later release, it will be removed. Finalization has existed since Java 1.0 and is intended to help avoid resource leaks by allowing classes to implement a finalize() method to release system resources (such as file handles or non-heap memory) requested by the operating system.