db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francois Orsini (JIRA)" <derby-...@db.apache.org>
Subject [jira] Created: (DERBY-1008) Derby JARs downloadable / archiving footprint can be reduced dramatically using Java 5 Pack200 Compression capability - Deployment Enhancement Documentation
Date Sat, 18 Feb 2006 02:18:25 GMT
Derby JARs downloadable / archiving footprint can be reduced dramatically using Java 5 Pack200
Compression capability - Deployment Enhancement Documentation

         Key: DERBY-1008
         URL: http://issues.apache.org/jira/browse/DERBY-1008
     Project: Derby
        Type: Improvement
  Components: Documentation  
    Reporter: Francois Orsini

PACK200 (JSR-200) is a very interesting feature that is available as part of J2SE 1.5.

In order to increase network server, availability and bandwidth , two new compression formats
have been made available to Java deployment of applications and applets: gzip and Pack200.

HTTP compression is implemented in Java Web Start and Java Plug-in in compliance with HTTP
1.1 RFC 2616. If a client does not support this type of compression then a web server will
send a non-compressed JAR or a format that the client can process.

More information about Pack200 at:

I have compressed the Apache Derby engine JAR file (derby.jar) using pack200 and the resulting
JAR went from 2,131,777 to 630,520 bytes (~2MB down to 600K for the database core engine!).
Uncompression happens on the client side automatically once the pack200 compressed JAR has
been fetched and the client is capable of handling pack200 archives.

To compress/pack the JAR archive:
$ pack200 derby.jar.pack.gz derby.jar

It then can be stored on a HTTP 1.1 compliant web server and if a web client support pack200-gzip
encoding (specified as part of the HTTP request), then the server will send that compressed
JAR down - otherwise the server will stream/send a format that the client can process (compressed
{gzip} or not {.jar}).

To unpack (manually):
$ unpack200 derby.jar.pack.gz derby.jar (the unpack operation is actually pretty fast)

This is quite good when one needs to deploy Apache Derby over a network (i.e. Applet using
Derby with the Java plug-in or plain HTTP download, etc) or as part of some offline installer
who would want to pack JARs then unpack them during install (unpack200{.exe} is a standalone
executable that can be included as part of an installer).

pack200 and unpack200 are pure executable(s) that do not require a JVM to be present or run
at the time an archive is compressed or uncompressed (i.e. during installation)

unpack200 (Unix) or unpack200.exe(Windows) included as part of the JRE as well (under bin)
- at least for Sun J2SE.

Pack200 also has a Java API (java.util.jar.Pack200):
The packer engine is used by application developers to deploy or host JAR files on a website.
The unpacker engine is used by deployment applications to transform the byte-stream back to
JAR format.

This does not reduce the runtime footprint of Apache Derby - it basically provides means to
reduce the downloable footprint of JARs during install. Pack200 also supports the packing
of *signed* JARs.

I'm entering this JIRA hoping that we can document this deployment capability in the Derby
Developer's Guide (for instance) under some Deployment section. I believe that Derby deployment
enhancements should be worth mentioning in some developer's guide.

Other interesting uses would be:

- to pack200 a JAR containing some Derby database along with the application and else...reducing
the downloadble/shippable footprint.

- to allow pack200 jars to be stored within Derby - could be unpacked on the fly using the
java.util.jar.Pack200 API.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message