1<!doctype html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
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">
10if (window.self==window.top)
11  window.top.location.replace("/index.html#"+window.location.pathname+window.location.hash);
12else {
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;
24While preparing a configuration for processing your code, you may bump into a
25few problems. The following sections discuss some common issues and solutions:
27<h3><a href="#processing">Problems while processing</a></h3>
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>
61<h3><a href="#afterprocessing">Unexpected observations after processing</a></h3>
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>
68<h3><a href="#dalvik">Problems while converting to Android Dalvik bytecode</a></h3>
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>
75<h3><a href="#preverifying">Problems while preverifying for Java Micro Edition</a></h3>
78<li><a href="#invalidclassexception1">InvalidClassException, class loading error, or verification error</a></li>
81<h3><a href="#runtime">Problems at run-time</a></h3>
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>
107<h2><a name="processing">Problems while processing</a></h2>
109ProGuard may print out some notes and non-fatal warnings:
112<dt><a name="dynamicalclass"><b>Note: can't find dynamically referenced class ...</b></a></dt>
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>
118<dt><a name="dynamicalclasscast"><b>Note: ... calls '(...)Class.forName(variable).newInstance()'</b></a></dt>
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>
128<dt><a name="dynamicalclassmember"><b>Note: ... accesses a field/method '...' dynamically</b></a></dt>
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>
140<dt><a name="unknownclass"><b>Note: the configuration refers to the unknown class  '...'</b></a></dt>
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>
147<dt><a name="descriptorclass"><b>Note: the configuration keeps the entry point '...', but not the descriptor class '...'</b></a></dt>
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>
158<dt><a name="classmembers"><b>Note: the configuration doesn't specify which class members to keep for class '...'</b></a></dt>
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>
173<dt><a name="duplicateclass"><b>Note: duplicate definition of program/library class</b></a></dt>
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>
197<dt><a name="duplicatezipentry"><b>Warning: can't write resource ... Duplicate zip entry</b></a></dt>
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>
215ProGuard may terminate when it encounters parsing errors or I/O errors, or
216some more serious warnings:
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>
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>
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>
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>
301<dt><a name="unresolvedprogramclassmember"><b>Warning: can't find referenced field/method '...' in program class ...</b></a></dt>
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>
311<dt><a name="unresolvedlibraryclassmember"><b>Warning: can't find referenced field/method '...' in library class ...</b></a></dt>
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>
341<dt><a name="unresolvedenclosingmethod"><b>Warning: can't find enclosing class/method</b></a></dt>
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>
349<dt><a name="dependency"><b>Warning: library class ... depends on program class ...</b></a></dt>
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>
373<dt><a name="unexpectedclass"><b>Warning: class file ... unexpectedly contains class ...</b></a></dt>
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>
387<dt><a name="mappingconflict1"><b>Warning: ... is not being kept as ..., but remapped to ...</b></a></dt>
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>
400<dt><a name="mappingconflict2"><b>Warning: field/method ... can't be mapped to ...</b></a></dt>
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>
418<dt><a name="unsupportedclassversion"><b>Error: Unsupported class version number</b></a></dt>
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>
425<dt><a name="keep"><b>Error: You have to specify '-keep' options</b></a></dt>
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>
434<dt><a name="filename"><b>Error: Expecting class path separator ';' before 'Files\Java\</b>...<b>'</b> (in Windows)</a></dt>
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>
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>
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>
449<dt><a name="cantread"><b>Error: Can't read ...</b></a></dt>
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>
459<dt><a name="cantwrite"><b>Error: Can't write ...</b></a></dt>
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>
465<dt><a name="startinggui"><b>Internal problem starting the ProGuard GUI (Cannot write XdndAware property)</b> (in Linux)</a></dt>
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>
476Should ProGuard crash while processing your application:
479<dt><a name="outofmemoryerror"><b>OutOfMemoryError</b></a></dt>
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>
488<dt><a name="stackoverflowerror"><b>StackOverflowError</b></a></dt>
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>
499<dt><a name="unexpectederror"><b>Unexpected error</b></a></dt>
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>
508<dt><a name="otherwise"><b>Otherwise...</b></a></dt>
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>
517<h2><a name="afterprocessing">Unexpected observations after processing</a></h2>
519If ProGuard seems to run fine, but your processed code doesn't look right,
520there might be a couple of reasons:
523<dt><a name="disappearingclasses"><b>Disappearing classes</b></a></dt>
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>
542<dt><a name="notkept"><b>Classes or class members not being kept</b></a></dt>
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>
562<dt><a name="notobfuscated"><b>Variable names not being obfuscated</b></a></dt>
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>
574<h2><a name="dalvik">Problems while converting to Android Dalvik bytecode</a></h2>
576If ProGuard seems to run fine, but the dx tool in the Android SDK subsequently
577fails with an error:
580<dt><a name="simexception"><b>SimException: local variable type mismatch</b></a></dt>
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>
593<dt><a name="conversionerror"><b>Conversion to Dalvik format failed with error 1</b></a></dt>
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>
604<h2><a name="preverifying">Problems while preverifying for Java Micro Edition</a></h2>
606If ProGuard seems to run fine, but the external preverifier subsequently
607produces errors, it's usually for a single reason:
610<dt><a name="invalidclassexception1"><b>InvalidClassException</b>, <b>class loading error</b>, or <b>verification error</b></a></dt>
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>
630Note that it is no longer necessary to use an external preverifier. With the
631<a href="usage.html#microedition"><code>-microedition</code></a> option,
632ProGuard will preverify the class files for Java Micro Edition.
635<h2><a name="runtime">Problems at run-time</a></h2>
637If ProGuard runs fine, but your processed application doesn't work, there
638might be several reasons:
641<dt><a name="stacktraces"><b>Stack traces without class names or line numbers</b></a></dt>
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>
648<dt><a name="noclassdeffounderror"><b>NoClassDefFoundError</b></a></dt>
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>
653<dt><a name="classnotfoundexception"><b>ClassNotFoundException</b></a></dt>
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>
664<dt><a name="nosuchfieldexception"><b>NoSuchFieldException</b></a></dt>
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>
674<dt><a name="nosuchmethodexception"><b>NoSuchMethodException</b></a></dt>
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>
689<dt><a name="missingresourceexception"><b>MissingResourceException</b> or <b>NullPointerException</b></a></dt>
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>
706<dt><a name="disappearingannotations"><b>Disappearing annotations</b></a></dt>
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>
714<dt><a name="invalidjarfile"><b>Invalid or corrupt jarfile</b></a></dt>
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>
726<dt><a name="invalidjarindexexception"><b>InvalidJarIndexException: Invalid index</b></a></dt>
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>
737<dt><a name="invalidclassexception2"><b>InvalidClassException</b>, <b>class loading error</b>, or <b>verification error</b> (in Java Micro Edition)</a></dt>
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>
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>
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>
756<dt><a name="failingmidlets"><b>Failing midlets</b> (on a Java Micro Edition device)</a></dt>
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>
772<dt><a name="disappearingloops"><b>Disappearing loops</b></a></dt>
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>
784<dt><a name="securityexception"><b>SecurityException: SHA1 digest error</b></a></dt>
786<dd>You may have forgotten to sign your program jar <i>after</i> having
787    processed it with ProGuard.</dd>
789<dt><a name="classcastexception"><b>ClassCastException: class not an enum</b>, or <br /><b>IllegalArgumentException: class not an enum type</b></a></dt>
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>
796<dt><a name="arraystoreexception"><b>ArrayStoreException: sun.reflect.annotation.EnumConstantNotPresentExceptionProxy</b></a></dt>
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>
802<dt><a name="compilererror"><b>CompilerError: duplicate addition</b></a></dt>
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>
811<dt><a name="classformaterror1"><b>ClassFormatError: repetitive field name/signature</b></a></dt>
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>
819<dt><a name="classformaterror2"><b>ClassFormatError: Invalid index in LocalVariableTable in class file</b></a></dt>
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>
827<dt><a name="nosuchmethoderror"><b>NoSuchMethodError</b> or <b>AbstractMethodError</b></a></dt>
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>
842<dt><a name="verifyerror"><b>VerifyError</b></a></dt>
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>
854<hr />
855<noscript><div><a target="_top" href="/index.html" class="button">Show menu</a></div></noscript>
857Copyright &copy; 2002-2013
858<a target="other" href="http://www.lafortune.eu/">Eric Lafortune</a>.