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