I report the size of jar files, j0r.gz files (jar files without individual classfile compression but with overall zlib compression), Jazz files [BHV98] (Section 13.1) and the archives produced by the techniques described in this paper.
I also report, in the archives I produce, how much space is occupied by strings (string constants, class and method names, ...), opcodes, integers, references and other (including floating point constants, branch offsets and registers). As you can see, no one element dominates, so obtaining substantial additional reduction in archive size would likely require substantial reductions in all elements.
The decompressor can decompress about 75-120 Kbytes of wire-format classfiles per second (which would expand into a substantially larger collection of classfiles). This is on a Sun Ultra 5 workstation with a 333Mhz processor using the Sun Solaris production JVM, version 1.2fcs, which achieves a JVM98 Specmark of 16.6.
The compressor is about 15 times slower than the decompressor, but at the moment it still contains a fair bit of code for generating statistics and is a very general purpose compressor (i.e., can implement many different compression schemes). A rewrite of the compressor should provide substantial speed improvements.
The decompressor is 36 Kbytes in jar format, so if the decompressor had to be downloaded along with a packed archived, it would only be advantageous for larger archives. The decompressor is 23 Kbytes in j0r.gz format, so it could be loaded by first downloading (a tiny) a classloader than understood j0r.gz archives, and then downloading the decompressor. If the decompressor were installed as an standard extension, then this wouldn't be an issue and would be fine for even very small archives.