JDK 17 is Officially Released

Even though we are a few months ahead of schedule, Java 17 is now taking shape and worth talking about. There are four really good features planned for the upgrade to Java.

Even though we are a few months ahead of schedule, Java 17 is now taking shape and worth talking about. There are four really good features planned for the upgrade to Java. As of the latest change just this week, the currently experimental Java Ahead-of-Time (AOT) and Just-in-Time (JIT) will be removed.

The Java Development Kit (JDK) 17 is going to be a Long Term Support (LTS) release with extended support from Oracle for a good few years.

Some of the most important changes are listed below.

  • 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.

In the next few months, it’s likely more features will be proposed for JDK 17. Some of the possibilities include a foreign linker API, a vector API, and a foreign-memory access API – all of which are currently in an experimental to the beta stage in the JDK 16 release published March 16. Sealed classes, in a second preview in JDK 16, could become generally available in JDK 17.

September 14 has been chosen for the general availability date for JDK 17. The production release will be preceded by ramp-down phases in June and July and release candidates in August. Early-access builds of JDK 17 can be found at jdk.java.net.