 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 200: Network Transfer Format for JavaTM Archives.
JCP version in use: 2.6 Java Specification Participation Agreement version in use: 2.0 Description: This JSR will define a dense download format for JavaTM classfiles. It is expected that this format can achieve considerable size savings over compressed JAR files. Please direct comments on this JSR to the Spec Lead(s) Team
Original Java Specification Request (JSR)
Identification |
Request |
Contributions Section 1. Identification Submitting Member: Sun Microsystems, Inc. Name of Contact Person: John Rose, Kumar Srinivasan E-Mail Address: John.Rose@Sun.COM, Kumar.Srinivasan@Sun.COM Telephone Number: +1 408 276 7263, +1 408 276 7586 Fax Number: Specification Lead: John Rose, Kumar Srinivasan E-Mail Address: John.Rose@Sun.COM, Kumar.Srinivasan@Sun.COM Telephone Number: +1 408 276 7263, +1 408 276 7586 Fax Number: Initial Expert Group Membership:
Supporting this JSR: Sun Microsystems, Inc. Section 2: Request
2.1 Please describe the proposed Specification:This JSR will define a dense download format for JavaTM classfiles. It is expected that this format can achieve considerable size savings over compressed JAR files. In recent years, we have had great advancement of processor speeds with comparatively poor improvements in network bandwidth, leaving us with high performing, low cost systems operating on slow networks. With the growing popularity of the JavaTM Programming Language, the overall size and volume of JavaTM applications have multiplied and it is desirable to reduce the download size for large web deployed JavaTM applications. Currently the JavaTM platform uses JavaTM Archive (JAR) encapsulation of these applications and their classes. The JavaTM archive format can compress these classes at the byte level only, leading to a meager reduction factor of about two. We need to compress the classes much more efficiently, thus making network transfers faster and therefore more reliable. An example of a more effective compression technology is the Pack format which was developed to reduce the download size of the JRE (J2SE Runtime Environment) installer for windows in J2SE v1.4.1 and J2SE1.4.2. The Pack format simultaneously organizes the layout of all classes and resource files within a JAR, removing repetitions of shared structures, and yielding a reduction factor of seven to nine. (This relies on a post-packing compression step using, an off the-shelf-utility such as zip.) After a comparatively fast download, the receiving system uncompresses and unpacks the data, producing a locally stored Jar archive equivalent to the originally packed Jar. The unpacked Jar file is ready for the consumption of the JavaTM applications and the VM. Pack has proven very effective at compressing the JavaTM class files delivered within the JRE. We would therefore like to develop a JavaTM community standard so that a similar highly compressed format can be used by application developers to package their JavaTM applications. While Sun is offering the Pack format as a potential starting point for the Network Transfer Format, the Expert Group will also be open to evaluating other formats or to enhancing the Pack format to achieve better compression. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)Java 2, Standard Edition, this technology is typically intended to make the deployment of JavaTM applications more efficient. 2.3 What need of the Java community will be addressed by the proposed specification?This will make the deployment of JavaTM applications faster and more network efficient. 2.4 Why isn't this need met by existing specifications?The current JavaTM Class Format is sparse and therefore not network efficient. 2.5 Please give a short description of the underlying technology or technologies:Runtime APIs to pack and unpack the data and a network format. 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)Yes the proposed names are javax.pack.*. 2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 2.8 Are there any security issues that cannot be addressed by the current security model?No 2.9 Are there any internationalization or localization issues?No 2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No existing mechanisms will be altered or deprecated. However, it is anticipated that some specifications (such as JNLP specification) may make use of this feature in future revisions. 2.11 Please describe the anticipated schedule for the development of this specification.The product will be ready for the Tiger release of J2SDK and J2RE. 2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.It is anticipated that most of the work will be done by email. 2.13 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 will be delivered as part of J2SE 1.5 "Tiger". 2.14 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.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.This JSR will be delivered as part of J2SE 1.5 "Tiger". The proposed J2SE 1.5 licensing terms are available here. 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 JavaTMVirtual Machine Specification, and the JAR specification. The existing Pack and Unpack implementation used by the J2SE 1.4.1/1.4.2 installers.
Prior work on compressed classfile fomats includes the following: 3.2 Explanation of how these items might be used as a starting point for the work.The existing JavaTM Virtual Machine Specification is used as the basis for this work. The Pack format was developed at Sun, in late 1996. "Compressing JavaTM Class Files Paper " was used to cross-check the techniques described here, and inspired some adjustments. Although the Pack format is substantially complete, we welcome new ideas of improvement. It is our intention to provide application developers with options to discard or retain class file attributes. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
