With the new JDK 1.5 Tiger beta, there are lots of thoughts flowing from developers on the new features. One of these is the javax.pack package which provides methods to read files from a JAR file and to transform them to Pack200 format. It also provides methods to expand Pack200 format back to a JAR file equivalent to the original JAR.

Eugene Kuleshov wrote some code to experiment and SEE what kind of compression he could get. The numbers look great. He took the rt.jar and compressed it to 12% (with a pack and zip).

Read Eugene Kuleshov in Crunching jars up to less then 10% of the original size.

That's really amazing.

You are right. I think part of my brain didn't think it was possible so it used the wrong words :)

Dion

The jar file packed down to 12%, and 'some UML tool' packed down into 8.5%. These results were a combination of using Pack200 and zip. I'm sure the results will vary with the individual file.

Pretty impressive in any case.

So why the new JDK1.5 doesn't use Pack as default instead of jar format, and why it took so long to come out with something better the jar format? Would be interesting to compare the new Pack format with the old CAB one.

Actually, the pack format has been around for a while - you might have noticed how the JRE download has been under 10MB for a while, even though rt.jar alone is around 30MB.

You don't need pack for that. 1.4.2_02 with included server vm is 44,1MB and compresses to 17MB with regular winzip.

IMHO, this is massively good news for client side java applications. If the 1.5 JRE installer uses the pack format (which I'm sure they will do, as this may have been the sole reason for including it) the download could get down to 4-6 MB, a great improvement for desktop java applications. As long as the time required for decompression is reasonable, the time for compression, which I've read is a bit high, becomes irrelevant and we have an easy to download and distribute JRE. Well done!

less *than* 10% of their size :)