rt.jar put on a Proguard diet losses 26 MB
Jeff Palmer
jcpalmer at rochester.rr.com
Sat Dec 15 14:08:57 PST 2012
I just did a production JWS implementation, and am now just doing a little alternative exploration for the future.
I did a series experiments. One which actually worked, had a really big impact. On windows, I ran this build.xml file with proguard 4.8 against the latest jre, release 10:
<?xml version="1.0" encoding="UTF-8"?>
<project name="proguard rt">
<description>see effects of proguard on rt.jar</description>
<property name="java-lib" location="..\Progra~2\Java\jre7\lib"/>
<taskdef
resource="proguard/ant/task.properties"
classpath="../proguard4.8/lib/proguard.jar"
/>
<target name="shrink">
<proguard>
-injars ${java-lib}/original-rt.jar
<!-- -injars ${java-lib}/alt-rt.jar-->
<!-- -injars ${java-lib}/jce.jar-->
<!-- -injars ${java-lib}/charsets.jar-->
<!-- -injars ${java-lib}/deploy.jar-->
<!-- -injars ${java-lib}/javaws.jar-->
<!-- -injars ${java-lib}/jfr.jar-->
<!-- -injars ${java-lib}/jfxrt.jar-->
<!-- -injars ${java-lib}/jsse.jar-->
<!-- -injars ${java-lib}/management-agent.jar-->
<!-- -injars ${java-lib}/plugin.jar-->
<!-- -injars ${java-lib}/resources.jar-->
-outjars new-rt.jar
-verbose
-dontoptimize
-dontshrink
-dontobfuscate
-ignorewarnings <!-- 755 warnings, but they do not matter -->
-target 7
-renamesourcefileattribute Line
-keepattributes Exceptions,InnerClasses,Signature,Deprecated,SourceFile,LineNumberTable,*Annotation*,EnclosingMethod
</proguard>
</target>
</project>
rt.jar went from 50,469 KB to 24,207 KB. That's a 52% reduction! Copied new-rt.jar over rt.jar in java-lib, and my apps still work. Anyone know why rt.jar is so big? Alignment or compression level maybe? I looked at both jars using this jd-gui.exe program I got from somewhere, and my spot checks show identical decompiled source.
If this process was run for each library jar needed, then either the mac or windows jre embedding would be a lot smaller. I made a copy of rt.jar to original-rt.jar before I started, but that was just because I was experimenting.
I still have a strong need for coordinated server-desktop-android updates, and having applications that are not self-updateable are crap. If there is not something which ruins this, I could refactor an internal process for a SSL android stub - impl setup to work for desktop too. The stub application brings down new implementation code at launch if needed,.
Are there any known downsides to doing whatever I did to library jars? If not, maybe Oracle should think about just doing "this" to their distributions to begin with, unless they get bandwidth for free.
Thanks,
Jeff Palmer
WhatIf Squared LLC
More information about the macosx-port-dev
mailing list