(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..getField("myField")". Depending on your application, you
may need to figure out where the mentioned class members are defined and
keep them with an option like "-keep class MyClass { MyFieldType
myField; }". Otherwise, ProGuard might remove or obfuscate the
class members, since it can't know which ones they are exactly. It does
list possible candidates, for your information. You can switch off these
notes by specifying the -dontnote option.-keep option to preserve the
given method (or field), but no -keep option for the given
class that is an argument type or return type in the method's descriptor.
You may then want to keep the class too. Otherwise, ProGuard will
obfuscate its name, thus changing the method's signature. The method might
then become unfindable as an entry point, e.g. if it is part of a public
API. You can switch off these notes by specifying the -dontnote option.-keepclassmembers/-keepclasseswithmembers option to
preserve fields or methods in the given class, but it doesn't specify
which fields or methods. This way, the option simply won't have any
effect. You probably want to specify one or more fields or methods, as
usual between curly braces. You can specify all fields or methods with a
wildcard "*;". You can switch off these notes by specifying
the -dontnote option.-dontnote option.ProGuard may terminate when it encounters parsing errors or I/O errors, or some more serious warnings:
-libraryjars option.
For example, if ProGuard complains that it can't find a
javax.crypto class, you probably still have to specify
jce.jar, next to the more common rt.jar.
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. Only use these options if you really know what you're doing
though.
For example, if you're developing for Android, and ProGuard complains that
it can't find a java.awt class, then some library that you
are using is referring to java.awt. This is a bit shady, since
Android doesn't have this package at all, but if your application works
anyway, you can let ProGuard accept it with "-dontwarn
java.awt.**".
-ignorewarnings
or -dontwarn, but it didn't
work out. ProGuard's optimization step and preverification step really
need the missing classes to make sense of the code. Preferably, you would
solve the problem by adding the missing library, as discussed. If you're
sure the class that references the missing class isn't used either, you
could also try filtering it out from the input, by adding a filter to the
corresponding -injars option:
"-injars
myapplication.jar(!somepackage/SomeUnusedClass.class)". Hopefully,
you can access the configuration of your build process for such a
modification. As a final solution, you could switch off optimization
(-dontoptimize) and
preverification
(-dontpreverify).
If your program classes reside in the same packages as library classes,
and refer to their package visible class members, then you should also
specify the
-dontskipnonpubliclibraryclassmembers
option.
-injars) and library code
(specified with -libraryjars), and try
again.WEB-INF/classes directory in a war should be packaged
in a jar and put in the WEB-INF/lib directory. If you don't
mind these classes not being written to the output, you can specify the -ignorewarnings option,
or even the -dontwarn
option.-keep option in the
configuration, and the mapping file, in the obfuscation step. The given
class name or class member name can't be kept by its original name, as
specified in the configuration, but it has to be mapped to the other given
name, as specified in the mapping file. You should adapt your
configuration or your mapping file to remove the conflict. Alternatively,
if you're sure the renaming won't hurt, you can specify the -ignorewarnings option,
or even the -dontwarn
option.-ignorewarnings option,
or even the -dontwarn
option. Note that you should always use the -useuniqueclassmembernames
option in the initial obfuscation step, in order to reduce the risk of
conflicts.-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.<java.home>/lib/rt.jar by
<java.home>/../Classes/classes.jar.-DsuppressSwingDropSupport=true when running the
GUI.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)
should help too. In practice however, the -Xss setting
doesn't have any effect on the main thread, due to Sun Bug
#4362291. As a result, this solution will only work when running
ProGuard in a different thread, e.g. from its GUI.-dontoptimize option. In
any case, please report the problem, preferably with the simplest example
that causes ProGuard to crash.
-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.
If you are using marker interfaces to keep other classes, the marker
interfaces themselves are probably being removed in the shrinking step.
You should therefore always explicitly keep any marker interfaces, with
an option like "-keep interface MyMarkerInterface".
Similarly, if you are keeping classes based on annotations, you may have to
avoid that the annotation classes themselves are removed in the shrinking
step. You can explicitly keep all annotation classes in your program code
with an option like "-keep @interface *".
LocalVariableTable or LocalVariableTypeTable
attributes.-g:none), or let
ProGuard's obfuscation step remove the debug information again
(by not keeping the attributes LocalVariableTable
and LocalVariableTypeTable
with -keepattributes),
or otherwise just disable optimization
(-dontoptimize).android-sdk/tools/proguard/lib. If that doesn't help,
please report the problem, preferably with the simplest example that still
brings out the error.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.
If the above doesn't help, there is probably a bug in the optimization
step of ProGuard. Make sure you are using the latest version. You should
be able to work around the problem by using the -dontoptimize option. You
can check the bug database to see if it is a known problem (often with a
fix). Otherwise, please report it, preferably with the simplest example on
which you can find ProGuard to fail.
-microedition option,
ProGuard will preverify the class files for Java Micro Edition.
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 appropriate -keep option, e.g. "-keep
class mypackage.MyClass" or "-keep class * implements
mypackage.MyInterface".myClass.getMethod, trying to find some method dynamically.
Since ProGuard can't always detect this automatically, you have to keep
the missing method in using the appropriate -keep option, e.g. "-keep
class mypackage.MyClass { void myMethod(); }".
More specifically, if the method reported as missing is
values or valueOf, you probably have to keep
some methods related to enumerations.
-adaptresourcefilenames
and/or -adaptresourcefilecontents.
Furthermore, directory entries in jar files aren't copied, unless you
specify the option -keepdirectories.
Note that Sun advises against calling Class.getResource() for
directories (Sun
Bug #4761949).
-keepattributes
*Annotation*.-jar instead of the option -classpath. The java
virtual machine returns with this error message if your jar doesn't
contain a manifest file (META-INF/MANIFEST.MF), if the
manifest file doesn't specify a main class (Main-Class: ...),
or if the jar doesn't contain this main class. You should then make sure
that the input jar contains a valid manifest file to start with, that this
manifest file is the one that is copied (the first manifest file that is
encountered), and that the main class is kept in your configuration,META-INF/INDEX.LIST, listing all class files in the jar.
ProGuard by default copies files like these unchanged. ProGuard may however
remove or rename classes, thus invalidating the file. You should filter the
index file out of the input
(-injars in.jar(!META-INF/INDEX.LIST)) or update the file
after having applied ProGuard (jar -i out.jar).
-microedition option, so
the processed class files are preverified properly.-repackageclasses
'' and -overloadaggressively.
If you're using the JME WTK plugin, you can adapt the configuration
proguard/wtk/default.pro that's inside the
proguard.jar.-useuniqueclassmembernames
option. It avoids overloading class member names, which triggers a bug in
their java virtual machine.
You might also try using the -dontusemixedcaseclassnames
option. Even if the midlet 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.
volatile. If this is not
possible for some reason, you'll have to switch off optimization using the
-dontoptimize
option.-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 avoid this option.-overloadaggressively
option. You should then use the same option again in the second processing
round.LocalVariableTable or
LocalVariableTypeTable attributes, ProGuard's optimizing step
is sometimes unable to update them consistently. You should then let the
obfuscation step remove these attributes or disable the optimization
step.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. You can check the bug database to see if it is a known problem
(often with a fix). Otherwise, please report it, preferably with the
simplest example on which ProGuard fails.