This Specification defines version 11 of the Java Platform, Standard Edition.
|4||Component JSR Specifications|
|9||APIs proposed for removal|
|A1||Complete API Specification|
|A2||API Specification differences|
|A3||Java Language & Virtual Machine Specifications|
This release continues the evolution of the Platform to ensure the broadest possible success of the core Java technology. It substantially streamlines the footprint of the Platform by removing enterprise APIs, and improves the expressiveness of Java class files.
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 11 API Specification and Annex 2 is an annotated API specification showing the exact differences relative to Java SE 10. 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 11 Editions of The Java Language Specification and The Java Virtual Machine Specification in Annex 3. The Java SE 11 Editions contain all corrections and clarifications made since the Java SE 10 Editions, as well as additions for new features.
The Final Release of this Specification is expected to include all of the currently described features and updates; however, further changes may be forthcoming. For example, the Expert Group could determine that a feature is not yet be ready for standardization.
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. The following existing component JSRs may have Maintenance Releases. These will be incorporated by reference before the Final Release of this Specification as necessary:
JSR 199: Java Compiler API JSR 114: JDBC Rowset Implementations JSR 221: JDBC API JSR 269: Pluggable Annotation-Processing API
The javax.transaction.xa package of the following existing component JSR is subsumed by this Specification:
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 11 Reference Implementation, which is the Java Development Kit, version 11 (JDK 11), is organized in terms of JDK Enhancement Proposals (JEPs). Each feature description includes a link to the corresponding JEP document as a convenience, but that document is not a normative part of this Specification.
Extend the Java class-file format to support a new constant-pool form,
CONSTANT_Dynamic. Loading a
CONSTANT_Dynamic will delegate creation
to a bootstrap method, just as linking an
invokedynamic call site
delegates linkage to a bootstrap method.
var to be used when declaring the formal parameters of implicitly typed lambda expressions.
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 aggregator module, which gathers together all of the modules that comprise the Java SE Platform. 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 considered part of the Java SE Platform Specification if, and only if, it is a standard module reachable from the java.se module.
Following the conventions established by the Enhanced Deprecation feature,
various APIs were annotated with
forRemoval=true in the “APIs
Proposed for Removal” section of the Java SE 9
Platform Specification and the Java SE 10
The following individual APIs are removed from this Specification. They have all been deprecated since at least Java SE 1.4 and have been superseded by newer APIs.
Seven modules that were proposed for removal by the Java SE 9 and 10 Platform Specifications are removed from this Specification. More information about these modules and their APIs is available in JEP 320. Standalone versions of the APIs and their implementations are readily available.
The following APIs were proposed for removal by the Java SE 9 or 10 Platform Specifications, and continue to be eligible for removal in a future release. They are not removed from this Specification.