Due in September, Java 17 continues to take shape, with seven features planned for the upgrade to standard Java so far plus two feature removals and one feature deprecation. In the latest changes, as of May 20, pattern matching for
switch expressions and statements and strong encapsulation of JDK internals have been added.
Java Development Kit (JDK) 17 will be a long-term-support (LTS) release, with extended support from Oracle expected for several years. Features filed as part of OpenJDK’s JDK 17 include the following:
- Pattern matching for
switchextends the language of patterns in Java to allow
switchexpressions and statements to be tested against a number of patterns, each with a specific action. This enables complex data-oriented queries to be expressed concisely and safely. Among the goals of this feature include expanding the expressiveness and application of
switchexpressions and statements by enabling patterns to appear in case labels, relaxing the historical null-hostility of
switchwhen desired, and introducing two kinds of patterns:
guarded patterns, which allow pattern matching logic to be refined with arbitrary Boolean expressions, and
parenthesized patterns, which resolve some parsing ambiguities. In JDK 16, the
instanceofoperator was extended to take a type pattern and perform pattern matching. The modest extension proposed allows the familiar instanceof-and-cast idiom to be simplified.
- Strong encapsulation for JDK internals, except for critical internal APIs such as
misc.unsafe, would make it no longer be possible to relax the strong encapsulation of internal elements via a single command-line option, as was doable in JDK 9 through JDK 16. Goals of the plan include improving security and maintainability of the JDK and encouraging developers to migrate from internal elements to standard APIs.
- Removal of the Remote Method Invocation (RMI) Activation mechanism while preserving the rest of RMI. The RMI Activation mechanism is obsolete and disused and was deprecated for removal in JDK 15.
- The foreign function and memory API, introduced an incubator stage, allows Java programs to interoperate with code and data outside of the Java runtime. By efficiently invoking foreign functions, i.e., code outside the JVM, and safely accessing foreign memory, i.e., memory not managed by the JVM, the API enables Java programs to call native libraries and process native data without the brittleness and risk of JNI (Java Native Interface). The API proposed is the evolution of two APIs — the foreign memory access API and the foreign linker API. The foreign memory access API was targeted to Java 14 in 2019 as an incubating API and re-incubated in Java 15 and Java 16. The foreign linker API was targeted to Java 16 as an incubating API in late-2020. Goals of the API plan include ease of use, performance, generality, and safety.
- Integrated into JDK 16 as an incubating API, the platform-agnostic vector API will be incubated again in JDK 17, providing a mechanism to express vector computations that reliably compile at run time to optimal vector instructions on supported CPU architectures. This achieves better performance than equivalent scalar computations. In JDK 17, the vector API has been enhanced for performance and implementation, including enhancements to translate byte vectors to and from boolean arrays.
- Sealed classes and interfaces restrict which other classes or interfaces may extend or implement them. Goals of the proposal include allowing the author of a class or interface to control which code is responsible for implementing it, providing a more declarative way than access modifiers to restrict the use of a superclass, and supporting future directions in pattern matching by providing a foundation for the exhaustive analysis of patterns.
- Removal of the experimental AOT and JIT compiler, which has seen little use but requires significant maintenance effort. The plan calls for maintaining the Java-level JVM compiler interface so developers can keep using externally built versions of the compiler for JIT compilation. AOT compilation (the jaotc tool) was incorporated into JDK 9 as an experimental feature. The tool uses the Graal compiler, which is itself written in Java, for AOT compilation. These experimental features were not included in JDK 16 builds published by Oracle and no one complained. Under the plan prescribed, three JDK modules would be removed: jdk.aot (the jaotc tool); internal.vm.compiler, the Graal compiler; and jdk.internal.vm.compiler.management, the Graal MBean. HotSpot code related to AOT compilation also would be removed.
- Porting the JDK to MacOS/AArch64 in response to Apple’s plan to transition its Macintosh computers from x64 to AArch64. An AArch64 port for Java already exists for Linux and work is underway for Windows. Java builders expect to reuse existing AArch64 code from these ports by employing conditional compilation, as is the norm in ports of the JDK, to accommodate differences in low-level conventions such as the application binary interface and the set of reserved processor registers. Changes for MacOS/AArch64 risk breaking the existing Linux/AArch64, Windows/AArch64, and MacOS/x64 ports, but the risk will be reduced through pre-integration testing.
- Deprecating the Applet API for removal. This API is essentially irrelevant, since all web browser vendors either have removed support for Java browser plug-ins or have announced plans to do so. The Applet API previously was deprecated, but not for removal, in Java 9 in September 2017.
- A new rendering pipeline for MacOS, using the Apple Metal API as an alternative to the existing pipeline that uses the deprecated OpenGL API. This proposal is intended to provide a fully functional rendering pipeline for the Java 2D API that uses the MacOS Metal framework and be ready in the event Apple removes the OpenGL API from a future version of MacOS. The pipeline is intended to have functional parity with the existing OpenGL pipeline, with performance as good or better in select applications and benchmarks. A clean architecture would be created that fits into the current Java 2D model. The pipeline would coexist with the OpenGL pipeline until obsolete. It is not a goal of the proposal to add any new Java or JDK APIs.
- Enhanced pseudo-random number generators that would provide new interface types and implementations for pseudorandom number generators (PRNGs) including jumpable PRNGs and an additional class of splittable PRNG algorithms (LXM). A new interface,
RandomGenerator, would supply a uniform API for all existing and new PRNGs. Four specialized RandomGenerator interfaces would be provided. Motivating the plan is a focus on multiple areas for improvement in the area of pseudorandom number generation in Java. The effort does not call for providing implementations of numerous other PRNG algorithms. But three common algorithms have been added that already are widely deployed in other programming language environments. Goals of the plan include:
- Making it easier to use various PRNG algorithms interchangeably in applications.
- Improved support for stream-based programming, providing streams of PRNG objects.
- Elimination of code duplication in existing PRNG classes.
- Preservation of existing behavior of class
September 14 has been slated as the general availability date for JDK 17. The production release will be preceded by rampdown phases in June and July and release candidates in August. Early-access open source builds of JDK 17 can be found at jdk.java.net.
LTS releases such as JDK 17 arrive every three years. The last LTS release, JDK 11, was published in September 2018. New releases of Java arrive every six months.
Copyright © 2021 IDG Communications, Inc.