Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 200: Network Transfer Format for JavaTM Archives.

Stage Access Start Finish
Final Release Download page 30 Sep, 2004  
Final Approval Ballot View results 31 Aug, 2004 13 Sep, 2004
Proposed Final Draft 4 Download page 06 Aug, 2004  
Proposed Final Draft 3 Download page 16 Jul, 2004  
Proposed Final Draft 2 Download page 03 Jun, 2004  
Proposed Final Draft Download page 18 May, 2004  
Public Review Download page 16 Dec, 2003 14 Feb, 2004
Community Draft Ballot View results 26 Aug, 2003 02 Sep, 2003
Community Review Login page 31 Jul, 2003 02 Sep, 2003
Expert Group Formation   13 Dec, 2002 06 May, 2003
JSR Review Ballot View results 26 Nov, 2002 09 Dec, 2002
Status: Final
JCP version in use: 2.6
Java Specification Participation Agreement version in use: 2.0

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)

Specification Leads
  John Rose Sun Microsystems, Inc.
  Kumar Srinivasan Sun Microsystems, Inc.
Expert Group
  Pugh, William SAS Institute Inc. Sun Microsystems, Inc.
  Zero G Software

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.
William Pugh, University of Maryland Oracle Corporation.

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?


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


2.9 Are there any internationalization or localization issues?


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.
No changes to the JavaTM Virtual Machine specification are required by this JSR. This JSR merely defines a download format. The downloaded file is unpacked into a regular JavaTM JAR file before it is presented to the virtual machine.

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).


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:
Academic and Research Papers:
Compressing Java Class Files - William Pugh
More Efficient Class Loading through Bundling - David Hovemeyer and William Pugh
The Class Archive Format - Denis N Antonioli
JARG Java Archive Grinder

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.