Oracle has released version 17 of the Java programming language and virtual machine. As the first long-term support (LTS) release since JDK 11 in 2018, the 14 JEPs in this final feature set are:
- 306: Restore Always-Strict Floating-Point Semantics
- 356: Enhanced Pseudo-Random Number Generators
- 382: New macOS Rendering Pipeline
- 391: macOS/AArch64 Port
- 398: Deprecate the Applet API for Removal
- 403: Strongly Encapsulate JDK Internals
- 406: Pattern Matching for switch (Preview)
- 407: Remove RMI Activation
- 409: Sealed Classes
- 410: Remove the Experimental AOT and JIT Compiler
- 411: Deprecate the Security Manager for Removal
- 412: Foreign Function & Memory API (Incubator)
- 414: Vector API (Second Incubator)
- 415: Context-Specific Deserialization Filters
The feature cadence for Java 17 remains similar to previous releases with 17 features in Java 16, 14 features in Java 15 and 16 features in Java 14.
Two of the JEPs within the Java 17 feature set, JEP 403 and JEP 411, generated some concern within the Java community. We examine them here.
JEP 403: Strongly Encapsulate JDK Internals
As one of the primary goals of Project Jigsaw, JEP 403 proposes to strongly encapsulate all internal elements of the JDK, except for critical internal APIs, such as sun.misc.Unsafe, to improve the security and maintainability of the JDK. As the successor to JEP 396, Strongly Encapsulate JDK Internals by Default, it will no longer be possible to bypass strong encapsulation via the command-line option, --illegal-access, in Java 17. For example, attempting use this option by assigning the value permit will yield the following warning:
$ java --illegal-access=permit {filename}.java
OpenJDK 64-Bit Server VM warning: Ignoring option --illegal-access=permit;
support was removed in 17.0
More details may be found in this InfoQ news story.
JEP 411: Deprecate the Security Manager for Removal
For many years, the Security Manager has not been the primary means of securing client-side Java code and has rarely been used to secure server-side code. The intent is to deprecate the Security Manager, introduced in Java 1.0, for removal in conjunction with JEP 398, Deprecate the Applet API for Removal. As described in the risks and assumptions section of JEP 411:
Jakarta EE has several requirements on the Security Manager. These must be either relaxed or removed in order for compliant applications to run on future Java releases after the Security Manager is degraded and then removed.
Concerned over future development of Jakarta EE, Arjan Tijms, self-employed software consultant, author, and committer to 23 EE4J projects, writes:
As was discussed before, the removal of the Security Manager in Java SE will impact Jakarta EE.
Currently Jakarta EE 10 will target Java SE 11, so will theoretically not be affected by this. However, implementations for Jakarta EE 9.1 (like GlassFish) already run on JDK 17 today and have to deal with aggressive warnings in the console about the security manager deprecation. It's therefore likely all Jakarta EE 10 implementations will come into contact with this sooner or later.
We don't exactly know when the security manager will actually be removed, but it's an impediment for EE implementations to run on whatever version that is, be it Java SE 18, Java SE 19, etc. This even concerns the API artefacts, as security manager calls take place in these. As it stands, these API artefacts would not be consumable on the Java SE version where the security manager is actually removed.
It's therefore probably good to prepare for this already in EE 10. A good first step would be perhaps to add a statement of intent that Jakarta EE indeed plans to follow Java SE and in the future remove usage of the security manager. At the moment this is not exactly clear, and I noticed some teams have been cautious with taking action pending any official statement regarding this matter.
Plans to evolve further deprecation of the Security Manager in Java 18, presumably in a successor JEP, include: preventing a Java application or library from dynamically installing a Security Manager unless the end user has explicitly opted to allow it; and degrade other Security Manager APIs so that they remain in place, but with limited or no functionality.
More details may be found in this InfoQ news story.
Is Java 17 a Glass Half Full?
Earlier this year, InfoQ examined this upcoming release as a "glass half full" and more modest than many developers had anticipated. This is partially due to records (JEP 395) and sealed types (JEP 409) having been fully delivered in Java 17, but pattern matching (JEP 406) is still in preview.
Java 18
Currently, only two JEPs are Targeted or Integrated for inclusion in Java 18:
- JEP 400: UTF-8 by Default
- JEP 413: Code Snippets in Java API Documentation
with one additional JEP as Proposed to Target:
- JEP 417: Vector API (Third Incubator)
JEP 400 specifies that UTF-8 is the default character set of the standard Java APIs to ensure consistency across all implementations, operating systems, locales, and configurations.
JEP 413 introduces the @snippet tag for Oracle's Standard Doclet, the well-known Java API documentation utility that produces the default HTML-formatted output. The intent is to simplify the inclusion of example source code in the API documentation.
The release date for Java 18 has not yet been announced, but it is expected to be delivered in mid-March 2022 as per the six-month release cadence. Developers can anticipate a feature freeze in mid-December 2021.
Java 17 can be downloaded from Oracle now with binaries from other vendors expected to become available in the coming days.
