Home | History | Annotate | Download | only in manual
      1 <!doctype html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
      2 <html>
      3 <head>
      4 <meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
      5 <meta http-equiv="content-style-type" content="text/css">
      6 <link rel="stylesheet" type="text/css" href="style.css">
      7 <title>ProGuard Troubleshooting</title>
      8 <script type="text/javascript" language="JavaScript">
      9 <!--
     10 if (window.self==window.top)
     11   window.top.location.replace("../index.html#"+window.location.pathname+window.location.hash);
     12 else {
     13   var hash="#"+window.location.pathname.replace(window.top.location.pathname.replace("index.html", ""), "");
     14   if (window.top.location.hash!=hash)
     15     window.top.location.hash=hash;
     16 }
     17 //-->
     18 </script>
     19 </head>
     20 <body>
     21 
     22 <h2>Troubleshooting</h2>
     23 
     24 While preparing a configuration for processing your code, you may bump into a
     25 few problems. The following sections discuss some common issues and solutions:
     26 
     27 <h3><a href="#processing">Problems while processing</a></h3>
     28 <ul>
     29 <li><a href="#dynamicalclass">Note: can't find dynamically referenced class ...</a></li>
     30 <li><a href="#dynamicalclasscast">Note: ... calls '(...)Class.forName(variable).newInstance()'</a></li>
     31 <li><a href="#dynamicalclassmember">Note: ... accesses a field/method '...' dynamically</a></li>
     32 <li><a href="#unknownclass">Note: the configuration refers to the unknown class  '...'</a></li>
     33 <li><a href="#descriptorclass">Note: the configuration keeps the entry point '...', but not the descriptor class '...'</a></li>
     34 <li><a href="#classmembers">Note: the configuration doesn't specify which class members to keep for class '...'</a></li>
     35 <li><a href="#duplicateclass">Note: duplicate definition of program/library class</a></li>
     36 <li><a href="#duplicatezipentry">Warning: can't write resource ... Duplicate zip entry</a></li>
     37 <li><a href="#unresolvedclass">Warning: can't find superclass or interface</a></li>
     38 <li><a href="#unresolvedclass">Warning: can't find referenced class</a></li>
     39 <li><a href="#superclass">Error: Can't find any super classes of ... (not even immediate super class ...)</a></li>
     40 <li><a href="#superclass">Error: Can't find common super class of ... and ...</a></li>
     41 <li><a href="#unresolvedprogramclassmember">Warning: can't find referenced field/method '...' in program class ...</a></li>
     42 <li><a href="#unresolvedlibraryclassmember">Warning: can't find referenced field/method '...' in library class ...</a></li>
     43 <li><a href="#unresolvedenclosingmethod">Warning: can't find enclosing class/method</a></li>
     44 <li><a href="#dependency">Warning: library class ... depends on program class ...</a></li>
     45 <li><a href="#unexpectedclass">Warning: class file ... unexpectedly contains class ...</a></li>
     46 <li><a href="#mappingconflict1">Warning: ... is not being kept as ..., but remapped to ...</a></li>
     47 <li><a href="#mappingconflict2">Warning: field/method ... can't be mapped to ...</a></li>
     48 <li><a href="#unsupportedclassversion">Error: Unsupported class version number</a></li>
     49 <li><a href="#keep">Error: You have to specify '-keep' options</a></li>
     50 <li><a href="#filename">Error: Expecting class path separator ';' before 'Files\Java\...' (in Windows)</a></li>
     51 <li><a href="#macosx">Error: Can't read [.../lib/rt.jar] (No such file or directory) (in MacOS X)</a></li>
     52 <li><a href="#cantread">Error: Can't read ...</a></li>
     53 <li><a href="#cantwrite">Error: Can't write ...</a></li>
     54 <li><a href="#startinggui">Internal problem starting the ProGuard GUI (Cannot write XdndAware property) (in Linux)</a></li>
     55 <li><a href="#outofmemoryerror">OutOfMemoryError</a></li>
     56 <li><a href="#stackoverflowerror">StackOverflowError</a></li>
     57 <li><a href="#unexpectederror">Unexpected error</a></li>
     58 <li><a href="#otherwise">Otherwise...</a></li>
     59 </ul>
     60 
     61 <h3><a href="#afterprocessing">Unexpected observations after processing</a></h3>
     62 <ul>
     63 <li><a href="#disappearingclasses">Disappearing classes</a></li>
     64 <li><a href="#notkept">Classes or class members not being kept</a></li>
     65 <li><a href="#notobfuscated">Variable names not being obfuscated</a></li>
     66 </ul>
     67 
     68 <h3><a href="#dalvik">Problems while converting to Android Dalvik bytecode</a></h3>
     69 
     70 <ul>
     71 <li><a href="#simexception">SimException: local variable type mismatch</a></li>
     72 <li><a href="#conversionerror">Conversion to Dalvik format failed with error 1</a></li>
     73 </ul>
     74 
     75 <h3><a href="#preverifying">Problems while preverifying for Java Micro Edition</a></h3>
     76 
     77 <ul>
     78 <li><a href="#invalidclassexception1">InvalidClassException, class loading error, or verification error</a></li>
     79 </ul>
     80 
     81 <h3><a href="#runtime">Problems at run-time</a></h3>
     82 <ul>
     83 <li><a href="#stacktraces">Stack traces without class names or line numbers</a></li>
     84 <li><a href="#noclassdeffounderror">NoClassDefFoundError</a></li>
     85 <li><a href="#classnotfoundexception">ClassNotFoundException</a></li>
     86 <li><a href="#nosuchfieldexception">NoSuchFieldException</a></li>
     87 <li><a href="#nosuchmethodexception">NoSuchMethodException</a></li>
     88 <li><a href="#missingresourceexception">MissingResourceException or NullPointerException</a></li>
     89 <li><a href="#disappearingannotations">Disappearing annotations</a></li>
     90 <li><a href="#invalidjarfile">Invalid or corrupt jarfile</a></li>
     91 <li><a href="#invalidjarindexexception">InvalidJarIndexException: Invalid index</a></li>
     92 <li><a href="#invalidclassexception2">InvalidClassException, class loading error, or verification error (in Java Micro Edition)</a></li>
     93 <li><a href="#nosuchfieldormethod">Error: No Such Field or Method, Error verifying method (in a Java Micro Edition emulator)</a></li>
     94 <li><a href="#failingmidlets">Failing midlets (on a Java Micro Edition device)</a></li>
     95 <li><a href="#disappearingloops">Disappearing loops</a></li>
     96 <li><a href="#securityexception">SecurityException: SHA1 digest error</a></li>
     97 <li><a href="#classcastexception">ClassCastException: class not an enum</a></li><li><a href="#classcastexception">IllegalArgumentException: class not an enum type</a></li>
     98 <li><a href="#arraystoreexception">ArrayStoreException: sun.reflect.annotation.EnumConstantNotPresentExceptionProxy</a></li>
     99 <li><a href="#compilererror">CompilerError: duplicate addition</a></li>
    100 <li><a href="#classformaterror1">ClassFormatError: repetitive field name/signature</a></li>
    101 <li><a href="#classformaterror2">ClassFormatError: Invalid index in LocalVariableTable in class file</a></li>
    102 <li><a href="#nosuchmethoderror">NoSuchMethodError or AbstractMethodError</a></li>
    103 <li><a href="#verifyerror">VerifyError</a></li>
    104 </ul>
    105 
    106 
    107 <h2><a name="processing">Problems while processing</a></h2>
    108 
    109 ProGuard may print out some notes and non-fatal warnings:
    110 
    111 <dl>
    112 <dt><a name="dynamicalclass"><b>Note: can't find dynamically referenced class ...</b></a></dt>
    113 
    114 <dd>ProGuard can't find a class or interface that your code is accessing by
    115     means of introspection. You should consider adding the jar that contains
    116     this class.</dd>
    117 
    118 <dt><a name="dynamicalclasscast"><b>Note: ... calls '(...)Class.forName(variable).newInstance()'</b></a></dt>
    119 
    120 <dd>ProGuard lists all class casts of dynamically created class instances,
    121     like "<code>(MyClass)Class.forName(variable).newInstance()</code>".
    122     Depending on your application, you may need to keep the mentioned classes
    123     with an option like "<code>-keep class MyClass</code>", or their
    124     implementations with an option like "<code>-keep class * implements
    125     MyClass</code>". You can switch off these notes by specifying the
    126     <a href="usage.html#dontnote"><code>-dontnote</code></a> option.</dd>
    127 
    128 <dt><a name="dynamicalclassmember"><b>Note: ... accesses a field/method '...' dynamically</b></a></dt>
    129 
    130 <dd>ProGuard lists a number of constructs like
    131     "<code>.getField("myField")</code>". Depending on your application, you
    132     may need to figure out where the mentioned class members are defined and
    133     keep them with an option like "<code>-keep class MyClass { MyFieldType
    134     myField; }</code>". Otherwise, ProGuard might remove or obfuscate the
    135     class members, since it can't know which ones they are exactly. It does
    136     list possible candidates, for your information. You can switch off these
    137     notes by specifying the <a
    138     href="usage.html#dontnote"><code>-dontnote</code></a> option.</dd>
    139 
    140 <dt><a name="unknownclass"><b>Note: the configuration refers to the unknown class  '...'</b></a></dt>
    141 
    142 <dd>Your configuration refers to the name of a class that is not present in
    143     the program jars or library jars. You should check whether the name is
    144     correct. Notably, you should make sure that you always specify
    145     fully-qualified names, not forgetting the package names.</dd>
    146 
    147 <dt><a name="descriptorclass"><b>Note: the configuration keeps the entry point '...', but not the descriptor class '...'</b></a></dt>
    148 
    149 <dd>Your configuration contains a <code>-keep</code> option to preserve the
    150     given method (or field), but no <code>-keep</code> option for the given
    151     class that is an argument type or return type in the method's descriptor.
    152     You may then want to keep the class too. Otherwise, ProGuard will
    153     obfuscate its name, thus changing the method's signature. The method might
    154     then become unfindable as an entry point, e.g. if it is part of a public
    155     API. You can switch off these notes by specifying the <a
    156     href="usage.html#dontnote"><code>-dontnote</code></a> option.</dd>
    157 
    158 <dt><a name="classmembers"><b>Note: the configuration doesn't specify which class members to keep for class '...'</b></a></dt>
    159 
    160 <dd>Your configuration contains
    161     a <a href="usage.html#keepclassmembers"><code>-keepclassmembers</code></a>/<a href="usage.html#keepclasseswithmembers">-keepclasseswithmembers</code></a>
    162     option to preserve fields or methods in the given class, but it doesn't
    163     specify which fields or methods. This way, the option simply won't have
    164     any effect. You probably want to specify one or more fields or methods, as
    165     usual between curly braces. You can specify all fields or methods with a
    166     wildcard "<code>*;</code>". You should also consider if you just need the
    167     more common <a href="usage.html#keep"><code>-keep</code></a> option, which
    168     preserves all specified classes <i>and</i> class members.
    169     The <a href="usage.html#keepoverview">overview of all <code>keep</code>
    170     options</a> can help. You can switch off these notes by specifying
    171     the <a href="usage.html#dontnote"><code>-dontnote</code></a> option.</dd>
    172 
    173 <dt><a name="duplicateclass"><b>Note: duplicate definition of program/library class</b></a></dt>
    174 
    175 <dd>Your program jars or library jars contain multiple definitions of the
    176     listed classes. ProGuard continues processing as usual, only considering
    177     the first definitions. The warning may be an indication of some problem
    178     though, so it's advisable to remove the duplicates. A convenient way to do
    179     so is by specifying filters on the input jars or library jars. You can
    180     switch off these notes by specifying the <a
    181     href="usage.html#dontnote"><code>-dontnote</code></a> option.
    182     <p>
    183     <img class="float" src="android_small.png" width="32" height="32"
    184     alt="android" /> The standard Android build process automatically
    185     specifies the input jars for you. There may not be an easy way to filter
    186     them to remove these notes. You could remove the duplicate classes
    187     manually from your libraries. You should never explicitly specify the
    188     input jars yourself (with <code>-injars</code> or
    189     <code>-libraryjars</code>), since you'll then get duplicate definitions.
    190     You should also not add libraries to your application that are already
    191     part of the Android run-time (notably <code>org.w3c.dom</code>,
    192     <code>org.xml.sax</code>, <code>org.xmlpull.v1</code>,
    193     <code>org.apache.commons.logging.Log</code>, <code>org.apache.http</code>,
    194     and <code>org.json</code>). They are possibly inconsistent, and the
    195     run-time libraries would get precedence anyway.</dd>
    196 
    197 <dt><a name="duplicatezipentry"><b>Warning: can't write resource ... Duplicate zip entry</b></a></dt>
    198 
    199 <dd>Your input jars contain multiple resource files with the same name.
    200     ProGuard continues copying the resource files as usual, skipping any files
    201     with previously used names. Once more, the warning may be an indication of
    202     some problem though, so it's advisable to remove the duplicates. A
    203     convenient way to do so is by specifying filters on the input jars. There
    204     is no option to switch off these warnings.
    205     <p>
    206     <img class="float" src="android_small.png" width="32" height="32"
    207     alt="android" /> The standard Android build process automatically
    208     specifies the input jars for you. There may not be an easy way to filter
    209     them to remove these warnings. You could remove the duplicate resource files
    210     manually from the input and the libraries.</dd>
    211 
    212 </dl>
    213 <p>
    214 
    215 ProGuard may terminate when it encounters parsing errors or I/O errors, or
    216 some more serious warnings:
    217 
    218 <dl>
    219 <dt><a name="unresolvedclass"><b>Warning: can't find superclass or interface</b><br/><b>Warning: can't find referenced class</b></a></dt>
    220 
    221 <dd>A class in one of your program jars or library jars is referring to a
    222     class or interface that is missing from the input. The warning lists both
    223     the referencing class(es) and the missing referenced class(es). There can
    224     be a few reasons, with their own solutions:
    225     <p>
    226     <ol>
    227     <li>If the missing class is referenced from your own code, you may have
    228         forgotten to specify an essential library. Just like when compiling
    229         all code from scratch, you must specify all libraries that the code is
    230         referencing, directly or indirectly. If the library should be
    231         processed and included in the output, you should specify it with
    232         <a href="usage.html#injars"><code>-injars</code></a>, otherwise you
    233         should specify it with
    234         <a href="usage.html#libraryjars"><code>-libraryjars</code></a>.
    235         <p>
    236         For example, if ProGuard complains that it can't find a
    237         <code>java.lang</code> class, you have to make sure that you are
    238         specifying the run-time library of your platform. For JSE, these are
    239         typically packaged in <code>lib/rt.jar</code> (<code>vm.jar</code> for
    240         IBM's JVM, and <code>classes.jar</code> in MacOS X). Other platforms
    241         like JME and Android have their own run-time libraries.
    242         The <a href="examples.html">examples section</a> provides more details
    243         for the various platforms.
    244         <p>
    245         If ProGuard still complains that it can't find a
    246         <code>javax.crypto</code> class, you probably still have to specify
    247         <code>jce.jar</code>, next to the more common <code>rt.jar</code>.</li>
    248     <li>If the missing class is referenced from a pre-compiled third-party
    249         library, and your original code runs fine without it, then the missing
    250         dependency doesn't seem to hurt. The cleanest solution is to
    251         <a href="usage.html#filters">filter out</a> the <i>referencing</i>
    252         class or classes from the input, with a filter like "<code>-libraryjars
    253         mylibrary.jar(!somepackage/SomeUnusedReferencingClass.class)</code>".
    254         ProGuard will then skip this class entirely in the input, and it will
    255         not bump into the problem of its missing reference. However, you may
    256         then have to filter out other classes that are in turn referencing the
    257         removed class. In practice, this works best if you can filter out
    258         entire unused packages at once, with a wildcard filter like
    259         "<code>-libraryjars
    260         mylibrary.jar(!someunusedpackage/**)</code>".<p></li>
    261     <li>If you don't feel like filtering out the problematic classes, you can
    262         try your luck with the <a
    263         href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a>
    264         option, or even
    265         the <a href="usage.html#dontwarn"><code>-dontwarn</code></a> option.
    266         Only use these options if you really know what you're doing though.</li>
    267     </ol>
    268     <p>
    269     <img class="float" src="android_small.png" width="32" height="32"
    270     alt="android" /> The standard Android build process automatically
    271     specifies the input jars for you. Unfortunately, many pre-compiled
    272     third-party libraries refer to other libraries that are not actually used
    273     and therefore not present. This works fine in debug builds, but in release
    274     builds, ProGuard expects all libraries, so it can perform a proper static
    275     analysis. For example, if ProGuard complains that it can't find
    276     a <code>java.awt</code> class, then some library that you are using is
    277     referring to <code>java.awt</code>. This is a bit shady, since Android
    278     doesn't have this package at all, but if your application works anyway,
    279     you can let ProGuard accept it with "<code>-dontwarn java.awt.**</code>",
    280     for instance.</dd>
    281 
    282 <dt><a name="superclass"><b>Error: Can't find any super classes of ... (not even immediate super class ...)</b><br/><b>Error: Can't find common super class of ... and ...</b></a></dt>
    283 
    284 <dd>It seems like you tried to avoid the warnings from the previous paragraph
    285     by specifying
    286     <a href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a>
    287     or <a href="usage.html#dontwarn"><code>-dontwarn</code></a>, but it didn't
    288     work out. ProGuard's optimization step and preverification step really
    289     need the missing classes to make sense of the code. Preferably, you would
    290     solve the problem by adding the missing library, as discussed. If you're
    291     sure the class that references the missing class isn't used either, you
    292     could also try filtering it out from the input, by adding a filter to the
    293     corresponding <a href="usage.html#injars"><code>-injars</code></a> option:
    294     "<code>-injars
    295     myapplication.jar(!somepackage/SomeUnusedClass.class)</code>". As a final
    296     solution, you could switch off optimization
    297     (<a href="usage.html#dontoptimize"><code>-dontoptimize</code></a>) and
    298     preverification
    299     (<a href="usage.html#dontpreverify"><code>-dontpreverify</code></a>).</dd>
    300 
    301 <dt><a name="unresolvedprogramclassmember"><b>Warning: can't find referenced field/method '...' in program class ...</b></a></dt>
    302 
    303 <dd>A program class is referring to a field or a method that is missing from
    304     another program class. The warning lists both the referencing class and
    305     the missing referenced class member. Your compiled class files are most
    306     likely inconsistent. Possibly, some class file didn't get recompiled
    307     properly, or some class file was left behind after its source file was
    308     removed. Try removing all compiled class files and rebuilding your
    309     project.</dd>
    310 
    311 <dt><a name="unresolvedlibraryclassmember"><b>Warning: can't find referenced field/method '...' in library class ...</b></a></dt>
    312 
    313 <dd>A program class is referring to a field or a method that is missing from a
    314     library class. The warning lists both the referencing class and the
    315     missing referenced class member. Your compiled class files are
    316     inconsistent with the libraries. You may need to recompile the class
    317     files, or otherwise upgrade the libraries to consistent versions.
    318     <p>
    319     <img class="float" src="android_small.png" width="32" height="32"
    320     alt="android" /> If you're developing for Android and ProGuard complains
    321     that it can't find a method that is only available in a recent version of
    322     the Android run-time, you should change the build target in your
    323     <code>project.properties</code> file or <code>build.gradle</code> file to
    324     that recent version. You can still specify a different
    325     <code>minSdkVersion</code> and a different <code>targetSdkVersion</code>
    326     in your <code>AndroidManifest.xml</code> file.
    327     <p>
    328     Alternatively, you may get away with ignoring the inconsistency with the
    329     options
    330     <a href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a> or
    331     even
    332     <a href="usage.html#dontwarn"><code>-dontwarn</code></a>. For instance, you
    333     can specify "<code>-dontwarn mypackage.MyInconsistentClass</code>".
    334     <p>
    335     Finally, should your program classes reside in the same packages as
    336     library classes and should they refer to their package visible class
    337     members, then you should also specify the
    338     <a href="usage.html#dontskipnonpubliclibraryclassmembers"><code>-dontskipnonpubliclibraryclassmembers</code></a>
    339     option.</dd>
    340 
    341 <dt><a name="unresolvedenclosingmethod"><b>Warning: can't find enclosing class/method</b></a></dt>
    342 
    343 <dd>If there are unresolved references to classes that are defined inside
    344     methods in your input, once more, your compiled class files are most likely
    345     inconsistent. Possibly, some class file didn't get recompiled properly, or
    346     some class file was left behind after its source file was removed. Try
    347     removing all compiled class files and rebuilding your project.</dd>
    348 
    349 <dt><a name="dependency"><b>Warning: library class ... depends on program class ...</b></a></dt>
    350 
    351 <dd>If any of your library classes depend on your program classes, by
    352     extending, implementing or just referencing them, your processed code will
    353     generally be unusable. Program classes can depend on library classes, but
    354     not the other way around. Program classes are processed, while library
    355     classes always remain unchanged. It is therefore impossible to adapt
    356     references from library classes to program classes, for instance if the
    357     program classes are renamed. You should define a clean separation between
    358     program code (specified with <a
    359     href="usage.html#injars"><code>-injars</code></a>) and library code
    360     (specified with <a
    361     href="usage.html#libraryjars"><code>-libraryjars</code></a>), and try
    362     again.
    363     <p>
    364     <img class="float" src="android_small.png" width="32" height="32"
    365     alt="android" /> In Android development, sloppy libraries may contain
    366     duplicates of classes that are already present in the Android run-time
    367     (notably <code>org.w3c.dom</code>, <code>org.xml.sax</code>,
    368     <code>org.xmlpull.v1</code>, <code>org.apache.commons.logging.Log</code>,
    369     <code>org.apache.http</code>, and <code>org.json</code>). You must remove
    370     these classes from your libraries, since they are possibly inconsistent,
    371     and the run-time libraries would get precedence anyway.</dd>
    372 
    373 <dt><a name="unexpectedclass"><b>Warning: class file ... unexpectedly contains class ...</b></a></dt>
    374 
    375 <dd>The given class file contains a definition for the given class, but the
    376     directory name of the file doesn't correspond to the package name of the
    377     class. ProGuard will accept the class definition, but the current
    378     implementation will not write out the processed version. Please make sure
    379     your input classes are packaged correctly. Notably, class files that are
    380     in the <code>WEB-INF/classes</code> directory in a war should be packaged
    381     in a jar and put in the <code>WEB-INF/lib</code> directory. If you don't
    382     mind these classes not being written to the output, you can specify the <a
    383     href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a> option,
    384     or even the <a href="usage.html#dontwarn"><code>-dontwarn</code></a>
    385     option.</dd>
    386 
    387 <dt><a name="mappingconflict1"><b>Warning: ... is not being kept as ..., but remapped to ...</b></a></dt>
    388 
    389 <dd>There is a conflict between a <code>-keep</code> option in the
    390     configuration, and the mapping file, in the obfuscation step. The given
    391     class name or class member name can't be kept by its original name, as
    392     specified in the configuration, but it has to be mapped to the other given
    393     name, as specified in the mapping file. You should adapt your
    394     configuration or your mapping file to remove the conflict. Alternatively,
    395     if you're sure the renaming won't hurt, you can specify the <a
    396     href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a> option,
    397     or even the <a href="usage.html#dontwarn"><code>-dontwarn</code></a>
    398     option.</dd>
    399 
    400 <dt><a name="mappingconflict2"><b>Warning: field/method ... can't be mapped to ...</b></a></dt>
    401 
    402 <dd>There is a conflict between some new program code and the mapping file, in
    403     the obfuscation step. The given class member can't be mapped to the given
    404     name, because it would conflict with another class member that is already
    405     being mapped to the same name. This can happen if you are performing
    406     incremental obfuscation, applying an obfuscation mapping file from an
    407     initial obfuscation step. For instance, some new class may have been added
    408     that extends two existing classes, introducing a conflict in the name
    409     space of its class members. If you're sure the class member receiving
    410     another name than the one specified won't hurt, you can specify the <a
    411     href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a> option,
    412     or even the <a href="usage.html#dontwarn"><code>-dontwarn</code></a>
    413     option. Note that you should always use the <a
    414     href="usage.html#useuniqueclassmembernames"><code>-useuniqueclassmembernames</code></a>
    415     option in the initial obfuscation step, in order to reduce the risk of
    416     conflicts.</dd>
    417 
    418 <dt><a name="unsupportedclassversion"><b>Error: Unsupported class version number</b></a></dt>
    419 
    420 <dd>You are trying to process class files compiled for a recent version of
    421     Java that your copy of ProGuard doesn't support yet. You
    422     should <a href="http://proguard.sourceforge.net/downloads.html">check
    423     on-line</a> if there is a more recent release.</dd>
    424 
    425 <dt><a name="keep"><b>Error: You have to specify '-keep' options</b></a></dt>
    426 
    427 <dd>You either forgot to specify <a
    428     href="usage.html#keep"><code>-keep</code></a> options, or you mistyped the
    429     class names. ProGuard has to know exactly what you want to keep: an
    430     application, an applet, a servlet, a midlet,..., or any combination of
    431     these. Without the proper seed specifications, ProGuard would shrink,
    432     optimize, or obfuscate all class files away.</dd>
    433 
    434 <dt><a name="filename"><b>Error: Expecting class path separator ';' before 'Files\Java\</b>...<b>'</b> (in Windows)</a></dt>
    435 
    436 <dd>If the path of your run-time jar contains spaces, like in "Program Files",
    437     you have to enclose it with single or double quotes, as explained in the
    438     section on <a href="usage.html#filename">file names</a>. This is actually
    439     true for all file names containing special characters, on all
    440     platforms.</dd>
    441 
    442 <dt><a name="macosx"><b>Error: Can't read [</b>...<b>/lib/rt.jar] (No such file or directory)</b> (in MacOS X)</a></dt>
    443 
    444 <dd>In MacOS X, the run-time classes may be in a different place than on most
    445     other platforms. You'll then have to adapt your configuration, replacing
    446     the path <code>&lt;java.home&gt;/lib/rt.jar</code> by
    447     <code>&lt;java.home&gt;/../Classes/classes.jar</code>.</dd>
    448 
    449 <dt><a name="cantread"><b>Error: Can't read ...</b></a></dt>
    450 
    451 <dd>ProGuard can't read the specified file or directory. Double-check that the
    452     name is correct in your configuration, that the file is readable, and that
    453     it is not corrupt. An additional message "Unexpected end of ZLIB input
    454     stream" suggests that the file is truncated. You should then make sure
    455     that the file is complete on disk when ProGuard starts (asynchronous
    456     copying? unflushed buffer or cache?), and that it is not somehow
    457     overwritten by ProGuard's own output.</dd>
    458 
    459 <dt><a name="cantwrite"><b>Error: Can't write ...</b></a></dt>
    460 
    461 <dd>ProGuard can't write the specified file or directory. Double-check that
    462     the name is correct in your configuration and that the file is
    463     writable.</dd>
    464 
    465 <dt><a name="startinggui"><b>Internal problem starting the ProGuard GUI (Cannot write XdndAware property)</b> (in Linux)</a></dt>
    466 
    467 <dd>In Linux, at least with Java 6, the GUI may not start properly, due to
    468     <a href="http://bugs.sun.com/view_bug.do?bug_id=7027598">Sun
    469     Bug #7027598</a>. The work-around at this time is to specify the JVM
    470    option <code>-DsuppressSwingDropSupport=true</code> when running the
    471    GUI.</dd>
    472 
    473 </dl>
    474 <p>
    475 
    476 Should ProGuard crash while processing your application:
    477 
    478 <dl>
    479 <dt><a name="outofmemoryerror"><b>OutOfMemoryError</b></a></dt>
    480 
    481 <dd>You can try increasing the heap size of the Java virtual machine (with the
    482     usual <code>-Xms</code> and <code>-Xmx</code> options). You can also
    483     reduce the amount of memory that ProGuard needs by removing unnecessary
    484     library jars from your configuration, or by filtering out unused library
    485     packages and classes. Remember that only classes or interfaces that are
    486     extended or implemented by classes in your input jars are required.</dd>
    487 
    488 <dt><a name="stackoverflowerror"><b>StackOverflowError</b></a></dt>
    489 
    490 <dd>This error might occur when processing a large code base on Windows
    491     (surprisingly, not so easily on Linux). In theory, increasing the stack
    492     size of the Java virtual machine (with the usual <code>-Xss</code> option)
    493     should help too. In practice however, the <code>-Xss</code> setting
    494     doesn't have any effect on the main thread, due to <a
    495     href="http://bugs.sun.com/view_bug.do?bug_id=4362291">Sun Bug
    496     #4362291</a>. As a result, this solution will only work when running
    497     ProGuard in a different thread, e.g. from its GUI.</dd>
    498 
    499 <dt><a name="unexpectederror"><b>Unexpected error</b></a></dt>
    500 
    501 <dd>ProGuard has encountered an unexpected condition, typically in the
    502     optimization step. It may or may not recover. You should be able to avoid
    503     it using the <a
    504     href="usage.html#dontoptimize"><code>-dontoptimize</code></a> option. In
    505     any case, please report the problem, preferably with the simplest example
    506     that causes ProGuard to crash.</dd>
    507 
    508 <dt><a name="otherwise"><b>Otherwise...</b></a></dt>
    509 
    510 <dd>Maybe your class files are corrupt. See if recompiling them and trying
    511     again helps. If not, please report the problem, preferably with the
    512     simplest example that causes ProGuard to crash.</dd>
    513 
    514 </dl>
    515 <p>
    516 
    517 <h2><a name="afterprocessing">Unexpected observations after processing</a></h2>
    518 
    519 If ProGuard seems to run fine, but your processed code doesn't look right,
    520 there might be a couple of reasons:
    521 
    522 <dl>
    523 <dt><a name="disappearingclasses"><b>Disappearing classes</b></a></dt>
    524 
    525 <dd>If you are working on Windows and it looks like some classes have
    526     disappeared from your output, you should make sure you're not writing your
    527     output class files to a directory (or unpacking the output jar). On
    528     platforms with case-insensitive file systems, such as Windows, unpacking
    529     tools often let class files with similar lower-case and upper-case names
    530     overwrite each other. If you really can't switch to a different operating
    531     system, you could consider using ProGuard's <a
    532     href="usage.html#dontusemixedcaseclassnames"><code>-dontusemixedcaseclassnames</code></a>
    533     option.
    534     <p>
    535     Also, you should make sure your class files are in directories that
    536     correspond to their package names. ProGuard will read misplaced class
    537     files, but it will currently not write their processed versions. Notably,
    538     class files that are in the <code>WEB-INF/classes</code> directory in a
    539     war should be packaged in a jar and put in the <code>WEB-INF/lib</code>
    540     directory.</dd>
    541 
    542 <dt><a name="notkept"><b>Classes or class members not being kept</b></a></dt>
    543 
    544 <dd>If ProGuard is not keeping the right classes or class members, make sure
    545     you are using fully qualified class names. If the package name of some
    546     class is missing, ProGuard won't match the elements that you might be
    547     expecting. It may help to double-check for typos too. You can use the <a
    548     href="usage.html#printseeds"><code>-printseeds</code></a> option to see
    549     which elements are being kept exactly.
    550     <p>
    551     If you are using marker interfaces to keep other classes, the marker
    552     interfaces themselves are probably being removed in the shrinking step.
    553     You should therefore always explicitly keep any marker interfaces, with
    554     an option like "<code>-keep interface MyMarkerInterface</code>".
    555     <p>
    556     Similarly, if you are keeping classes based on annotations, you may have
    557     to avoid that the annotation classes themselves are removed in the
    558     shrinking step. You should package the annotation classes as a library, or
    559     explicitly keep them in your program code with an option like "<code>-keep
    560     @interface *</code>".</dd>
    561 
    562 <dt><a name="notobfuscated"><b>Variable names not being obfuscated</b></a></dt>
    563 
    564 <dd>If the names of the local variables and parameters in your obfuscated code
    565     don't look obfuscated, because they suspiciously resemble the names of
    566     their types, it's probably because the decompiler that you are using is
    567     coming up with those names. ProGuard's obfuscation step does remove the
    568     original names entirely, unless you explicitly keep the
    569     <code>LocalVariableTable</code> or <code>LocalVariableTypeTable</code>
    570     attributes.</dd>
    571 
    572 </dl>
    573 
    574 <h2><a name="dalvik">Problems while converting to Android Dalvik bytecode</a></h2>
    575 
    576 If ProGuard seems to run fine, but the dx tool in the Android SDK subsequently
    577 fails with an error:
    578 
    579 <dl>
    580 <dt><a name="simexception"><b>SimException: local variable type mismatch</b></a></dt>
    581 
    582 <dd>This error indicates that ProGuard's optimization step has not been able
    583     to maintain the correct debug information about local variables. This can
    584     happen if some code is optimized radically. Possible work-arounds: let the
    585     java compiler not produce debug information (<code>-g:none</code>), or let
    586     ProGuard's obfuscation step remove the debug information again
    587     (by <i>not</i> keeping the attributes <code>LocalVariableTable</code>
    588     and <code>LocalVariableTypeTable</code>
    589     with <a href="usage.html#keepattributes"><code>-keepattributes</code></a>),
    590     or otherwise just disable optimization
    591     (<a href="usage.html#dontoptimize"><code>-dontoptimize</code></a>).</dd>
    592 
    593 <dt><a name="conversionerror"><b>Conversion to Dalvik format failed with error 1</b></a></dt>
    594 
    595 <dd>This error may have various causes, but if dx is tripping over some code
    596     processed by ProGuard, you should make sure that you are using the latest
    597     version of ProGuard. You can just copy the ProGuard jars
    598     to <code>android-sdk/tools/proguard/lib</code>. If that doesn't help,
    599     please report the problem, preferably with the simplest example that still
    600     brings out the error.</dd>
    601 
    602 </dl>
    603 
    604 <h2><a name="preverifying">Problems while preverifying for Java Micro Edition</a></h2>
    605 
    606 If ProGuard seems to run fine, but the external preverifier subsequently
    607 produces errors, it's usually for a single reason:
    608 
    609 <dl>
    610 <dt><a name="invalidclassexception1"><b>InvalidClassException</b>, <b>class loading error</b>, or <b>verification error</b></a></dt>
    611 
    612 <dd>If you get any such message from the preverifier, you are probably working
    613     on a platform with a case-insensitive file system, such as Windows. The
    614     <code>preverify</code> tool always unpacks the jars, so class files with
    615     similar lower-case and upper-case names overwrite each other. You can use
    616     ProGuard's <a
    617     href="usage.html#dontusemixedcaseclassnames"><code>-dontusemixedcaseclassnames</code></a>
    618     option to work around this problem.
    619     <p>
    620     If the above doesn't help, there is probably a bug in the optimization
    621     step of ProGuard. Make sure you are using the latest version. You should
    622     be able to work around the problem by using the <a
    623     href="usage.html#dontoptimize"><code>-dontoptimize</code></a> option. You
    624     can check the bug database to see if it is a known problem (often with a
    625     fix). Otherwise, please report it, preferably with the simplest example on
    626     which you can find ProGuard to fail.</dd>
    627 
    628 </dl>
    629 
    630 Note that it is no longer necessary to use an external preverifier. With the
    631 <a href="usage.html#microedition"><code>-microedition</code></a> option,
    632 ProGuard will preverify the class files for Java Micro Edition.
    633 <p>
    634 
    635 <h2><a name="runtime">Problems at run-time</a></h2>
    636 
    637 If ProGuard runs fine, but your processed application doesn't work, there
    638 might be several reasons:
    639 
    640 <dl>
    641 <dt><a name="stacktraces"><b>Stack traces without class names or line numbers</b></a></dt>
    642 
    643 <dd>If your stack traces don't contain any class names or lines numbers,
    644     even though you are keeping the proper attributes, make sure this debugging
    645     information is present in your compiled code to start with. Notably the Ant
    646     javac task has debugging information switched off by default.</dd>
    647 
    648 <dt><a name="noclassdeffounderror"><b>NoClassDefFoundError</b></a></dt>
    649 
    650 <dd>Your class path is probably incorrect. It should at least contain all
    651     library jars and, of course, your processed program jar.</dd>
    652 
    653 <dt><a name="classnotfoundexception"><b>ClassNotFoundException</b></a></dt>
    654 
    655 <dd>Your code is probably calling <code>Class.forName</code>, trying to create
    656     the missing class dynamically. ProGuard can only detect constant name
    657     arguments, like <code>Class.forName("mypackage.MyClass")</code>. For
    658     variable name arguments like <code>Class.forName(someClass)</code>, you
    659     have to keep all possible classes using the appropriate <a
    660     href="usage.html#keep"><code>-keep</code></a> option, e.g. "<code>-keep
    661     class mypackage.MyClass</code>" or "<code>-keep class * implements
    662     mypackage.MyInterface</code>".</dd>
    663 
    664 <dt><a name="nosuchfieldexception"><b>NoSuchFieldException</b></a></dt>
    665 
    666 <dd>Your code is probably calling something like
    667     <code>myClass.getField</code>, trying to find some field dynamically.
    668     Since ProGuard can't always detect this automatically, you have to keep
    669     the missing field in using the
    670     appropriate <a href="usage.html#keep"><code>-keep</code></a> option, e.g.
    671     "<code>-keepclassmembers class mypackage.MyClass { int myField;
    672     }</code>".</dd>
    673 
    674 <dt><a name="nosuchmethodexception"><b>NoSuchMethodException</b></a></dt>
    675 
    676 <dd>Your code is probably calling something like
    677     <code>myClass.getMethod</code>, trying to find some method dynamically.
    678     Since ProGuard can't always detect this automatically, you have to keep
    679     the missing method in using the
    680     appropriate <a href="usage.html#keep"><code>-keep</code></a> option, e.g.
    681     "<code>-keepclassmembers class mypackage.MyClass { void myMethod();
    682     }</code>".
    683     <p>
    684     More specifically, if the method reported as missing is
    685     <code>values</code> or <code>valueOf</code>, you probably have to keep
    686     some methods related to <a
    687     href="examples.html#enumerations">enumerations</a>.</dd>
    688 
    689 <dt><a name="missingresourceexception"><b>MissingResourceException</b> or <b>NullPointerException</b></a></dt>
    690 
    691 <dd>Your processed code may be unable to find some resource files. ProGuard
    692     simply copies resource files over from the input jars to the output jars.
    693     Their names and contents remain unchanged, unless you specify the options
    694     <a
    695     href="usage.html#adaptresourcefilenames"><code>-adaptresourcefilenames</code></a>
    696     and/or <a
    697     href="usage.html#adaptresourcefilecontents"><code>-adaptresourcefilecontents</code></a>.
    698     <p>
    699     Furthermore, directory entries in jar files aren't copied, unless you
    700     specify the option <a
    701     href="usage.html#keepdirectories"><code>-keepdirectories</code></a>.
    702     Note that Sun advises against calling <code>Class.getResource()</code> for
    703     directories (<a href="http://bugs.sun.com/view_bug.do?bug_id=4761949">Sun
    704     Bug #4761949</a>).</dd>
    705 
    706 <dt><a name="disappearingannotations"><b>Disappearing annotations</b></a></dt>
    707 
    708 <dd>By default, the obfuscation step removes all annotations. If your
    709     application relies on annotations to function properly, you should
    710     explicitly keep them with
    711     <code><a href="usage.html#keepattributes">-keepattributes</a>
    712     *Annotation*</code>.</dd>
    713 
    714 <dt><a name="invalidjarfile"><b>Invalid or corrupt jarfile</b></a></dt>
    715 
    716 <dd>You are probably starting your application with the java option
    717     <code>-jar</code> instead of the option <code>-classpath</code>. The java
    718     virtual machine returns with this error message if your jar doesn't
    719     contain a manifest file (<code>META-INF/MANIFEST.MF</code>), if the
    720     manifest file doesn't specify a main class (<code>Main-Class:</code> ...),
    721     or if the jar doesn't contain this main class. You should then make sure
    722     that the input jar contains a valid manifest file to start with, that this
    723     manifest file is the one that is copied (the first manifest file that is
    724     encountered), and that the main class is kept in your configuration,</dd>
    725 
    726 <dt><a name="invalidjarindexexception"><b>InvalidJarIndexException: Invalid index</b></a></dt>
    727 
    728 <dd>At least one of your processed jar files contains an index file
    729     <code>META-INF/INDEX.LIST</code>, listing all class files in the jar.
    730     ProGuard by default copies files like these unchanged. ProGuard may however
    731     remove or rename classes, thus invalidating the file. You should filter the
    732     index file out of the input
    733     (<code>-injars in.jar(!META-INF/INDEX.LIST)</code>) or update the file
    734     after having applied ProGuard (<code>jar -i out.jar</code>).
    735     </dd>
    736 
    737 <dt><a name="invalidclassexception2"><b>InvalidClassException</b>, <b>class loading error</b>, or <b>verification error</b> (in Java Micro Edition)</a></dt>
    738 
    739 <dd>If you get such an error in Java Micro Edition, you may have forgotten to
    740     specify the <a
    741     href="usage.html#microedition"><code>-microedition</code></a> option, so
    742     the processed class files are preverified properly.</dd>
    743 
    744 <dt><a name="nosuchfieldormethod"><b>Error: No Such Field or Method</b>, <b>Error verifying method</b> (in a Java Micro Edition emulator)</a></dt>
    745 
    746 <dd>If you get such a message in a Motorola or Sony Ericsson phone emulator,
    747     it's because these emulators don't like packageless classes and/or
    748     overloaded fields and methods. You can work around it by not using the
    749     options <code><a href="usage.html#repackageclasses">-repackageclasses</a>
    750     ''</code> and <a
    751     href="usage.html#overloadaggressively"><code>-overloadaggressively</code></a>.
    752     If you're using the JME WTK plugin, you can adapt the configuration
    753     <code>proguard/wtk/default.pro</code> that's inside the
    754     <code>proguard.jar</code>.</dd>
    755 
    756 <dt><a name="failingmidlets"><b>Failing midlets</b> (on a Java Micro Edition device)</a></dt>
    757 
    758 <dd>If your midlet runs in an emulator and on some devices, but not on some
    759     other devices, this is probably due to a bug in the latter devices. For
    760     some older Motorola and Nokia phones, you might try specifying the <a
    761     href="usage.html#useuniqueclassmembernames"><code>-useuniqueclassmembernames</code></a>
    762     option. It avoids overloading class member names, which triggers a bug in
    763     their java virtual machine.
    764     <p>
    765     You might also try using the <a
    766     href="usage.html#dontusemixedcaseclassnames"><code>-dontusemixedcaseclassnames</code></a>
    767     option. Even if the midlet has been properly processed and then
    768     preverified on a case-sensitive file system, the device itself might not
    769     like the mixed-case class names. Notably, the Nokia N-Gage emulator works
    770     fine, but the actual device seems to exhibit this problem.</dd>
    771 
    772 <dt><a name="disappearingloops"><b>Disappearing loops</b></a></dt>
    773 
    774 <dd>If your code contains empty busy-waiting loops, ProGuard's optimization
    775     step may remove them. More specifically, this happens if a loop
    776     continuously checks the value of a non-volatile field that is changed in a
    777     different thread. The specifications of the Java Virtual Machine require
    778     that you always mark fields that are accessed across different threads
    779     without further synchronization as <code>volatile</code>. If this is not
    780     possible for some reason, you'll have to switch off optimization using the
    781     <a href="usage.html#dontoptimize"><code>-dontoptimize</code></a>
    782     option.</dd>
    783 
    784 <dt><a name="securityexception"><b>SecurityException: SHA1 digest error</b></a></dt>
    785 
    786 <dd>You may have forgotten to sign your program jar <i>after</i> having
    787     processed it with ProGuard.</dd>
    788 
    789 <dt><a name="classcastexception"><b>ClassCastException: class not an enum</b>, or <br /><b>IllegalArgumentException: class not an enum type</b></a></dt>
    790 
    791 <dd>You should make sure you're preserving the special methods of enumeration
    792     types, which the run-time environment calls by introspection. The required
    793     options are shown in the <a
    794     href="examples.html#enumerations">examples</a>.</dd>
    795 
    796 <dt><a name="arraystoreexception"><b>ArrayStoreException: sun.reflect.annotation.EnumConstantNotPresentExceptionProxy</b></a></dt>
    797 
    798 <dd>You are probably processing annotations involving enumerations. Again, you
    799     should make sure you're preserving the special methods of the enumeration
    800     type, as shown in the examples.</dd>
    801 
    802 <dt><a name="compilererror"><b>CompilerError: duplicate addition</b></a></dt>
    803 
    804 <dd>You are probably compiling or running some code that has been obfuscated
    805     with the <a
    806     href="usage.html#overloadaggressively"><code>-overloadaggressively</code></a>
    807     option. This option triggers a bug in
    808     <code>sun.tools.java.MethodSet.add</code> in Sun's JDK 1.2.2, which is
    809     used for (dynamic) compilation. You should then avoid this option.</dd>
    810 
    811 <dt><a name="classformaterror1"><b>ClassFormatError: repetitive field name/signature</b></a></dt>
    812 
    813 <dd>You are probably processing some code that has been obfuscated before with
    814     the <a
    815     href="usage.html#overloadaggressively"><code>-overloadaggressively</code></a>
    816     option. You should then use the same option again in the second processing
    817     round.</dd>
    818 
    819 <dt><a name="classformaterror2"><b>ClassFormatError: Invalid index in LocalVariableTable in class file</b></a></dt>
    820 
    821 <dd>If you are keeping the <code>LocalVariableTable</code> or
    822     <code>LocalVariableTypeTable</code> attributes, ProGuard's optimizing step
    823     is sometimes unable to update them consistently. You should then let the
    824     obfuscation step remove these attributes or disable the optimization
    825     step.</dd>
    826 
    827 <dt><a name="nosuchmethoderror"><b>NoSuchMethodError</b> or <b>AbstractMethodError</b></a></dt>
    828 
    829 <dd>You should make sure you're not writing your output class files to a
    830     directory on a platform with a case-insensitive file system, such as
    831     Windows. Please refer to the section about <a
    832     href="#disappearingclasses">disappearing classes</a> for details.
    833     <p>
    834     Furthermore, you should check whether you have specified your program jars
    835     and library jars properly. Program classes can refer to library classes,
    836     but not the other way around.
    837     <p>
    838     If all of this seems ok, perhaps there's a bug in ProGuard (gasp!). If so,
    839     please report it, preferably with the simplest example on which you can
    840     find ProGuard to fail.</dd>
    841 
    842 <dt><a name="verifyerror"><b>VerifyError</b></a></dt>
    843 
    844 <dd>Verification errors when executing a program are almost certainly the
    845     result of a bug in the optimization step of ProGuard. Make sure you are
    846     using the latest version. You should be able to work around the problem by
    847     using the <a href="usage.html#dontoptimize"><code>-dontoptimize</code></a>
    848     option. You can check the bug database to see if it is a known problem
    849     (often with a fix). Otherwise, please report it, preferably with the
    850     simplest example on which ProGuard fails.</dd>
    851 
    852 </dl>
    853 
    854 <hr />
    855 <noscript><div><a target="_top" href="../index.html" class="button">Show menu</a></div></noscript>
    856 <address>
    857 Copyright &copy; 2002-2013
    858 <a target="other" href="http://www.lafortune.eu/">Eric Lafortune</a>.
    859 </address>
    860 </body>
    861 </html>
    862