(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.-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. Common examples are the classes
    javax.swing.TransferHandler$HasGetTransferHandler and
    java.util.zip.ZipConstants, which are used as interfaces in
    some public classes, even though they are only package visible. This
    option is not set by default for reasons of efficiency. Setting it increases
    the processing time a bit, but it won't hurt the output in any way.
    
    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.
    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.
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.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.
LocalVariableTable or LocalVariableTypeTable
    attributes.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 isn't detecting this (yet), you have to keep the missing
    method in using the appropriate -keep option, e.g. "-keep
    class mypackage.MyClass { void myMethod(); }".-adaptresourcefilenames
    and/or -adaptresourcefilecontents.
    
    Furthermore, directory entries in jar files aren't copied, unless you
    specify the option -keepdirectories.
-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,-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.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.