(MyClass)Class.forName(variable).newInstance()
".
Depending on your application, you may need to keep the mentioned classes
with an option like "-keep class MyClass
", or their
implementations with an option like "-keep class * implements
MyClass
". You can switch off these notes by specifying the
-dontnote
option.-dontnote
option.WEB-INF/classes
directory in a war should be packaged
in a jar and put in the WEB-INF/lib
directory. You can switch
off these notes by specifying the -dontnote
option.ProGuard may terminate when it encounters parsing errors or I/O errors, or some more serious warnings:
-libraryjars
option.
If the class that is reported as missing is a non-public library class,
you should specify the -dontskipnonpubliclibraryclasses
option. A common example is the class
java.util.zip.ZipConstants
, which is used as an interface
class in some public classes, even though it is only package visible (in
this case, the warning could also be ignored, because the class is not a
fundamental part of the class hierarchNotably,
class files that are in the WEB-INF/classes
directory in a
war should be packaged in a jar and put in the WEB-INF/lib
directory.y).
If you're missing a library and you're absolutely sure it isn't used
anyway, you can try your luck with the -ignorewarnings
option, or even the -dontwarn
option.
If the class member that is reported as missing is actually implemented in
a non-public library class, you should specify the
-dontskipnonpubliclibraryclasses
option. A common example is
the method setLength(int)
in the public class
java.lang.StringBuilder
. This method is actually defined in
the package visible superclass
java.lang.AbstractStringBuilder
, which ProGuard ignores by
default.
If your program classes reside in the same packages as library classes,
and refer to their package visible class members, then you should specify
the -dontskipnonpubliclibraryclassmembers
option.
-keep
options, or you mistyped
the class names. ProGuard has to know exactly what you want to keep: an
application, an applet, a servlet, a midlet,..., or any combination of
these. Without the proper seed specifications, ProGuard would shrink,
optimize, or obfuscate all class files away.Should ProGuard crash while processing your application:
-Xms
and -Xmx
options). You can also
reduce the amount of memory that ProGuard needs by removing unnecessary
library jars from your configuration, or by filtering out unused library
packages and classes. Remember that only classes or interfaces that are
extended or implemented by classes in your input jars are required.-Xss
option). This error also seems to occur
occasionally when optimizing complex methods on Windows (surprisingly, not
on Linux). You can then work around it by using ProGuard's
-dontoptimize
option.preverify
tool always unpacks the jars, so class files with
similar lower-case and upper-case names overwrite each other. You can use
ProGuard's -dontusemixedcaseclassnames
option to work around
this problem.-dontusemixedcaseclassnames
option.
Also, you should make sure your class files are in directories that
correspond to their package names. ProGuard will read misplaced class
files, but it will currently not write their processed versions. Notably,
class files that are in the WEB-INF/classes
directory in a
war should be packaged in a jar and put in the WEB-INF/lib
directory.
-printseeds
option to see which elements are being kept
exactly.Class.forName
, trying to create
the missing class dynamically. ProGuard can only detect constant name
arguments, like Class.forName("mypackage.MyClass")
. For
variable name arguments like Class.forName(someClass)
, you
have to keep all possible classes using the -keep
option,
e.g. "-keep class mypackage.MyClass
" or "-keep class *
implements mypackage.MyInterface
".myClass.getMethod
, trying to find some method dynamically.
Since ProGuard isn't detecting this (yet), you have to keep the missing
method in using the -keep
option, e.g. "-keep class
mypackage.MyClass { void myMethod(); }
".-defaultpackage
option, the package names of some classes may
have changed, and along with them, the directory in which they look for
their resource files. It's better not to use this option in these
circumstances.-dontusemixedcaseclassnames
option. Even if it has been
properly processed and then preverified on a case-sensitive file system,
the device itself might not like the mixed-case class names. Notably, the
Nokia N-Gage emulator works fine, but the actual device seems to exhibit
this problem.values()
method of the enumeration type, as
shown in the examples.proguard/wtk/default.pro
that's inside the
proguard.jar
.-overloadaggressively
option. This option triggers a
bug in sun.tools.java.MethodSet.add
in Sun's JDK 1.2.2, which
is used for (dynamic) compilation. You should then not use this
option.-overloadaggressively
option. You should then use the
same option again in the second processing round.Furthermore, you should check whether you have specified your program jars and library jars properly. Program classes can refer to library classes, but not the other way around.
If all of this seems ok, perhaps there's a bug in ProGuard (gasp!). If so, please report it, preferably with the simplest example on which you can find ProGuard to fail.
-dontoptimize
option. Please report it, preferably
with the simplest example on which you can find ProGuard to fail.