This Specification defines version 17 of the Java Platform, Standard Edition (“Java SE 17”). The Reference Implementation of this Specification is the Java Development Kit, version 17 (“JDK 17”).
|4||Component JSR Specifications|
|8||APIs proposed for removal|
|A1||Complete API Specification|
|A2||API Specification differences|
|A3||Java Language & Virtual Machine Specifications|
|A4||JAR File Specification|
|A5||Java AWT Native Interface (JAWT) Specification & Guide|
|A6||Java Debug Wire Protocol (JDWP)|
|A7||Java Native Interface (JNI) Specification|
|A8||Java Object Serialization Specification|
|A9||Java Remote Method Invocation (RMI) Specification|
|A10||Java Security Standard Algorithm Names|
|A11||JVM Tool Interface (JVM TI)|
This release continues the evolution of the Platform to ensure the
broadest possible success of the core Java technology. It standardizes
sealed classes, restores always-strict floating-point semantics, and
previews pattern matching for
switch statements. It enhances
pseudorandom number generators and adds support for context-specific and
dynamically-selected deserialization filters. In addition, and in
contrast to earlier releases, it always requires strong encapsulation of
an Implementation’s modules with no option to disable. Finally, it
removes the RMI Activation mechanism and deprecates the Security Manager
and the Applet API for removal in a future release.
This document directly specifies API features, enhancements, clarifications, and bug fixes. It also specifies features by reference to other Specifications which are revised in Maintenance Releases of existing JSRs. The specifications of these changes are contained in two accompanying documents: Annex 1 is the complete Java SE 17 API Specification and Annex 2 is an annotated API specification showing the exact differences relative to Java SE 16. Informative background for these changes may be found in the list of approved Change Specification Requests for this release.
This Specification includes the Java SE 17 Editions of The Java Language Specification and The Java Virtual Machine Specification in Annex 3. The Java SE 17 Editions contain all corrections and clarifications made since the Java SE 16 Editions, as well as additions for new features. Annex 3 also presents changes to The Java Language Specification and The Java Virtual Machine Specification in connection with preview features in Java SE 17.
This Specification includes the Java SE 17 versions of additional narrative specifications in Annexes 4 — 11. The Java SE 17 versions contain all corrections and clarifications made since the Java SE 16 versions, as well as additions for new features. The Java Remote Method Invocation (RMI) Specification in Annex 9 contains the most significant changes which were made in connection with the removal of the deprecated RMI Activation mechanism.
Changes to the Java SE Platform Specification are categorized as either features or enhancements. A feature is, roughly speaking, a change of which at least one of the following statements is true:
Any addition that is not a feature is considered an enhancement.
There is, obviously, room for judgment when interpreting this definition. In order to maximize the visibility of Platform revisions we generally tend to consider borderline items to be features rather than enhancements.
Some Component JSR Specifications previously incorporated into the Platform are still available separately or have significant Specifications themselves. Changes to their Specifications are therefore made in separate Maintenance Releases, which are incorporated here by reference:
Each Component JSR Specification, or revision thereto, may be related to one or more features in the detailed list below.
Work on features in the Java SE 17 Reference Implementation is organized in terms of JDK Enhancement Proposals (JEPs). Each feature description gives a link to the corresponding JEP document as a convenience, but that document is not a normative part of this Specification. Some features are included in the Java SE 17 Reference Implementation on a preview basis, to gain exposure before achieving permanent status in a later release of the Java SE Platform.
Allow applications to configure context-specific and dynamically-selected deserialization filters via a JVM-wide filter factory that is invoked to select a filter for each individual deserialization operation.
Deprecate the Applet API for removal. It is essentially irrelevant since all web-browser vendors have either removed support for Java browser plug-ins or announced plans to do so.
Provide new interface types and implementations for pseudorandom number generators (PRNGs), including jumpable PRNGs and an additional class of splittable PRNG algorithms (LXM).
Remove the Remote Method Invocation (RMI) Activation mechanism, while preserving the rest of RMI.
Strongly encapsulate all internal elements of the JDK, except for
critical internal APIs such as
sun.misc.Unsafe. It will no
longer be possible to relax the strong encapsulation of internal elements
via a single command-line option, as was possible in JDK 9 through
Deprecate the Security Manager for removal in a future release. The Security Manager dates from Java 1.0. It has not been the primary means of securing client-side Java code for many years, and it has rarely been used to secure server-side code. To move Java forward, we intend to deprecate the Security Manager for removal in concert with the legacy Applet API (JEP 398).
Enhance the Java programming language with pattern matching for
expressions and statements, along with extensions to the language of patterns.
Extending pattern matching to
switch allows an expression to be tested against
a number of patterns, each with a specific action, so that complex data-oriented
queries can be expressed concisely and safely.
Make floating-point operations consistently strict, rather than have both strict floating-point semantics (
strictfp) and subtly different default floating-point semantics. This will restore the original floating-point semantics to the language and VM, matching the semantics before the introduction of strict and default floating-point modes in Java SE 1.2.
Preview features A preview language or VM feature is a new feature of the Java SE Platform that is fully specified, fully implemented, and yet impermanent. This Specification incorporates the Java SE 12 Platform Specification (JSR 386), subsection Preview features by reference.
A module is a named set of packages designed for reuse. A specification governed by the JCP defines standard packages, and may group them into one or more standard modules.
This Specification groups the standard packages of the Java SE Platform into 21 standard modules, which we refer to as the Java SE modules. The name of a Java SE module always starts with the string "java.". The complete list of such modules is:
Compared to Java SE 16, this Specification does not add or remove any modules.
The module graph The Java SE modules depend upon each other as stated in their specifications, which are part of the overall API Specification. The corresponding complete Java SE module graph has too many edges to be displayed easily in visual form; here is the transitive reduction of the directed acyclic graph, in which redundant edges are omitted (click to enlarge):
Here is how to read this visualization of the module graph:
If one module depends upon another, and it grants implied readability to that module via a requires transitive directive, then there is an edge from the first module to the second.
At the very bottom is the java.base module, which contains essential classes such as java.lang.Object and java.lang.String. The base module depends upon no module, and every other module depends upon the base module.
At the top is the java.se module, which gathers together all of the modules that comprise the Java SE Platform. This is an example of an aggregator module, which logically gathers the content of other modules by granting implied readability to them, but adds no content of its own. A run-time system configured to contain the java.se module will contain all of the packages of the Java SE Platform.
A module is a Java SE module — that is, considered part of the Java SE Platform Specification — if and only if it is a standard module reachable from the java.se module.
Relaxing strong encapsulation As an aid to migration, previous versions of this Specification permitted an Implementation to provide a means to invoke its run-time system with one or more packages of one or more of its modules open to code in all unnamed modules, i.e., to code on the class path. This is no longer permitted.
(The Reference Implementation provided this capability via the
An Implementation must not relax the strong encapsulation of any of its modules, either by default or upon request. That is, its run-time system must not behave as if some packages in the Implementation’s modules are open when they are not open according to their module declarations. A package, or an entire module, is open to code in all unnamed modules if and only if:
This section may be compared to the corresponding section that appeared in Java SE 16.
The following APIs were removed from the Java SE Platform by this Platform Specification. The number in parentheses indicates the Java SE Platform Specification which first proposed its removal.
The following APIs were proposed for removal from the Java SE Platform by the Platform Specifications for Java SE 9, Java SE 10, Java SE 13, Java SE 14, and Java SE 16. They are not removed in this release of the Java SE Platform. They continue to be eligible for removal in a future release.
The following APIs are proposed for removal from the Java SE Platform
by this Platform Specification. They are annotated as
forRemoval=true, following the
convention established by
This makes them eligible for removal in a future release.