Find JSRs
Submit this Search


Ad Banner
 
 
 
 
JSRs: Java Specification Requests
JSR 294: Improved Modularity Support in the JavaTM Programming Language

This JSR has been Withdrawn
Reason: Withdrawn at the request of the Specification Lead. Superseded by JSR 376.

This JSR has been withdrawn.

Updates to the Java Specification Request (JSR)

2010.02.15:
Oracle America, Inc. assumed the Maintenance Lead role from Sun Microsystems.

Resources

Background

JSR 294 initially focused on a concept called superpackages, described in April 2006 and again in November 2006. Later, JSR 294 focused on a more lightweight concept called modules, described to the Expert Group in March 2008. This received a positive reaction from the Expert Group and others. In January 2009, the Expert Group started discussion in earnest based on the problem domain and high-level requirements.

Update to section 2.13 (2009.02.25)

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

The intention is to deliver this JSR as a component of Java SE 7. Early Draft Review of this JSR is planned to occur in the first half of 2009, Public Review in the second half of 2009, and Proposed Final Draft in the first half of 2010.

Update to section 1 (2006.11.04)

Specification Lead: Alex Buckley

E-Mail Address: alex.buckley@sun.com

Telephone Number: +1 408 276 3065

Fax Number: -

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Sun Microsystems

Name of Contact Person: Graham Hamilton

E-Mail Address: graham.hamilton@sun.com

Telephone Number: +1 408 276 7102

Fax Number: +1 408 276 7700


Specification Lead: Gilad Bracha

E-Mail Address: gilad.bracha@sun.com

Telephone Number: +1 408 276 7025

Fax Number: +1 408 276 7700


Initial Expert Group Membership:

Sun Microsystems
Google
Doug Lea
IBM

Supporting this JSR:

Google
Sun Microsystems
Doug Lea
IBM



Section 2: Request

2.1 Please describe the proposed Specification:

We plan to extend the Java programming language with new constructs (tentatively called "superpackages") that allow hierarchical modular organization. We expect these constructs to be supported at the virtual machine level, through modifications or extensions to the JVMs access control rules.

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

Java SE and EE

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 is a JLS and JVM specification change. As such, care will be taken to ensure that the changes can be implemented in a wide variety of environments.

Should this JSR be voted on by both Executive Committees?

No

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

Today, an implementation can be partitioned into multiple packages. Subparts of such an implementation need to be more tightly coupled to each other than to the surrounding software environment. Today designers are forced to declare elements of the program that are needed by other subparts of the implementation as public - thereby making them globally accessible, which is clearly suboptimal.

Alternately, the entire implementation can be placed in a single package. This resolves the issue above, but is unwieldy, and exposes all internals of all subparts to each other.

The language changes envisioned will resolve these issues. In particular, we expect to introduce a new notion of modules (superpackages) at the language level where existing public access control would apply only within a language level module and access to API's from outside a module would be restricted to API's the module explicitly exports.

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

The current language and VM accessibility rules result in the suboptimal situation described above, and need to be modified.

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

Existing compilers map Java programming language source into binaries in the Java virtual machine class file format. We anticipate that the new constructs will be implemented in a similar way. We expect that some modifications to the class file format will be needed, as well as extensions to the behavior of Java virtual machines, especially with respect to access control.

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

N/A

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?

No. All security concerns will be addressed by suitable instruction semantics and byte code verification rules.

2.11 Are there any internationalization or localization issues?

No

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

This work will be a modification of the Java language and JVM specifications. In addition, this JSR will work closely with JSR277 to ensure that the two specifications fit well together.

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

The intention is to deliver this JSR as a component of Java SE 7 (code name "Dolphin"). Early Draft Review would occur in the second half of 2006, Public Review in the first half of 2007, and Proposed Final Draft in the second half of 2007.

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

It is anticipated that most work will be done by e-mail, with conference calls if needed.

2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.

It is expected that early access drafts will be made publicly available as the work progresses. As with Mustang (see mustang.dev.java.net) there will be weekly snapshot releases of Dolphin, allowing the community early access to both the source and binary of the RI as it is being developed.

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.

This JSR and its RI and TCK are intended to be part of the Java SE 7 RI and TCK, respectively.

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 RI and TCK will be delivered and licensed as part of the RI and TCK for Java SE 7.





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 blog entry gives a draft of an initial strawman proposal for this JSR.

http://blogs.sun.com/roller/page/gbracha?entry=developing_modules_for_development/

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

The ideas described in the blog outline language constructs that could potentially address the problems this JSR is supposed to solve. These ideas need to be critiqued an drefined by the EG until a suitable specification is obtained.