E-Mail Address: iris.clark@oracle.com, mark.reinhold@oracle.com

Telephone Number: +1 408 276 3909, +1 408 276 7256

Fax Number: -

2.19 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.

EG communications archive: http://mail.openjdk.java.net/pipermail/java-se-8-spec-experts/

Comments on specific elements of draft specifications are best communicated via the issue tracker. Other feedback may be sent to the comments address, java-se-8-spec-comments@openjdk.java.net, the archives of which are public.

2.20 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?

http://java.net/jira/browse/JAVA_SE_8

2.21 Please provide the location of the publicly accessible document archive you have created for the Expert Group.

http://openjdk.java.net/projects/jdk8/spec/

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Oracle

Name of Contact Person: Mark Reinhold

E-Mail Address: mark.reinhold@oracle.com

Telephone Number: +1 408 276 7256

Fax Number: -

Specification Lead: Mark Reinhold

E-Mail Address: mark.reinhold@oracle.com

Telephone Number: +1 408 276 7256

Fax Number: -

Initial Expert Group Membership:

Oracle
Ericsson
IBM
Red Hat
SAP

Supporting this JSR:

Eclipse Foundation
Ericsson
IBM
Red Hat
SAP

Section 2: Request

2.1 Please describe the proposed Specification:

The Java Platform, Standard Edition ("Java SE") is the core Java platform for general-purpose computing. In this release of the platform, Java SE 8, we intend to address a number of areas based upon trends in the programming community, trends in hardware architectures, and above all our continued commitment to ensuring the broadest possible success of core Java technology for years to come.

The Java SE 8 Platform Specification will build upon the Java Language Specification, the Java Virtual Machine Specification, and the Java SE APIs defined in Java SE 7. The Platform Specification does not itself define new features, or enhancements to existing specifications; rather, it enumerates features and enhancements defined in component JSRs or through the JCP maintenance process.

The Java SE 8 Platform Specification will aim to support the creation of maintainable, scalable, and high-performance Java applications across a range of computing environments. We propose three main themes: Productivity, Performance, and Modularity.

Productivity

Java SE 8 will further reduce boilerplate code by adding productivity features to the Java language and the Java SE APIs. These features will increase the abstraction level of most applications in a pragmatic way, with no significant impact on existing code and a minimal learning curve for all developers. We propose to make it easier for developers to work with the existing, widely-used Collections Framework, for example, by extending the language with literal expressions for immutable lists, sets, and maps.

Annotations, introduced in Java SE 5, enable the documentation of program behavior and, in many cases, the static verification of that behavior. To enhance support for the verification of large programs and libraries we propose to include JSR 308, which allows annotations to be written in contexts where they are currently illegal.

Performance

The Fork/Join Framework introduced in Java SE 7 was a first step toward providing higher-level programming abstractions suitable for multicore CPUs. In this release we will take another big step by enhancing the Collections Framework and related APIs to support automatically-parallelizable bulk-data operations such as filter, map, and reduce. Convenient use of these new APIs will be enabled by extending the Java language to include lambda expressions (a.k.a. "closures") and default methods. These language changes will, as an additional benefit, improve the productivity of developers using existing single-abstract-method APIs across the platform.

Modularity

Developers of Java SE applications have long suffered with the brittle, error-prone class-path mechanism for organizing program components. A class path is really just a sequence of JAR files or directories which is searched linearly whenever a class file or resource is needed. As such it supports neither the encapsulation nor the versioning of components; both of these facilities are essential to the construction and maintenance of large programs.

In Java SE 8 we propose to enable developers finally to escape from the class path's "JAR hell" by integrating a module system directly into the platform. We further propose to apply that module system to the platform itself so as to support customizable configurations which scale from large servers down to small embedded devices. We envision this Expert Group defining:

• Rules for creating Profiles of the Java SE Platform, which may contain subsets of Java SE, additional JCP technologies not part of the Java SE Platform, or both;

• A Java SE Base Profile, which contains the foundational APIs upon which the rest of the platform and applications depend;

• A Java SE Base Module, which implements the Base Profile; and

• A set of component modules for separable technologies such as the AWT and Swing GUI APIs, CORBA, naming, monitoring and management APIs, web services, and the various XML technologies.

Products implementing the Java SE 8 Platform Specification would be required to include the Base module together with all component modules. Products implementing the Java SE 8 Base Profile would only be required to include the Base module; they may include some component modules, however, as well as facilities for downloading and installing component modules on demand.

In either case, by expressing dependences upon standard modules an application developer would be assured of a flexible yet consistent "write once, run anywhere" experience.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

This JSR defines a release of the Java SE platform targeted at embedded, desktop, server, and cloud environments.

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

This JSR does not target a platform edition; it defines a platform edition, namely version 8 of the Java platform, Standard Edition. Members of the Java ME and Java EE communities have already been involved in preliminary planning activities for this release. We look forward to their continued involvement as work progresses.

2.4 Should this JSR be voted on by both Executive Committees?

No; SE/EE EC only.

2.5 What need of the Java community will be addressed by the proposed specification?

Continually improving the productivity of Java developers is critical to keeping the Java SE Platform at the forefront of software development.

Exploiting the opportunities of multi-core CPUs in a way that is safe and practical for programmers is essential for all Java applications.

Modularity is a fundamental building block for developing, deploying, managing, and evolving all Java applications. Existing frameworks and tools support these tasks today, but standardization in the Java SE Platform would promote interoperability and benefit developers, users, and vendors.

2.6 Why isn't this need met by existing specifications?

While existing (in progress) JSRs and open-source projects have investigated the evolution of the Java language, the JVM, and the Java SE APIs, only a platform JSR can unite the results of these investigations into a new edition of the Java SE platform.

2.7 Please give a short description of the underlying technology or technologies:

The technologies that make up Java SE 8 will be described by the component JSRs enumerated in the Java SE 8 Platform Specification. We propose a candidate list of component JSRs in section 3.1.

2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

The Java SE platform itself does not have a single package name. All of its requirements are reflected in the packages of its constituent Java SE APIs.

2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No.

2.10 Are there any security issues that cannot be addressed by the current security model?

None are known at this time.

2.11 Are there any internationalization or localization issues?

None are known at this time.

2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

JSR 901 (Java Language Specification), JSR 924 (JVM Specification), and the specifications for certain java.*/javax.* packages will need to be revised as a result of this JSR.

2.13 Please describe the anticipated schedule for the development of this specification.

Expert Group formation: July 2012
Early Draft Review: September 2012
Public Review: January 2013
Proposed Final Draft: June 2013
Final Release: August 2013

2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.

The Expert Group will communicate primarily via e-mail.

2.15 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate:

• The public can read the names of the people on the Expert Group.

We intend this to be the case.

• The Expert Group business is regularly reported on a publicly readable alias.

We intend this to be the case.

• The schedule for the JSR is publicly available, it's current, and I update it regularly.

We intend this to be the case.

• The public can read/write to a wiki for my JSR.

Rather than a wiki which the Expert Group must take time out to visit, we intend to implement a pair of mailing lists following the approach of JSR 294 and JSR 330. First, Expert Group business will be carried out on a mailing list dedicated to Expert Group members. Second, an "observer" mailing list which anyone may join will receive the traffic of the Expert Group list. The observer list allows the public to follow Expert Group business, and is writable to allow the public to make comments for other observers to see and make further comment on. Expert Group members are under no obligation to join the observer list and partake in public discussion. In addition to these lists we will maintain a private Expert-Group-only list for administrative and other non-technical traffic.

• I read and respond to posts on the discussion board for my JSR on jcp.org.

In lieu of tracking the jcp.org discussion board, and in light of the considerable public attention that the observer list is likely to receive, the Java SE 8 Platform Specification Lead (or his designates) will read the observer list and respond directly as appropriate.

• There is an issue-tracker for my JSR that the public can read.

Since the majority of Java SE 8 is developed in component JSRs, it is intended that the public track those JSRs according to whatever mechanisms are offered by the JSRs' specification leads.

• I have spoken at conferences and events about my JSR recently.

Yes. The Java SE team at Oracle, as well as external contributors, have spoken and written about planned enhancements for some time.

• I am using open-source processes for the development of the RI and/or TCK.

The source code for most of the Reference Implementation will be developed in the OpenJDK Community, just as for Java SE 7, with weekly and milestone binary builds made available for anyone to test and review.

• The Update tab for my JSR has links to and information about all public communication mechanisms and sites for the development of my JSR.

We intend this to be the case.

2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

The RI will be the Java Development Kit (JDK), version 8. The TCK will be the Java Compatibility Kit (JCK), version 8.

2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

N/A

2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

The licenses for Java SE 8 will be the same as for Java SE 7.

Note that the following was added when the JSR moved to JCP 2.8:

2.19 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.

EG communications archive: http://mail.openjdk.java.net/pipermail/java-se-8-spec-experts/

Comments on specific elements of draft specifications are best communicated via the issue tracker. Other feedback may be sent to the comments address, java-se-8-spec-comments@openjdk.java.net, the archives of which are public.

2.20 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?

http://java.net/jira/browse/JAVA_SE_8

2.21 Please provide the location of the publicly accessible document archive you have created for the Expert Group.

http://openjdk.java.net/projects/jdk8/spec/

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

The following JSRs will be proposed for inclusion as components of the Java SE 8 Umbrella JSR. The final Java SE 8 Platform Specification might not include all of these JSRs, and it might include some JSRs not listed here.

• JSR 308: Annotations on Java Types
• JSR 310: Date and Time API
• JSR TBD: More Small Enhancements to the Java Programming Language (OpenJDK Project Coin)
• JSR 335: Lambda Expressions for the Java Programming Language (OpenJDK Project Lambda)
• JSR TBD: Java Platform Module System

In the case of the proposed Java Platform Module System JSR, it is understood that there is already a significant investment within the Java community in applications and frameworks built using the module layer of the OSGi Service Platform. The extent to which the Java Platform Module System should adopt, interoperate with, or otherwise accommodate OSGi will be a topic for that JSR's Expert Group and the Java SE 8 Expert Group to discuss and decide.

The following core JCP specifications will be enhanced under the auspices of the Java SE 8 Umbrella JSR:

• JSR 901: Java Language Specification — Maintenance Review to incorporate changes from the above JSRs
• JSR 924: JVM Specification — Maintenance Review to incorporate changes from the above JSRs
• Java SE APIs — Maintenance Review to incorporate changes made by routine maintenance and small-scale enhancement

Changes defined in Maintenance Reviews of various bundled stand-alone JSRs will also be included:

• JSR 199: Java Compiler API
• JSR 206: Java API for XML Processing (JAXP)
• JSR 222: Java Architecture for XML Binding (JAXB)
• JSR 224: Java API for XML-Based Web Services (JAX-WS)
• JSR 269: Pluggable Annotation-Processing API

3.2 Explanation of how these items might be used as a starting point for the work.

See section 2.1.