 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 277: JavaTM Module System
Reason: Withdrawn at the request of the Specification Lead. Superseded by JSR 376. JCP version in use: 2.6 Java Specification Participation Agreement version in use: 2.0 Description: The specification defines a distribution format and a repository for collections of Java code and related resources. It also defines the discovery, loading, and integrity mechanisms at runtime. Please direct comments on this JSR to the Spec Lead(s) Team
This JSR has been Withdrawn
The following updates have been made since the original request.
Supporting this JSR: BEA Systems 2.1 Please describe the proposed Specification:Java Archives (JARs) are widely used as both the distribution and execution format for Java applications. The JAR format dates back to the mid-1990s, and it has not scaled particularly well in either of these roles. JAR files are hard to distribute, hard to version, and hard to reference in general. Distributing a simple Java application is considered to be a complicated task by many developers because it often involves creating a native installer to package multiple JARs into a distribution unit, and it sometimes involves converting the application into a Java applet or JNLP (Java Network Launching Protocol) application for web-based deployment. There is no built-in versioning support in the JAR format. There is no reliable mechanism for expressing, resolving, and enforcing the dependency of one JAR upon another. Referencing a JAR, moreover, involves specifying it in the classpath. Since the path of a JAR may change during deployment, developers are forced to fix up all the references to the deployed JARs as part of the deployment process. Developers also find it quite difficult to deploy installed Java extensions (a.k.a optional packages) because they can easily run into issues like versioning conflict and namespace collision. Java extensions can currently only be installed into a specific Java Runtime Environment (JRE); it is basically impossible to arrange for an installed extension to be shared across multiple JRE installations. The specification of the Java Module System should define an infrastructure that addresses the above issues. Its components are likely to include: o A distribution format (i.e., a Java module) and its metadata as a unit of delivery for packaging collections of Java code and related resources. The metadata would contain information about a module, the resources within the module, and its dependencies upon other modules. The metadata would also include an export list to restrict resources from being exposed outside the module unintentionally. The metadata may allow subset of exposed resources to be used by other modules selectively. o A versioning scheme that defines how a module declares its own version as well its versioned dependencies upon other modules. o A repository for storing and retrieving modules on the machine with versioning and namespaces isolation support. o Runtime support in the application launcher and class loaders for the discovery, loading, and integrity checking of modules. o A set of support tools, including packaging tools as well as repository tools to support module installation and removal. We also expect the Java Module System to expose the public Java SE APIs as a virtual module in order to prevent unwanted usage of the private APIs in the implementation. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)Java SE. 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 is submitted to the Java SE EC although we expect the functionality in this JSR to be heavily used by Java EE. 2.6 Why isn't this need met by existing specifications?The existing specifications are inadequate to addresses the following issues: 1. No uniform deployment model for Java application and extensions. The Java Network Launching Protocol (JNLP, JSR 56) defines a protocol and API that enables Java applications to be deployed on the web. A JNLP descriptor is simply an XML file that describes a collection of resources on the web and the launching options for deploying an application or extension. A JNLP descriptor is completely unbounded with respect to the resources on the web; there is no concept of distribution unit. Because a JNLP descriptor describes resources on the web, it contains hardcoded URLs to the resources, and it is difficult to redistribute the application from different hosts (e.g., for load-balancing) or to deploy from a different target (e.g., Intranet server or CD install). Resource versioning in JNLP is arbitrary, and it does not tie to the actual version of the resource. Finally, in order to take advantage of JNLP, an application or extension must be converted to run in a JNLP client container; this makes JNLP unsuitable as a general application deployment model. The Java Platform, Enterprise Edition (Java EE) specification defines WARs (web application archive) and EARs (enterprise application archive) as packaging formats for Java EE-based applications. These packaging formats were designed for deployment with Java EE containers (i.e., web containers and EJB containers). They cannot be retrofitted for general application deployment purpose. The Java EE specification also mandates explicit support for referencing dependent JARs through the "Class-Path:" manifest entry in the Java EE module. However, the "Class-Path:" entry requires dependent JARs to be referenced through either relative or full file system paths, and there is no built-in versioning support. Therefore, the "Class-Path:" entry is not a sufficient solution to address the JAR referencing problem. In addition, the Java EE specification mandates explicit support for referencing installed extensions through the "Extension-List:" manifest entry in the Java EE module. However, the "Extension-List:" entry only supports extension dependency based on the minimum version of a specification or the minimum version of an implementation, and there is no support for exact version or version range. Thus, the "Extension-List:" entry is not a sufficient solution to address the JAR referencing problem. The R3 version of the Open Services Gateway Initiative (OSGi) specification defines a framework that enables the deployment of service-oriented applications (called bundles). However, the framework only supports package dependency based on the minimum version of a specification, and there is no support for exact version or version range. The framework also supports package dependency based on an implementation, but there is no support for versioning. Moreover, the framework must choose one bundle that will be the provider of the exported package for all bundles which have dependencies on that package, so it is impossible to support more than one version of shared package at runtime. Besides, the selection of exported package provider is anonymous, and there is no way to influence the selection. Because the versioning semantics in the OSGi R3 framework is simplistic, it is not a sufficient solution to address the JAR referencing problem. 2. No means to resolve versioning conflicts and namespace collision among Java extensions in a JRE. The Java Extension Architecture defines how JARs may be referenced through the "Class-Path:" entry in the JAR manifest as bundled extensions, and how JARs may be referenced from {java.home}/lib/ext as installed extensions. Unfortunately, the extension mechanism loads all JARs in the extension directory into the same extension classloader at runtime regardless of whether or not they are actually referenced by the application. As a result, if classes in a referenced JAR have a versioning conflict or namespace collision with classes in some other extension JARs, there is no simple way to resolve the problem. 3. No means to share Java extensions among different JREs on the same system. The Java Extension Architecture allows JARs to be referenced from {java.home}/lib/ext as installed extensions. However, the location is JRE specific, so each JRE may have its own set of installed extensions, and maintaining consistency of installed extensions among JREs on a system is very tedious. 2.7 Please give a short description of the underlying technology or technologies:The Java SE platform already includes support for the JAR format, class-loader delegation, standard extensions, code signing, and verification. 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?The intent is to encourage developers to migrate away from the {java.home}/lib/ext directory as part of Java SE 7. 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 first half of 2006, Public Review in the first half of 2007, and Proposed Final Draft in the second half of 2007. 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.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. Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: Sun Microsystems Name of Contact Person: Stanley M. Ho E-Mail Address: stanley.ho Telephone Number: +1 408 276 7117 Fax Number: +1 408 276 7209 Specification Lead: Stanley M. Ho E-Mail Address: stanley.ho Telephone Number: +1 408 276 7117 Fax Number: +1 408 276 7209 Initial Expert Group Membership: TBD Supporting this JSR: BEA Systems
NOTE that this information has been updated from this original request.
Section 2: Request
2.1 Please describe the proposed Specification:NOTE that this information has been updated from this original request. Java Archives (JARs) are widely used as both the distribution and execution format for Java applications. The JAR format dates back to the mid-1990s, and it has not scaled particularly well in either of these roles. JAR files are hard to distribute, hard to version, and hard to reference in general. Distributing a simple Java application is considered to be a complicated task by many developers because it often involves creating a native installer to package multiple JARs into a distribution unit, and it sometimes involves converting the application into a Java applet or JNLP (Java Network Launching Protocol) application for web-based deployment. There is no built-in versioning support in the JAR format. There is no reliable mechanism for expressing, resolving, and enforcing the dependency of one JAR upon another. Referencing a JAR, moreover, involves specifying it in the classpath. Since the path of a JAR may change during deployment, developers are forced to fix up all the references to the deployed JARs as part of the deployment process. Developers also find it quite difficult to deploy installed Java extensions (a.k.a optional packages) because they can easily run into issues like versioning conflict and namespace collision. Java extensions can currently only be installed into a specific Java Runtime Environment (JRE); it is basically impossible to arrange for an installed extension to be shared across multiple JRE installations. The specification of the Java Module System should define an infrastructure that addresses the above issues. Its components are likely to include: o A distribution format (i.e., a Java module) and its metadata as a unit of delivery for packaging collections of Java code and related resources. The metadata would contain information about a module, the resources within the module, and its dependencies upon other modules. The metadata would also include an export list to restrict resources from being exposed outside the module unintentionally. The metadata may allow subset of exposed resources to be used by other modules selectively. o A versioning scheme that defines how a module declares its own version as well its versioned dependencies upon other modules. o A repository for storing and retrieving modules on the machine with versioning and namespaces isolation support. o Runtime support in the application launcher and class loaders for the discovery, loading, and integrity checking of modules. o A set of support tools, including packaging tools as well as repository tools to support module installation and removal. We also expect the Java Module System to expose the public J2SE APIs as a virtual module in order to prevent unwanted usage of the private APIs in the implementation. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)J2SE. NOTE that this information has been updated from this original request. 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.NOTE that this information has been updated from this original request. This JSR is submitted to the J2SE EC although we expect the functionality in this JSR to be heavily used by J2EE. 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?Developers often find themselves drowning in JARs because JARs are hard to distribute, hard to version, and hard to reference in general. The proposed specification will simplify the deployment of Java-based applications and extensions by making it possible for developers to package them into convenient distribution units and deploy them easily on the system through the repository and the runtime support. 2.6 Why isn't this need met by existing specifications?NOTE that this information has been updated from this original request. The existing specifications are inadequate to addresses the following issues: 1. No uniform deployment model for Java application and extensions. The Java Network Launching Protocol (JNLP, JSR 56) defines a protocol and API that enables Java applications to be deployed on the web. A JNLP descriptor is simply an XML file that describes a collection of resources on the web and the launching options for deploying an application or extension. A JNLP descriptor is completely unbounded with respect to the resources on the web; there is no concept of distribution unit. Because a JNLP descriptor describes resources on the web, it contains hardcoded URLs to the resources, and it is difficult to redistribute the application from different hosts (e.g., for load-balancing) or to deploy from a different target (e.g., Intranet server or CD install). Resource versioning in JNLP is arbitrary, and it does not tie to the actual version of the resource. Finally, in order to take advantage of JNLP, an application or extension must be converted to run in a JNLP client container; this makes JNLP unsuitable as a general application deployment model. The Java 2 Enterprise Edition (J2EE) specification defines WARs (web application archive) and EARs (enterprise application archive) as packaging formats for J2EE-based applications. These packaging formats were designed for deployment with J2EE containers (i.e., web containers and EJB containers). They cannot be retrofitted for general application deployment purpose. The J2EE specification also mandates explicit support for referencing dependent JARs through the "Class-Path:" manifest entry in the J2EE module. However, the "Class-Path:" entry requires dependent JARs to be referenced through either relative or full file system paths, and there is no built-in versioning support. Therefore, the "Class-Path:" entry is not a sufficient solution to address the JAR referencing problem. In addition, the J2EE specification mandates explicit support for referencing installed extensions through the "Extension-List:" manifest entry in the J2EE module. However, the "Extension-List:" entry only supports extension dependency based on the minimum version of a specification or the minimum version of an implementation, and there is no support for exact version or version range. Thus, the "Extension-List:" entry is not a sufficient solution to address the JAR referencing problem. The current version of the Open Services Gateway Initiative (OSGi) specification defines a framework that enables the deployment of service-oriented applications (called bundles). However, the framework only supports package dependency based on the minimum version of a specification, and there is no support for exact version or version range. The framework also supports package dependency based on an implementation, but there is no support for versioning. Moreover, the framework must choose one bundle that will be the provider of the exported package for all bundles which have dependencies on that package, so it is impossible to support more than one version of shared package at runtime. Besides, the selection of exported package provider is anonymous, and there is no way to influence the selection. Because the versioning semantics in the OSGi framework is simplistic, it is not a sufficient solution to address the JAR referencing problem. 2. No means to resolve versioning conflicts and namespace collision among Java extensions in a JRE. The Java Extension Architecture defines how JARs may be referenced through the "Class-Path:" entry in the JAR manifest as bundled extensions, and how JARs may be referenced from {java.home}/lib/ext as installed extensions. Unfortunately, the extension mechanism loads all JARs in the extension directory into the same extension classloader at runtime regardless of whether or not they are actually referenced by the application. As a result, if classes in a referenced JAR have a versioning conflict or namespace collision with classes in some other extension JARs, there is no simple way to resolve the problem. 3. No means to share Java extensions among different JREs on the same system. The Java Extension Architecture allows JARs to be referenced from {java.home}/lib/ext as installed extensions. However, the location is JRE specific, so each JRE may have its own set of installed extensions, and maintaining consistency of installed extensions among JREs on a system is very tedious. 2.7 Please give a short description of the underlying technology or technologies:NOTE that this information has been updated from this original request. The J2SE platform already includes support for the JAR format, class-loader delegation, standard extensions, code signing, and verification. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)All APIs are expected to reside in the java.lang.module package (subject to change). The APIs may provide functionality for discovering, loading, and managing modules in the repository. 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. 2.11 Are there any internationalization or localization issues?No i18n or l10n issue beyond localizing messages in the implementation. 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?NOTE that this information has been updated from this original request. The intent is to encourage developers to migrate away from the {java.home}/lib/ext directory as part of J2SE 7.0. 2.13 Please describe the anticipated schedule for the development of this specification.NOTE that this information has been updated from this original request. The intention is to deliver this JSR as a component of J2SE 7.0 (code name "Dolphin"). Early Draft Review would occur in the first 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.A mailing list is intended to be the primary communication mechanism among members of the expert group. 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.We anticipate providing draft specs every two to three months after the first draft is released until the Proposed Final Draft. A JSR interest mailing list will be established so interested parties can be informed of issues under discussion. 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.NOTE that this information has been updated from this original request. This JSR and its RI and TCK are intended to be part of the J2SE 7.0 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).Not applicable. 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.NOTE that this information has been updated from this original request. The RI and TCK will be delivered and licensed as part of the RI and TCK for J2SE 7.0. 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.Not applicable. 3.2 Explanation of how these items might be used as a starting point for the work.Not applicable. Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.The expert group will seek to learn from the work of these existing initiatives during the development of this JSR: [1] OSGi Service Platform: http://www.osgi.org/ [2] Eclipse Plug-in Architecture: http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html [3] NetBeans Module Architecture: http://www.netbeans.org/project/www/download/dev/javadoc/OpenAPIs/org/openide/modules/doc-files/api.html [4] .NET Assemblies: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconassemblies.asp In addition, the expert group will seek to learn from this existing initiative for its repository feature: [1] Maven: http://maven.apache.org/ |
|||||||||||||||||||||||||||||||||||||||||||||||||||||
