This Specification defines the eighth version of the Java Platform, Standard Edition, which is currently scheduled for release in September 2013.
Contents | |
---|---|
1 | Summary |
2 | Structure and status |
3 | Definitions |
4 | Component JSR Specifications |
5 | Feature summary |
6 | Feature details |
7 | APIs proposed for removal |
8 | Profiles |
9 | Stripped Implementations |
The primary feature of this release is the addition of lambda expressions and virtual extension 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 either defined in new Component JSRs or revised in Maintenance Releases of existing such JSRs.
This document will also directly specify smaller features, enhancements, and bug fixes that are not part of any Component JSR Specification. At this Early Draft Review stage, however, this document simply describes the smaller features. At Public Review it will specify all features, enhancements, and bug fixes in the form of a detailed change summary and an annotated API specification showing the exact differences relative to Java SE 7.
The Public Review version of this Specification will also include draft updates to the Java Virtual Machine Specification and the Java Language Specification incorporating smaller features, enhancements, bug fixes, and clarifications. Changes made to these Specifications by Component JSR Specifications will be incorporated in time for the Proposed Final Draft.
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. The Final Release could also include additional features that are identified and approved by the Expert Group in response to feedback from the Java community.
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:
JSR 308: Annotations on Java Types JSR 310: Date and Time API JSR 335: Lambda Expressions
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 114: JDBC Rowsets JSR 160: JMX Remote API JSR 199: Java Compiler API JSR 173: Streaming API for XML 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.
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.tools
API to provide access to javadoc.ConcurrentHashMap
API, ForkJoinPool
improvements, and, possibly,
additional Lock
and Future
classes and better support for software
transactional memory (STM) frameworks.java.util.Arrays
that 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 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 four 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, and the smallest Profile must contain all of the classes and interfaces mandated by the Java Language Specification.
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 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:
compact1 | compact2 | compact3 |
---|---|---|
java.io | java.rmi | java.lang.instrument |
java.lang | java.rmi.activation | java.lang.management |
java.lang.annotation | java.rmi.dgc | java.security.acl |
java.lang.invoke | java.rmi.registry | java.util.prefs |
java.lang.ref | java.rmi.server | javax.annotation.processing |
java.lang.reflect | java.sql | javax.lang.model |
java.math | javax.rmi.ssl | javax.lang.model.element |
java.net | javax.sql | javax.lang.model.type |
java.nio | javax.transaction | javax.lang.model.util |
java.nio.channels | javax.transaction.xa | javax.management |
java.nio.channels.spi | javax.xml | javax.management.loading |
java.nio.charset | javax.xml.datatype | javax.management.modelmbean |
java.nio.charset.spi | javax.xml.namespace | javax.management.monitor |
java.nio.file | javax.xml.parsers | javax.management.openmbean |
java.nio.file.attribute | javax.xml.stream | javax.management.relation |
java.nio.file.spi | javax.xml.stream.events | javax.management.remote |
java.security | javax.xml.stream.util | javax.management.remote.rmi |
java.security.cert | javax.xml.transform | javax.management.timer |
java.security.interfaces | javax.xml.transform.dom | javax.naming |
java.security.spec | javax.xml.transform.sax | javax.naming.directory |
java.text | javax.xml.transform.stax | javax.naming.event |
java.text.spi | javax.xml.transform.stream | javax.naming.ldap |
java.util | javax.xml.validation | javax.naming.spi |
java.util.concurrent | javax.xml.xpath | javax.script |
java.util.concurrent.atomic | org.w3c.dom | javax.security.auth.kerberos |
java.util.concurrent.locks | org.w3c.dom.bootstrap | javax.security.sasl |
java.util.jar | org.w3c.dom.events | javax.sql.rowset |
java.util.logging | org.w3c.dom.ls | javax.sql.rowset.serial |
java.util.regex | org.xml.sax | javax.sql.rowset.spi |
java.util.spi | org.xml.sax.ext | javax.tools |
java.util.zip | org.xml.sax.helpers | javax.xml.crypto |
javax.crypto | javax.xml.crypto.dom | |
javax.crypto.interfaces | javax.xml.crypto.dsig | |
javax.crypto.spec | javax.xml.crypto.dsig.dom | |
javax.net | javax.xml.crypto.dsig.keyinfo | |
javax.net.ssl | javax.xml.crypto.dsig.spec | |
javax.security.auth | org.ietf.jgss | |
javax.security.auth.callback | ||
javax.security.auth.login | ||
javax.security.auth.spi | ||
javax.security.auth.x500 | ||
javax.security.cert |
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.
New packages defined in Component JSR Specifications will be added to the above lists in the Public Review version of this Specification. 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.
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 element of that Profile. If an Implementation implements the entire Platform then it must implement every element of the Platform. No other forms of Implementation are permitted.
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 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 only used a small part of the Platform. This limits the Platform’s utility in scenarios where space is at an extreme premium.
This Specification therefore permits an Implementation that is packaged with the sole application that will run upon it to omit, partially or entirely, elements that are never, under any circumstances, depended upon by the application. Such an Implementation is said to be stripped. An application packaged with a stripped Implementation must not load any Java code that is not part of itself, and its use of other reflective facilities must be severely constrained.