Java的库组织方式就是“动态链接”的,从一个Java的jar包运行有可能要接一堆classpath就知道。和基于静态链接的C语言要实现动态链接要做额外的事情相似,Java要想实现类似C的静态链接也要做很多额外的事。
用类似Fat Jar的方法,把所有的依赖库打包的最后的库中,其实不是静态链接——C的静态链接只把需要的代码复制过来,不是眉毛胡子一把抓。按说,以Java的思想,静态链接不是很必要,因此也就没有原生支持。但实践和理论毕竟差距很远,不是每个库都是标准库,假设你从别人的库中引用了几个类,为了支持你的程序,你必须提供别人的库(假设这个库并不流行)。再假设你自己写了一个库,以后再开发类似的程序就从库中派生,当然你不想把所有的代码都发行出去。这个问题在Netbeans上更为明显,Netbeans提供了一个swing框架,用起来当然很方便,但是当发行程序的时候你就会发现,Netbeans很负责任的把依赖库放到发行目录的lib下,居然有将近1M,(禁掉粗口),光写一个窗口就要1M!
ProGuard不光是个混淆器,它也能解决静态链接的问题,用它自己的话说是 It detects and removes unused classes, fields, methods, and attributes.下面给出的是在Netbeans中用的Ant脚本,修改项目的build.xml,添加:
<
target
name
=
"-post-jar"
>
<
taskdef
resource
=
"proguard/ant/task.properties"
classpath
=
"${libs.proguard.classpath}"
/>
<
copyfile
src
=
"${dist.jar}"
dest
=
"${dist.dir}/pre.jar"
/>
<
proguard
warn
=
"false"
obfuscate
=
"false"
>
<
libraryjar
path
=
"${java.home}/lib/rt.jar"
/>
<
injar
path
=
"${javac.classpath}"
filter
=
"!META-INF/MANIFEST.MF"
/>
<
injar
path
=
"${dist.dir}/pre.jar"
/>
<
outjar
path
=
"${dist.jar}"
/>
<
keep
name
=
"${main.class}"
>
<
method
name
=
"main"
/>
keep
>
<
keep
name
=
"org.jdesktop.beansbinding.ext.BeanAdapterProvider"
/>
<
keepclasseswithmembernames
>
<
method
name
=
"getServiceNames"
/>
keepclasseswithmembernames
>
<
keepclasseswithmembernames
>
<
method
name
=
"addPropertyChangeListener"
/>
keepclasseswithmembernames
>
proguard
>
target
>
Netbeans自带ProGuard混淆器,libs.proguard.classpath就是ProGuard的位置。关掉了警告,因为我的应用共享了J2ME的库。关掉了混淆,这样更能看出去掉了哪些类。后面的keep只要看着ProGuard的提示加就可以了——既然是一一对应的解决方案,为什么ProGuard不提供个自动选项,期望能早日加上。