db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kim Haase (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (DERBY-1008) Derby JARs downloadable / archiving footprint can be reduced dramatically using Java 5 Pack200 Compression capability - Deployment Enhancement Documentation
Date Mon, 08 Sep 2014 21:04:28 GMT

     [ https://issues.apache.org/jira/browse/DERBY-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Kim Haase closed DERBY-1008.
    Resolution: Won't Fix

This is a Java SE feature not strictly related to Derby, and no one seems to have felt strongly
enough about it to push for it to be documented.

> Derby JARs downloadable / archiving footprint can be reduced dramatically using Java
5 Pack200 Compression capability - Deployment Enhancement Documentation
> ------------------------------------------------------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-1008
>                 URL: https://issues.apache.org/jira/browse/DERBY-1008
>             Project: Derby
>          Issue Type: Improvement
>          Components: Documentation
>    Affects Versions:
>            Reporter: Francois Orsini
>            Priority: Minor
> 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
> 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:
> http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/pack200.html
> 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):
> http://java.sun.com/j2se/1.5.0/docs/api/java/util/jar/Pack200.html
> 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 was sent by Atlassian JIRA

View raw message