Due in September, Java 17 continues to take shape, with five features planned for the upgrade to standard Java so far plus one feature removal and a feature deprecation. In the latest changes, as of May 12, the platform-agnostic vector API will move into a second incubator phase and sealed classes will be finalized.

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: 

  • 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 java.util.Random.