Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Pack200"

(Jar Processor: corrected the bundle name in 3.6)
 
(10 intermediate revisions by 5 users not shown)
Line 1: Line 1:
'''Overview'''<br>
+
==Overview==
<p>Pack200 is a compression technology included in Java 1.5.0.  It was designed for compressing jars and works most efficiently on Java class files.  Using Pack200 compression can reduce the size of a jar by about 60%.</p>
+
<p>Pack200 is a compression technology included in Java 1.5.0.  It was designed for compressing jars and works most efficiently on Java class files.  Using Pack200 compression can reduce the size of a jar by about 60%.  By packing the jars placed on an update site and enabling update to unpack those jars after download, the amount of data downloaded during an update can be greatly reduced.</p>
 +
<br>
 +
===Compression and Signing===
 
<p>Pack200 is not a lossless compression.  Packing and unpacking will produce a jar that is semantically the same as the original, but classfile structures will be rearranged; the resulting jar will not be identical to the original.  However, this reordering is idempotent so a second pack-unpack will not further change the jar.</p>
 
<p>Pack200 is not a lossless compression.  Packing and unpacking will produce a jar that is semantically the same as the original, but classfile structures will be rearranged; the resulting jar will not be identical to the original.  However, this reordering is idempotent so a second pack-unpack will not further change the jar.</p>
  
'''Signing'''<br>
+
<p>Pack200 reduces the size of a JAR file by:
<p>Signing a jar hashes the contents and stores the hash codes in the manifest.  Since packing and unpacking a jar will modify the contents, the jar must be normalized prior to signing.  Normalizing the jar will also be refered to as repacking the jar.</p>
+
#Merging and sorting the constant-pool data in the class files and co-locating them in the archive.
 +
#Removing redundant class attributes.
 +
#Storing internal data structures.
 +
#Using delta and variable length encoding.
 +
#Choosing optimum coding types for secondary compression.
 +
</p>
 +
 
 +
<p>Signing a jar hashes the contents and stores the hash codes in the manifest.  Since packing and unpacking a jar will modify the contents, the jar must be normalized prior to signing.  Normalizing the jar will also be refered to as repacking or conditioning the jar.</p>
  
 
== Jar Processor ==
 
== Jar Processor ==
<p>The Jar Processor is a tool provided by the org.eclipse.update.core bundle that will recursively run the pack200, signing and unpack200 tools on a jar and its nested jars.  The jar processor can be exported into a self contained jar using the <code>org.eclipse.update.internal.jarprocessor/jarprocessor.jardesc</code> jar description file.  The jar processor can also be accessed through the <code>org.eclipse.update.core.siteOptimizer</code> application.</p>
+
<p>The Jar Processor is a tool that will recursively run the pack200, signing, and unpack200 tools on a jar and its nested jars.  The jar processor can be used during a build to repack, sign and pack jars for an update site.  It is also used by eclipse itself to unpack compressed jars downloaded from an update site.</p>
 +
 
 +
The jar processor requires a 1.5 jre to perform the pack and unpack.
 +
 
 +
<p>In Eclipse 3.3 and earlier the jarprocessor was part of the org.eclipse.update.core bundle and can be exported into a self contained jar using the <code>org.eclipse.update.internal.jarprocessor/jarprocessor.jardesc</code> jar description file.  The jar processor can also be accessed through the <code>org.eclipse.update.core.siteOptimizer</code> application.
 +
<pre>java -jar /eclipse/startup.jar -application org.eclipse.update.core.siteOptimizer -jarProcessor <options> [input]</pre>
 +
 
 +
In Eclipse 3.4 and later, the jarprocessor is its own bundle "org.eclipse.equinox.p2.jarprocessor".  It can be run as plain old java using
 +
<pre>java -cp org.eclipse.equinox.p2.jarprocessor_<version>.jar org.eclipse.equinox.internal.p2.jarprocessor.Main <options> [input]</pre>
 +
or in 3.6 and later:
 +
<pre>java -jar org.eclipse.equinox.p2.jarprocessor_&lt;version&gt;.jar <options> [input]</pre>
 +
 
 +
By default the Jar Processor will only process jars that have been previously marked as conditioned.  This allows the Jar Processor to be run on an entire update site and only process those jars that have been previously conditioned.  Marking a jar is done by the <tt>-repack</tt> option by placing a <tt>META-INF/eclipse.inf</tt> file in the jar.  Repacking must be done using the <tt>-processAll</tt> option since the jars won't be marked before repacking.
  
 
The jarprocessor understands the following command-line options:
 
The jarprocessor understands the following command-line options:
Line 14: Line 35:
 
!width="500"|Effect
 
!width="500"|Effect
 
|-
 
|-
|&ndash;repack
+
|<b>-processAll</b>
|Normalize the jar by calling the pack200 tool with the -repack option.
+
|Process all jars.  If this is not specified only previously conditioned and marked jars are processed.
 
|-
 
|-
|&ndash;pack
+
| -repack
 +
|Normalize the jar by calling the pack200 tool with the -repack option.  The -processAll option must be specified in order to normalize a jar for the first time.
 +
|-
 +
| -pack
 
|Pack the jar using the pack200 tool
 
|Pack the jar using the pack200 tool
 
|-
 
|-
|&ndash;sign <command>
+
| -sign <command>
 
|Sign the jar using the provided command.  The sign command will be provided the name of the jar to sign as its first argument.
 
|Sign the jar using the provided command.  The sign command will be provided the name of the jar to sign as its first argument.
 
|-
 
|-
|&ndash;unpack
+
| -unpack
 
|Unpack a pack.gz file into a jar using the unpack200 tool.
 
|Unpack a pack.gz file into a jar using the unpack200 tool.
 
|-
 
|-
|&ndash;outputDir <directory>
+
| -outputDir <directory>
 
|The directory in which to place the results.
 
|The directory in which to place the results.
 +
|-
 +
| -verbose
 +
|Use verbose mode
 
|}
 
|}
 
The repack, sign and pack options can be specified together.  When specifying all 3, the input jar will first be normalized, then signed, then packed.  The output will be the signed jar and a packed jar.pack.gz file.
 
The repack, sign and pack options can be specified together.  When specifying all 3, the input jar will first be normalized, then signed, then packed.  The output will be the signed jar and a packed jar.pack.gz file.
== Update Sites ==
+
<br>
== External Links ==
+
===Options===
 +
In addition to command line arguments, options can also be supplied to JarProcessor on a per-jar basis using configurations files nested within the jars being processed. These options give complete control of what jars are signed and packed within a recursive tree of zips/jars. See the [[JarProcessor_Options|options page]] for details on these options available for the jar processor.
 +
 
 +
===Input===
 +
The jar processor takes as input either a .zip file, a .jar (or .pack.gz) file, or a directory.
 +
*If the input is a zip file, then each contained .jar (or .pack.gz if unpacking) will be processed.  A new .zip file will be created in the output directory containing the results. 
 +
*If the input is a single .jar (or .pack.gz file) then that file is processed.
 +
*If the input is a directory then all .jar (or .pack.gz files) in that directory, and its subdirectories, will be processed.
 +
<br>
 +
<br>
 +
===Examples===
 +
3.5 style:
 +
<pre>
 +
java -cp org.eclipse.equinox.p2.jarprocessor_1.0.100.v20090520-1905.jar org.eclipse.equinox.internal.p2.jarprocessor.Main
 +
-processAll -repack -sign signing-script.sh -outputDir ./out eclipse-SDK.zip
 +
</pre>
 +
<p>This will run the jar processor using the siteOptimizer application.  For each jar file in eclipse-SDK.zip, the jar processor will normalize the jar by repacking it, mark the jar as conditioned by placing a <tt>META-INF/eclipse.inf</tt> file in the jar, then sign it by executing <code>signing-script.sh <jar></code>.  A zip <tt>./out/eclipse-SDK.zip</tt> will be created containing the repacked signed jars.  Any non-jar file in the input eclipse-SDK.zip will be copied over to the ./out/eclipse-SDK.zip as is.</p>
 +
 
 +
3.6 style:
 +
<pre>
 +
java -jar org.eclipse.equinox.p2.jarprocessor_1.0.200.v20100123-1019.jar
 +
-processAll -repack -sign signing-script.sh -pack -outputDir ./out eclipse-SDK.zip
 +
</pre>
 +
<p>This command will do the same as the first example, but will also pack the signed jars.  The output ./out/eclipse-SDK.zip file will contain both the signed jars and the .jar.pack.gz versions.</p>
 +
<pre>
 +
java -jar org.eclipse.equinox.p2.jarprocessor_1.0.200.v20100123-1019.jar -pack myJar.jar
 +
 
 +
java -jar org.eclipse.equinox.p2.jarprocessor_1.0.200.v20100123-1019.jar -unpack myJar.jar.pack.gz
 +
</pre>
 +
<p>These two commands are the inverses of each other.  The first will pack <code>myJar.jar</code> and produce a <code>myJar.jar.pack.gz</code> if the original myJar.jar was marked as conditioned.  Since no outputDir is specified, the .pack.gz file will be created in the current directory.  If <code>myJar.jar</code> contained a nested jar, then that nested jar will be packed first and the resulting <code>myJar.jar.pack.gz</code> would contain a nested <code>nested.jar.pack.gz</code>.  The second command will unpack the <code>myJar.jar.pack.gz</code> file and produce a <code>myJar.jar</code>.  The nested <code>nested.jar.pack.gz</code> will also be unpacked.  Again, because no outputDir is specified, the output will be in the current directory, overwriting the original <code>myJar.jar</code>.</p>
 +
<br>
 +
===Pack200 Executable location===
 +
By default, the jar processor will look for the pack200 and unpack200 executables first in the <code>${java.home}/bin</code> directory and then on the system search path.  However, the location of these tools can also be specified using the java system property <code>org.eclipse.update.jarprocessor.pack200</code>. The value is expected to be the directory containing the pack200 and unpack200 executables or one of the following special values:
 +
*"@jre" - find unpack200 in ${java.home}/bin
 +
*"@path" - find unpack200 on the search path
 +
*"@none" - pack200 not supported, download normal jars from update sites.
 +
 
 +
<br>
 +
 
 +
== Related Pages ==
 +
*[[Update Site Optimization]]
 +
*[[Callisto Coordinated Update Sites]]
 +
*[[JAR Signing]]
 +
===External Links===
 
[http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/pack200.html Pack200 and Compression]<br>
 
[http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/pack200.html Pack200 and Compression]<br>
 
[http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/pack200.html JAR Packing tool]<br>
 
[http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/pack200.html JAR Packing tool]<br>
 
[http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/unpack200.html JAR Unpacking tool]<br>
 
[http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/unpack200.html JAR Unpacking tool]<br>
 
[http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/jarsigner.html JAR Signing and Verification tool]<br>
 
[http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/jarsigner.html JAR Signing and Verification tool]<br>
 +
 +
[[Category:Releng]]

Latest revision as of 13:19, 21 August 2010

Overview

Pack200 is a compression technology included in Java 1.5.0. It was designed for compressing jars and works most efficiently on Java class files. Using Pack200 compression can reduce the size of a jar by about 60%. By packing the jars placed on an update site and enabling update to unpack those jars after download, the amount of data downloaded during an update can be greatly reduced.


Compression and Signing

Pack200 is not a lossless compression. Packing and unpacking will produce a jar that is semantically the same as the original, but classfile structures will be rearranged; the resulting jar will not be identical to the original. However, this reordering is idempotent so a second pack-unpack will not further change the jar.

Pack200 reduces the size of a JAR file by:

  1. Merging and sorting the constant-pool data in the class files and co-locating them in the archive.
  2. Removing redundant class attributes.
  3. Storing internal data structures.
  4. Using delta and variable length encoding.
  5. Choosing optimum coding types for secondary compression.

Signing a jar hashes the contents and stores the hash codes in the manifest. Since packing and unpacking a jar will modify the contents, the jar must be normalized prior to signing. Normalizing the jar will also be refered to as repacking or conditioning the jar.

Jar Processor

The Jar Processor is a tool that will recursively run the pack200, signing, and unpack200 tools on a jar and its nested jars. The jar processor can be used during a build to repack, sign and pack jars for an update site. It is also used by eclipse itself to unpack compressed jars downloaded from an update site.

The jar processor requires a 1.5 jre to perform the pack and unpack.

In Eclipse 3.3 and earlier the jarprocessor was part of the org.eclipse.update.core bundle and can be exported into a self contained jar using the org.eclipse.update.internal.jarprocessor/jarprocessor.jardesc jar description file. The jar processor can also be accessed through the org.eclipse.update.core.siteOptimizer application.

java -jar /eclipse/startup.jar -application org.eclipse.update.core.siteOptimizer -jarProcessor <options> [input]

In Eclipse 3.4 and later, the jarprocessor is its own bundle "org.eclipse.equinox.p2.jarprocessor". It can be run as plain old java using

java -cp org.eclipse.equinox.p2.jarprocessor_<version>.jar org.eclipse.equinox.internal.p2.jarprocessor.Main <options> [input]

or in 3.6 and later:

java -jar org.eclipse.equinox.p2.jarprocessor_<version>.jar <options> [input]

By default the Jar Processor will only process jars that have been previously marked as conditioned. This allows the Jar Processor to be run on an entire update site and only process those jars that have been previously conditioned. Marking a jar is done by the -repack option by placing a META-INF/eclipse.inf file in the jar. Repacking must be done using the -processAll option since the jars won't be marked before repacking.

The jarprocessor understands the following command-line options:

Option Effect
-processAll Process all jars. If this is not specified only previously conditioned and marked jars are processed.
-repack Normalize the jar by calling the pack200 tool with the -repack option. The -processAll option must be specified in order to normalize a jar for the first time.
-pack Pack the jar using the pack200 tool
-sign <command> Sign the jar using the provided command. The sign command will be provided the name of the jar to sign as its first argument.
-unpack Unpack a pack.gz file into a jar using the unpack200 tool.
-outputDir <directory> The directory in which to place the results.
-verbose Use verbose mode

The repack, sign and pack options can be specified together. When specifying all 3, the input jar will first be normalized, then signed, then packed. The output will be the signed jar and a packed jar.pack.gz file.

Options

In addition to command line arguments, options can also be supplied to JarProcessor on a per-jar basis using configurations files nested within the jars being processed. These options give complete control of what jars are signed and packed within a recursive tree of zips/jars. See the options page for details on these options available for the jar processor.

Input

The jar processor takes as input either a .zip file, a .jar (or .pack.gz) file, or a directory.

  • If the input is a zip file, then each contained .jar (or .pack.gz if unpacking) will be processed. A new .zip file will be created in the output directory containing the results.
  • If the input is a single .jar (or .pack.gz file) then that file is processed.
  • If the input is a directory then all .jar (or .pack.gz files) in that directory, and its subdirectories, will be processed.



Examples

3.5 style:

java -cp org.eclipse.equinox.p2.jarprocessor_1.0.100.v20090520-1905.jar org.eclipse.equinox.internal.p2.jarprocessor.Main
 -processAll -repack -sign signing-script.sh -outputDir ./out eclipse-SDK.zip
<p>This will run the jar processor using the siteOptimizer application. For each jar file in eclipse-SDK.zip, the jar processor will normalize the jar by repacking it, mark the jar as conditioned by placing a META-INF/eclipse.inf file in the jar, then sign it by executing signing-script.sh <jar>. A zip ./out/eclipse-SDK.zip will be created containing the repacked signed jars. Any non-jar file in the input eclipse-SDK.zip will be copied over to the ./out/eclipse-SDK.zip as is.

3.6 style:

java -jar org.eclipse.equinox.p2.jarprocessor_1.0.200.v20100123-1019.jar
 -processAll -repack -sign signing-script.sh -pack -outputDir ./out eclipse-SDK.zip

This command will do the same as the first example, but will also pack the signed jars. The output ./out/eclipse-SDK.zip file will contain both the signed jars and the .jar.pack.gz versions.

java -jar org.eclipse.equinox.p2.jarprocessor_1.0.200.v20100123-1019.jar -pack myJar.jar

java -jar org.eclipse.equinox.p2.jarprocessor_1.0.200.v20100123-1019.jar -unpack myJar.jar.pack.gz

These two commands are the inverses of each other. The first will pack myJar.jar and produce a myJar.jar.pack.gz if the original myJar.jar was marked as conditioned. Since no outputDir is specified, the .pack.gz file will be created in the current directory. If myJar.jar contained a nested jar, then that nested jar will be packed first and the resulting myJar.jar.pack.gz would contain a nested nested.jar.pack.gz. The second command will unpack the myJar.jar.pack.gz file and produce a myJar.jar. The nested nested.jar.pack.gz will also be unpacked. Again, because no outputDir is specified, the output will be in the current directory, overwriting the original myJar.jar.


Pack200 Executable location

By default, the jar processor will look for the pack200 and unpack200 executables first in the ${java.home}/bin directory and then on the system search path. However, the location of these tools can also be specified using the java system property org.eclipse.update.jarprocessor.pack200. The value is expected to be the directory containing the pack200 and unpack200 executables or one of the following special values:

  • "@jre" - find unpack200 in ${java.home}/bin
  • "@path" - find unpack200 on the search path
  • "@none" - pack200 not supported, download normal jars from update sites.


Related Pages

External Links

Pack200 and Compression
JAR Packing tool
JAR Unpacking tool
JAR Signing and Verification tool

Back to the top