This Specification defines the eighth version of the Java Platform, Standard Edition, which is currently scheduled for release in March 2014.
|2||Structure and status|
|4||Component JSR Specifications|
|7||APIs proposed for removal|
The primary feature of this release is the addition of lambda expressions and default methods to the Java programming language, together with related API enhancements (JSR 335). This release also includes a new date and time API (JSR 310), the extension of the language to allow annotations on types (JSR 308), and a collection of smaller features.
The original request for this Specification proposed to include a module system, and to use that system to modularize the Platform itself. That feature was, however, deferred to a future release in order to allow sufficient time for the broad evaluation, review, and feedback which such a profound change to the Platform demands. To enable the clean modularization of the Platform in the future, this release takes the opportunity to deprecate a small number of methods whose signatures introduce problematic API dependences, so that they can be removed in that release.
As an interim step toward a fully-modular Platform, this release defines three compact Profiles so that applications that use just part of the Platform can run on resource-constrained devices.
Even the smallest Profile will be too large for some scenarios. When a Platform Implementation is packaged together with an application, this release allows elements of the Implementation to be removed when it is known that the application will never depend upon any removed element.
As an Umbrella Platform Specification, this document specifies significant features by reference to other Specifications which are either defined in new Component JSRs or revised in Maintenance Releases of existing such JSRs.
This Specification directly specifies smaller API features, enhancements, clarifications, and bug fixes that are not part of any Component JSR Specification. The specifications of those changes are contained in two accompanying documents: Annex 1 is a detailed change summary and Annex 2 is an annotated API specification showing the exact differences relative to Java SE 7. The Component JSR Specifications may include API specifications for some of the packages detailed in Annex 2; in case of discrepancy, the Component JSR Specifications take precedence.
This Specification also includes drafts of the Java SE 8 Editions of The Java Language Specification and The Java Virtual Machine Specification in Annex 3. These drafts include all changes from Component JSR Specifications (JSR 335 and JSR 308), as well as all small features, corrections, and clarifications that are not themselves the subject of a Component JSR Specification.
The Final Release of this Specification is expected to include all of the features listed here, but it is possible for a feature to be dropped. The Expert Group could, for example, determine that a feature is too costly to implement.
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 judgement 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.
The significant new features of this release are specified in separate new Component JSR Specifications, which are incorporated here by reference:
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:
JSR 003: Java Management Extensions JSR 114: JDBC Rowsets JSR 160: JMX Remote API JSR 173: Streaming API for XML JSR 199: Java Compiler API JSR 206: Java API for XML Processing JSR 221: JDBC 4.0 JSR 269: Pluggable Annotation-Processing API
Each Component JSR Specification, or revision thereto, is related to one or more features in the detailed list below.
|Language||Access to Parameter Names at Runtime (JSR 269 MR, 337)|
|Add Javadoc to javax.tools (JSR 199 MR)|
|Annotations on Java Types (JSR 308)|
|Generalized Target-Type Inference (JSR 335)|
|Lambda Expressions & Virtual Extension Methods (JSR 269 MR, 335)|
|Repeating Annotations (JSR 269 MR, 337)|
|Core Libraries||Base64 Encoding & Decoding|
|Bulk Data Operations for Collections (JSR 335)|
|Date & Time API (JSR 310)|
|Enhance Core Libraries with Lambda (JSR 335)|
|JDBC 4.2 (JSR 114 MR, 221 MR)|
|Parallel Array Sorting|
|Statically-Linked JNI Libraries|
|I18n||BCP 47 Locale Matching|
|Networking||HTTP URL Permissions|
|Security||Configurable Secure Random-Number Generation|
|Enhance the Certificate Revocation-Checking API|
|NSA Suite B Cryptographic Algorithms|
|TLS Server Name Indication (SNI) Extension|
|XML||Restrict Fetching of External XML Resources (JSR 206 MR)|
|Platform||Compact Profiles (JSR 3 MR, 160 MR, 337)|
|Prepare for Modularization (JSR 173 MR, 206 MR, 337)|
If a feature description does not refer to a Component JSR Specification then the feature is specified directly in this Umbrella Platform Specification. If a feature is specified partly in a Component JSR Specification and partly in this Specification then a reference to this Specification, JSR 337, is included for clarity.
Work on features in the prototype Java SE 8 Reference Implementation, which is the Java Development Kit, version 8 (JDK 8), 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.
javax.toolsAPI to provide access to javadoc.
ForkJoinPoolimprovements, and additional
java.util.Arraysthat use the JSR 166 Fork/Join parallelism common pool to provide sorting of arrays in parallel.
Exploratory work toward the modular Java SE Platform in Project Jigsaw has identified a small number of problematic API dependences that will be a significant impediment to the clean modularization of the Platform in a future release.
The methods at which these dependences originate are:
The difficulty with these methods is that they require the modules that contain the java.util.logging and java.util.jar packages to depend upon the module that contains the java.beans package, which in turn depends upon the (very large) module that contains the java.awt package. Thus any application that uses the core logging or JAR-file APIs could only run on a configuration of the Platform that includes the AWT APIs, which is clearly undesirable.
An automated analysis of a large corpus of Java library and application code, including the entire content of Maven Central as of September 2012, suggests that these methods are hardly ever used. Following the process for removing APIs established in Java SE 6, the above methods will be deprecated in Java SE 8 and proposed for removal from the Platform in a future release.
This Specification introduces the concept of a Java SE Profile, which is a well-defined subset of the Java SE Platform. Profiles allow applications that use just part of the Platform to run on resource-constrained devices. An application that, e.g., does not use the Swing/AWT/2D graphics stack can achieve considerable space savings by running on a Profile that does not include an implementation of those APIs.
This feature is intended to enable the migration of applications currently built on the Java ME Connected Device Configuration (CDC) to appropriate Profiles of the Java SE Platform. It can thus be seen as part of the long-term effort to converge CDC with the Java SE Platform, and is included in this Specification in light of the deferral of a full module system to a future release.
A Java SE Profile is not a Profile Specification as defined in the Java Community Process. This Specification does not define rules by which separate JSR Specifications can define Profile Specifications based upon this Specification.
Constraints A Profile is subject to five constraints:
A Profile must implement the entire Java Virtual Machine Specification that is part of this Specification. The Virtual Machine itself is not subject to subsetting.
A Profile must implement the entire Java Language Specification that is part of this Specification. The language itself is not subject to subsetting.
A Profile must be specified as a list of packages. The content of a package in a Profile must be identical to the content of the package of the same name in the complete Java SE Platform, unless explicitly specified otherwise.
A Profile may be specified as being larger than some other Profile, in which case the larger Profile must contain all of the packages specified in the smaller Profile.
The smallest Profile must be specified to contain all of the packages containing the classes and interfaces mentioned in normative text in the Java Language Specification.
The complete Java SE Platform is not itself considered a Profile.
Content This Specification defines three Profiles: compact1, compact2, and compact3. compact3 is larger than compact2, and compact2 is larger than compact1. The packages added in each Profile are as follows:
The content of each package in these Profiles is identical to the content of the package of the same name in the complete Java SE Platform, except that the problematic APIs proposed for removal in a future release are not present in any of the Profiles, for the same reasons.
The above lists include new packages defined in the Component JSR Specifications. The Profile membership of each class, interface, and package will also be specified in the complete Javadoc API specification.
It is expected that the modular Platform to be defined in a future release will include modules corresponding almost exactly to the Profiles defined here, so that applications that use Profiles can easily be migrated to use modules. It is further expected that these Profiles will be deprecated at that time, so that they can be removed in an even later release.
Rationale The content of each Profile is motivated as follows:
The compact1 Profile contains the smallest set of packages that is feasible without omitting any classes or methods. The logging (java.util.logging), SSL/TLS (javax.net.ssl), and scripting (javax.script) packages are additionally included because it is expected that many applications running on even the smallest Profile will require these facilities.
The compact1 Profile is a suitable migration target for applications that currently target CDC 1.1 (JSR 218) and Foundation Profile 1.1 (JSR 219). It includes every package specified in those JSRs, including the “Security Optional Packages” in JSR 219, except for java.security.acl (a legacy API which nobody uses) and the javax.microedition.io and javax.microedition.pki packages (which are Java ME-specific).
The compact2 Profile adds packages for remote method invocation (RMI), database access (JDBC), and XML processing. This Profile is a suitable migration target for applications that currently target CDC 1.1 and Foundation Profile 1.1 and, additionally, one or more of the following Specifications:
The compact3 Profile adds packages for instrumentation, management, naming, scripting, and compilation as well as further packages for database access, security, and cryptography. This Profile is intended for applications that require most of the full Platform except for the desktop user-interface packages (AWT, Swing, etc.), web services (JAX-WS, JAXB, and SAAJ), and CORBA.
Conformance Implementors of this Specification are free to implement zero, one, or more Profiles. They are also free to implement one or more Profiles without implementing the entire Platform. The Technology Compatibility Kit (TCK) for this Specification will be structured so as to allow the conformance of an Implementation of any Profile, or of the entire Platform, to be tested. A Reference Implementation (RI) will be provided for each Profile, and for the entire Platform.
If an Implementation of this Specification implements a Profile then it must be complete, i.e., it must implement every API element of that Profile. If an Implementation implements the entire Platform then it must implement every API element of the Platform. No other forms of Implementation are permitted, except as defined in the next section.
Past releases of the Java SE Platform required Implementations to be complete in all circumstances. That is, removing elements of an Implementation after the Implementation is validated against the TCK was not permitted. This constraint has been a key to the long-term success of the Platform because it has helped to ensure the portability of Java library and application code to different Implementations.
As a consequence of this constraint, an application that was packaged together with an Implementation was required to include the entire Implementation even if it used only a small part of the Platform. This limited the Platform’s utility in scenarios where space is at an extreme premium.
This Specification therefore permits an Implementation that is packaged together with all of the Java library and application code that will ever run upon it to omit, partially or entirely, elements that are never, under any circumstances, depended upon by that code. The process that creates such an Implementation is called stripping, and the resulting Implementation is said to be Stripped.
The elements subject to removal by the stripping process may be Java code, in the form of packages, classes, interfaces, fields, or methods. They may also be other kinds of implementation elements, in the form of static data files or native-code procedures, objects, or libraries.
Constraints A Stripped Implementation must satisfy the following constraints:
The Implementation provided as input to the stripping process must conform to the Specification. It may implement additional JSR Specifications, in which case stripping may also apply to those components unless explicitly prohibited by their respective Specifications. The input Implementation need not include elements defined as optional by the relevant Specifications.
A Stripped Implementation, once created, cannot be changed. No further elements may be added or removed.
The Java library and application code provided as input to the stripping process may be transformed by that process, but after the process is complete the code cannot be changed. No further code in any form may be added or removed.
A Stripped Implementation is forever bound to the Java library and application code provided as input to the same invocation of the stripping process. A Stripped Implementation may not be used to execute any other library or application code. Elements of a Stripped Implementation may not in any way be referenced by any other library or application code.
The stripping process must preserve the functionality and behavior of the input Implementation and of the input Java library and application code. An element, whether optional or not, that is present in the input Implementation and is used by the input library or application code must also be present in the Stripped Implementation. The library and application code packaged together with a Stripped Implementation must behave identically to the input library and application code running on the input Implementation.
Implementation This Specification neither mandates nor forbids any particular means of creating Stripped Implementations, so long as the above constraints are satisfied. At a high level, a Stripped Implementation can be created in two steps:
Analyze the combined Implementation, library, and application code to identify elements that are never used, either directly or indirectly.
Remove the unused elements from the combined code and package all of the remaining code into a single binary image.
A precise answer for the first step cannot, in general, be computed automatically since it is equivalent to solving the Halting Problem. Practical tools for creating Stripped Implementations therefore usually rely upon a combination of heuristics, manual analysis, and automatic analysis to compute an approximate answer. It is highly recommended that the binary image created in the second step be fully tested, with the goal of achieving 100% coverage of the remaining library and application code, in order to ensure that all required elements of the Implementation are present.