It's the first time I've used ProGuard. I'm using Windows
2000 with Sun JDK 1.4.1_02 and ProGuard 1.7.2. Below
is a transcript of what happens. In addition to the
system not finding the standard java.util.zip.ZipEntry,
ProGuard throws an NPE.
The problem occurs even when the compiler is told to
generate bytecode for JVM 1.2.
The jar being processed (Zipper_noobf.jar) is
successfully processed using RetroGuard and yguard, so
there is nothing odd about it from the point of view of
an obfuscator.
G:\Projects\Zipper>java -jar "\proguard1.7.2
\lib\proguard.jar" -ignorewarnings -verbose @Zipper.pro
ProGuard, version 1.7
Reading jars...
Reading program jar [Zipper_noobf.jar]
Reading library jar [C:\Program
Files\Java\j2re1.4.1_02/lib/rt.jar]
Warning: java.util.zip.ZipEntry: can't find superclass or
interface java.util.zi
p.ZipConstants
Warning: there were 1 unresolved references to
superclasses or interfaces.
You may need to specify additional library jars
(using '-libraryjars').
Removing unused library classes...
Original number of library classes: 5273
Final number of library classes: 60
Printing kept classes, fields, and methods...
com.rdc.zipper.Zipper
com.rdc.zipper.Zipper: void main(java.lang.String[])
com.rdc.zipper.swing.ZipperGUI
com.rdc.zipper.swing.ZipperGUI: void main
(java.lang.String[])
Shrinking...
Removing unused program classes and class elements...
Original number of program classes: 114
Final number of program classes: 112
Obfuscating...
java.lang.NullPointerException
at
proguard.classfile.visitor.ClassFileUpDownTraveler.visitLibr
aryClassFile(ClassFileUpDownTraveler.java:173)
at proguard.classfile.LibraryClassFile.accept
(LibraryClassFile.java:387)
at
proguard.classfile.visitor.ClassFileUpDownTraveler.visitCla
ssCpInfo(ClassFileUpDownTraveler.java:212)
at proguard.classfile.ClassCpInfo.accept
(ClassCpInfo.java:98)
at
proguard.classfile.ProgramClassFile.constantPoolEntryAcc
ept(ProgramClassFile.java:371)
at
proguard.classfile.visitor.ClassFileUpDownTraveler.visitPro
gramClassFile(ClassFileUpDownTraveler.java:118)
at proguard.classfile.ProgramClassFile.accept
(ProgramClassFile.java:355)
at
proguard.obfuscate.MemberInfoLinker.visitProgramClassFil
e(MemberInfoLinker.java:56)
at
proguard.classfile.visitor.BottomClassFileFilter.visitProgra
mClassFile(BottomClassFileFilter.java:56)
at proguard.classfile.ProgramClassFile.accept
(ProgramClassFile.java:355)
at proguard.classfile.ClassPool.classFilesAccept
(ClassPool.java:116)
at proguard.ProGuard.obfuscate
(ProGuard.java:385)
at proguard.ProGuard.execute(ProGuard.java:586)
at proguard.ProGuard.main(ProGuard.java:625)
Logged In: YES
user_id=308438
I forgot to mention - the configuration is the standard
applications.pro file which ships with ProGuard.
Logged In: YES
user_id=555208
You must be using the -ignorewarnings option,
since you get a warning, but processing continues.
As mentioned in the manual, all bets are off with
this option!
In this case, the solution should be simple.
Use the -dontskipnonpubliclibraryclasses option,
so ProGuard will not skip the ZipConstants class.
It's package visible, but some public java run-time
classes extend it anyway. The warning will go away,
and ProGuard will not get lost when it tries to
access the class.
Logged In: YES
user_id=308438
Thanks for the suggestion, it worked.
Since rt.jar causes the problem, might I suggest that the
-dontskipnonpubliclibraryclasses option be made a default in
the .pro files shipped in the standard distribution? There might
be other classes in rt.jar which give rise to the same problem.
Or at least it could be added as a comment in the .pro files...
Logged In: YES
user_id=555208
The problem has been fixed for the upcoming version 2.0.
Incorrectly using the -ignorewarnings option no longer
causes a NullPointerException. For package-visible
library classes (like ZipConstants) that don't affect the
class hierarchy in any fundamental way, the
-ignorewarnings option is thus allowable instead of the
-dontskipnonpubliclibraryclasses option.