JDK 18: What to expect in Java 18

As of March 2022, Java 18 continues to add features, and nine feature proposals are being considered so far, including deprecation of termination, a capability that was intended to help prevent resource leaks but has come with risk. unlimited behavior and unpredictable latency. .

the OpenJDK page for Java Development Kit (JDK) 18 lists the following features as officially targeting JDK 18 as of Nov 24: a service provider interface, a simple web server, a vector API, code snippets, a core reflection reimplementation, a character set UTF-8, a second incubator for an external function and memory API, and a second preview of pattern matching for change statements. It is proposed to disable termination to point to JDK 18 in the JDK Improvement Proposal Index (JEP).

General availability expires on March 22, 2022, after the slowdown phases that occur on December 9, 2021 and January 20, 2022. Version candidates expire on February 10 and February 24 of next anus.

While JDK 17, released on September 14, 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 will be supported for six months. The early access builds of JDK 18 can be found for Linux, Windows, and MacOS at java.net.

Details of the JDK 18 proposals include:

  • Set completion aside for deletion in a future release. Finalizer has flaws that cause major problems in the real world in terms of safety, performance, reliability, and ease of maintenance. It also has a difficult programming model. Completion 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 completely removed in a later release. The proposal requires a command line option to disable completion and deprecation of all finalizers and completion methods in the standard Java API. The goals of the proposal include helping developers understand the dangers of completion, preparing developers for eventual removal, and providing simple tools to help detect completion dependency. Introduced in Java 1.0, completion was intended to help prevent resource leaks. A class can declare a finalizer: the method protected void finalize() – whose body releases any underlying resources. The garbage collector will schedule the terminator of an unreachable object to be called before it reclaims the object’s memory; in turn, the finalize The method can perform actions like calling the object close. This seems like an effective safety net to prevent resource leaks, but there are flaws that include unpredictable latency, with a long time between when an object becomes unreachable and when its finalizer is called; unrestricted behavior, with finalizer code capable of performing any action, including resurrecting an object and making it accessible again; the finalizer is always enabled, without an explicit registration mechanism; and finalizers can run on unspecified threads in an arbitrary order. Given the issues with completion, developers are advised to use alternate techniques to avoid resource leaks, namely test statements with resources and cleaners. (Watch JDK 421 Enhancement Proposal for details.)
  • For him Internet Address Resolution SPI, the proposal is to define an SPI for host and name address resolution so that Inet.Address You can make use of resolvers other than the platform’s built-in resolver. Motivations for this effort include better empowerment of Loom Project, for concurrency and new Java programming models, along with the integration of new network protocols, customization, and test enablement. The proposal does not involve the development of an alternative solver 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 declarations, along with extensions to the pattern language. This was seen in JDK 17. Extending pattern matching to switch allows you to test an expression against multiple patterns, each with a specific action, so complex data-oriented queries can be expressed concisely and safely.
  • the reimplementation of kernel reflection with method handles would re-implement lang.reflect.Method, Constructor, and Field Above java.lang.invoke method identifiers. The fact that method identifiers serve as the underlying mechanism for reflection will reduce maintenance and development costs for both java.lang.reflect and java.lang.invoke API.
  • With the simple web server proposal, a command line tool would be provided to start a minimal web server serving only static files. No CGI or servlet-like functionality is available. The tool will be useful for prototyping, ad-hoc coding, and testing, especially in educational contexts. The goals of the plan include offering a ready-to-use static HTTP file server with easy setup and minimal functionality, reducing developer wake-up power and making the JDK more accessible, and providing a default implementation across the line command along with a small API. for programmatic creation and customization. Providing a feature-rich or commercial-grade server is not an objective of the proposal.
  • A second incubation of a Memory API and foreign function, which introduces an API through which Java programs can interoperate with code and data outside of the Java runtime. By invoking external functions (code outside the JVM) and safely accessing external memory (memory not managed by the JVM), the API allows Java programs to call native libraries and process native data without the fragility and clutter. JNI (Java Native Interface) danger. The intention is to replace JNI with a pure and superior Java development model. This API was incubated in JDK 17. For JDK 18, improvements would be incorporated, based on feedback, such as support for more carriers such as Boolean and MemoryAddress in memory access var identifiers, and a new API for copying arrays Java to and from memory. segments.
  • the Vector API it would be incubated for the third time in JDK 18, having previously been incubated in JDK 16 and JDK 17. This proposal would express vector calculations that compile at run time to optimal vector instructions in supported CPU architectures, achieving superior performance to equivalent scalar calculations. Vector operations express a degree of parallelization that allows more work to be done in a single CPU cycle, leading to significant performance improvements. The Platform Independent Vector API aims to provide a way to write complex algorithms in Java, using the existing HotSpot automatic 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 the performance of vector operations that accept masks on architectures that support hardware masking.
  • Specify UTF-8 as the default character set for standard Java APIs. UTF-8 is a variable-width character encoding for electronic communication and is considered the standard character set for the web. Charset is a character encoding capable of encoding all characters on the web. With this change, APIs that depend on the default character set will behave consistently across deployments, operating systems, locales, and configurations. The proposal is not intended to define new standard Java APIs or JDK-specific ones. Proponents of the proposal hope that applications in many environments will see no impact from Java’s choice of UTF-8, since MacOS, many Linux distributions, and many server applications already support UTF-8. However, there is a risk in other environments, the most obvious being that applications that depend on the default character set will behave incorrectly when processing data produced when the default character set was not specified. Data corruption can happen silently. The main impact is expected to be on Windows system users in Asian locales and possibly some server environments in Asian and other regions.
  • Code snippets in the Java API documentation, which involves the introduction of a @snippet for the standard JavaDoc Doclet, to simplify the inclusion of sample source code in the API documentation. Among the goals of the plan is to facilitate the validation of source code snippets by providing API access to those snippets. While correctness is the responsibility of the author, improved support in JavaDoc and related tools may make it easier to achieve. Other goals include enabling modern styling, such as syntax highlighting, as well as automatic linking of names to statements, and allowing better IDE support for creating and editing fragments. The proposal notes that API documentation authors often include source code snippets in documentation comments.

Copyright © 2021 IDG Communications, Inc.

Leave a Comment