JDK 18: The new features in Java 18

Java Development Kit (JDK) 18 is now available as an official production release. The new version of standard Java has nine new features, including a simple web server and another preview of pattern matching for switch.

The OpenJDK page lists the following features as officially targeting JDK 18: a service provider interface, a simple web server, a third incubation of the vector API, code snippets, a reimplementation of core reflection, a UTF-8 charset, a second incubator of a foreign function and memory API, a second preview of pattern matching for switch statements, and the deprecation of finalization, which was the last addition.

While JDK 17 was a long-term support (LTS) release that will receive at least eight years of support from Oracle, JDK 18 will be a short-term feature release that is supported for six months. JDK 18 can be downloaded from oracle.com.

Specifics of the JDK 18 proposals include:

• Deprecate finalization for removal in a future release. Finalizer has flaws that cause significant real-world problems in security, performance, reliability, and maintainability. It also has a difficult programming model. Finalization is enabled by default for now but can be disabled to facilitate early testing. It will be disabled by default in a feature release and removed altogether in a later release. The proposal calls for a command-line option to disable finalization and deprecation of all finalizers and finalization methods in the standard Java API. Goals of the proposal include helping developers understand the dangers of finalization, preparing developers for its eventual removal, and providing simple tools to help detect reliance on finalization. Introduced in Java 1.0, finalization was intended to help avoid resource leaks. A class can declare a finalizer — the method protected void finalize() — whose body releases any underlying resource. The garbage collector will schedule the finalizer of an unreachable object to be called before it reclaims object memory; in turn, the finalize method can take actions such as calling the object’s close. This seems like an effective safety net for preventing resource leaks, but flaws exist including unpredictable latency, with a long time passing between when an object becomes unreachable and when its finalizer is called; unconstrained behavior, with finalizer code able to take any action, including resurrecting an object and making it reachable again; finalizer is always enabled, with no explicit registration mechanism; and finalizers can run on unspecified threads in an arbitrary order. Given the problems with finalization, developers are advised to use alternative techniques to avoid resource leaks, namely try-with-resources statements and cleaners. (See JDK Enhancement Proposal 421 for details.)
• For the Internet-address resolution SPI, the proposal is to define an SPI for host and name address resolution so that Inet.Address can make use of resolvers other than the platform’s built-in resolver. Motivations for this effort include better enablement of Project Loom, for concurrency and new programming models in Java, along with integrating new network protocols, customization, and enabling testing. The proposal does not involve developing an alternative resolver for the JDK.
• A second preview of pattern matching for switch, in which the Java language would be enhanced with pattern matching for switch expressions and statements, along with extensions to the language of patterns. This was previewed in JDK 17. Extending pattern matching to switch allows an expression to be tested against a number of patterns, each with a specific action, so complex data-oriented queries can be expressed concisely and safely. This feature comes from Project Amber, an OpenJDK project focused on smaller, productivity-oriented Java features. “Pattern matching for switch is something every Java programmer is going to see and run into and will be able to take advantage of,” said Georges Saab, vice president of the Java platform group at Oracle. The capability shows broad support for pattern matching in Java; previously it was available for instanceof. This style of programming will become second nature, Saab said.
• The reimplementation of core reflection with method handles would reimplement lang.reflect.Method, Constructor, and Field on top of java.lang.invoke method handles. Having method handles serve as the underlying mechanism for reflection will reduce maintenance and development costs of both the java.lang.reflect and java.lang.invoke APIs.
• With the simple web server proposal, a command-line tool would be provided to start a minimal web server that serves static files only. No CGI or servlet-like functionality is available. The tool will be useful for prototyping, ad-hoc coding, and testing, particularly in educational contexts. Goals of the plan include offering an out-of-the-box static HTTP file server with easy setup and minimal functionality, reducing developer activation energy and making the JDK more approachable, and providing a default implementation via the command line together with a small API for programmatic creation and customization. Providing a feature-rich or commercial-grade server is not a goal of the proposal.
• A second incubation of a foreign function and memory API, in which an API is introduced through which Java programs can interoperate with code and data outside of the Java runtime. By invoking foreign functions – code outside the JVM – and by safely accessing foreign memory – memory not managed by the JVM – the API lets Java programs call native libraries and process native data without the brittleness and danger of JNI (Java Native Interface). The intent is to replace JNI with a superior, pure Java development model. This API was incubated in JDK 17. For JDK 18, refinements would be incorporated, based on feedback, such as support for more carriers such as Boolean and MemoryAddress in memory access var handles, and a new API to copy Java arrays to and from memory segments.
• The vector API would be incubated for a third time in JDK 18, having previously been incubated in JDK 16 and JDK 17. This proposal would express vector computations that compile at run time to optimal vector instructions on supported CPU architectures, achieving performance superior to equivalent scalar computations. Vector operations express a degree of parallelization enabling more work to be done on a single CPU cycle, thus producing significant performance improvements. The platform-agnostic vector API aims to provide a way to write complex algorithms in Java, using the existing HotSpot auto-vectorizer but with a user model that makes vectorization more predictable. JDK 18 would also add support for the ARM Scalar Vector Extension platform and improve performance of vector operations that accept masks on architectures that support masking in hardware. The vector API also was derived from Project Panama. 
• Specifying UTF-8 as the default charset of the standard Java APIs. UTF-8 is a variable-wide character encoding for electronic communication and is considered the web’s standard charset. Charset is character encoding capable of encoding all characters on the web. Through this change, APIs that depend on the default charset will behave consistently across all implementations, operating systems, locales, and configurations. The proposal is not intended to define new Java-standard or JDK-specific APIs. Proponents of the proposal expect that applications in many environments will see no impact from Java’s choice of UTF-8, as MacOS, many Linux distributions, and many server applications already support UTF-8. However, there is risk in other environments, the most obvious being that applications depending on the default charset will behave incorrectly when processing data produced when the default charset was unspecified. Data corruption may silently occur. The main impact is expected to be fall on users of Windows systems in Asian locales and possibly some server environments in Asian and other locales.
• Code snippets in Java API documentation, involving the introduction of an @snippet tag for JavaDoc’s Standard Doclet, to simplify inclusion of example source code in API documentation. Among goals of the plan is facilitating the validation of source code fragments by providing API access to those fragments. While correctness is the responsibility of the author, enhanced support in JavaDoc and related tools can make it easier to achieve. Other goals include enabling modern styling, such as syntax highlighting, as well as the automatic linkage of names to declarations, and enabling better IDE support for creating and editing snippets. The proposal notes that authors of API documentation often include fragments of source code in documentation comments.

Although JDK 18 is a non-LTS (Long Term Support) release backed by only six months of support, it still is production quality, Saab said. LTS releases arrive every two years, with the next one, JDK 21, due in September 2023. Following JDK 18, JDK 19 is due this September.