Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / April 2007

Tip: Looking for answers? Try searching our database.

Compression used in Sun's JDK/JRE downloads?

Thread view: 
NotForMail@sonic.net - 15 Apr 2007 18:17 GMT
How does sun get their compressed archive of Java binaries down to 15MB?
When I uncompress these and then 'zip' or 'tar czf' the resulting file
is 25MB, even using maximum compression flags.

NM
Tom Hawtin - 15 Apr 2007 18:40 GMT
> How does sun get their compressed archive of Java binaries down to 15MB?
> When I uncompress these and then 'zip' or 'tar czf' the resulting file
> is 25MB, even using maximum compression flags.

Since 1.2.2(?) they have something similar to pack200. If you were to
dig up a copy of 1.2.1, you should find it much larger.

Instead of individually compressing a large set of files each with
duplicate data (signature strings, for example), a single file is
produced that shares data between classes. This file can then be
compressed as a single stream.

For more information, google 'pack200'.

Tom Hawtin
NotForMail@sonic.net - 17 Apr 2007 01:45 GMT
>> How does sun get their compressed archive of Java binaries down to 15MB?
>> When I uncompress these and then 'zip' or 'tar czf' the resulting file
>> is 25MB, even using maximum compression flags.
>
>Since 1.2.2(?) they have something similar to pack200. If you were to
>dig up a copy of 1.2.1, you should find it much larger.

Doesn't look like they're using the pack200 distributed with the
jdk, that creates archives that are 48% of original size.  No real
difference from gzip.  

Sun's jdk.*.bin downloads are 39% of the original size.  The only
tool does better is lzma, which creates archives that are 34% of the
original size.

# sh jdk-1_5_0_11-linux-amd64.bin && du -bs jdk1.5.0_11
113483747       jdk1.5.0_11

# jar cMf jdk1.5.0_11.jar jdk1.5.0_11 && du -bs jdk1.5.0_11.jar
55557396        jdk1.5.0_11.jar      (49% of original size)

# tar czvf jdk1.5.0_11.tgz jdk1.5.0_11 && du -bs jdk1.5.0_11.tgz
54730784        jdk1.5.0_11.tgz      (48% of original size)

# pack200 -J-Xmx500M -S-1 -E9 x.pack.gz jdk1.5.0_11.jar && \
# du -bs x.pack.gz
54622334        x.pack.gz      (48% of original size)

# du -bs jdk-1_5_0_11-linux-amd64.bin (Sun original)
43930095        jdk-1_5_0_11-linux-amd64.bin      (39% of original size)

# tar cvf - jdk1.5.0_11 | lzma -9 > jdk1.5.0_11.tar.lzma && \
# du -bs jdk1.5.0_11.tar.lzma
39714345        jdk1.5.0_11.tar.lzma      (34% of original size)

Since Sun's shar files contain self-extracting SFX archives they must have
some custom software that can be decompressed with gzip/unzipsfx.

NM
Tom Hawtin - 17 Apr 2007 02:50 GMT
>> Since 1.2.2(?) they have something similar to pack200. If you were to
>> dig up a copy of 1.2.1, you should find it much larger.
[quoted text clipped - 4 lines]
>  # du -bs x.pack.gz
>  54622334        x.pack.gz      (48% of original size)

I'm not particularly surprised pack200 on the installer doesn't work too
well. It's not going to comprise of all the class files in a ready to
run state, so pack200 wont help. Running it on rt.jar might give you
better figures. Also, IIRC, the JDK contains some debugging info (such
as line numbers) whereas the JRE does not. Presumably there is not a
great deal of point optimising pack200 to deal with debugging
information efficiently.

Tom Hawtin


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.