1<!doctype html PUBLIC "-//W3C//DTD HTML 3.2 Final//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<h2>Troubleshooting</h2> 12 13While preparing a configuration for processing your code, you may bump into a 14few problems. The following sections discuss some common issues and solutions: 15 16<h3><a href="#processing">Problems while processing</a></h3> 17<ul> 18<li><a href="#dynamicalclass">Note: can't find dynamically referenced class</a></li> 19<li><a href="#dynamicalclasscast">Note: ... calls '(...)Class.forName(variable).newInstance()'</a></li> 20<li><a href="#dynamicalclassmember">Note: ... accesses a field/method '...' dynamically</a></li> 21<li><a href="#descriptorclass">Note: the configuration keeps the entry point '...', but not the descriptor class '...'</a></li> 22<li><a href="#duplicateclass">Note: duplicate definition of program/library class</a></li> 23<li><a href="#duplicatezipentry">Warning: can't write resource ... Duplicate zip entry</a></li> 24<li><a href="#unresolvedclass">Warning: can't find superclass or interface</a></li> 25<li><a href="#unresolvedclass">Warning: can't find referenced class</a></li> 26<li><a href="#unresolvedclassmember">Warning: can't find referenced field/method</a></li> 27<li><a href="#unresolvedenclosingmethod">Warning: can't find enclosing class/method</a></li> 28<li><a href="#dependency">Warning: library class ... depends on program class ...</a></li> 29<li><a href="#unexpectedclass">Warning: class file ... unexpectedly contains class ...</a></li> 30<li><a href="#mappingconflict1">Warning: ... is not being kept as ..., but remapped to ...</a></li> 31<li><a href="#mappingconflict2">Warning: field/method ... can't be mapped to ...</a></li> 32<li><a href="#keep">Error: You have to specify '-keep' options</a></li> 33<li><a href="#filename">Error: Expecting class path separator ';' before 'Files\Java\...' (in Windows)</a></li> 34<li><a href="#macosx">Error: Can't read [.../lib/rt.jar] (No such file or directory) (in MacOS X)</a></li> 35<li><a href="#outofmemoryerror">OutOfMemoryError</a></li> 36<li><a href="#stackoverflowerror">StackOverflowError</a></li> 37<li><a href="#unexpectederror">Unexpected error</a></li> 38<li><a href="#otherwise">Otherwise...</a></li> 39</ul> 40 41<h3><a href="#afterprocessing">Unexpected observations after processing</a></h3> 42<ul> 43<li><a href="#disappearingclasses">Disappearing classes</a></li> 44<li><a href="#notkept">Classes or class members not being kept</a></li> 45<li><a href="#notobfuscated">Variable names not being obfuscated</a></li> 46</ul> 47 48<h3><a href="#preverifying">Problems while preverifying for Java Micro Edition</a></h3> 49 50<ul> 51<li><a href="#invalidclassexception1">InvalidClassException, class loading error, or verification error</a></li> 52</ul> 53 54<h3><a href="#runtime">Problems at run-time</a></h3> 55<ul> 56<li><a href="#stacktraces">Stack traces without class names or line numbers</a></li> 57<li><a href="#noclassdeffounderror">NoClassDefFoundError</a></li> 58<li><a href="#classnotfoundexception">ClassNotFoundException</a></li> 59<li><a href="#nosuchmethodexception">NoSuchMethodException</a></li> 60<li><a href="#missingresourceexception">MissingResourceException or NullPointerException</a></li> 61<li><a href="#invalidjarfile">Invalid or corrupt jarfile</a></li> 62<li><a href="#invalidclassexception2">InvalidClassException, class loading error, or verification error (in Java Micro Edition)</a></li> 63<li><a href="#nosuchfieldormethod">Error: No Such Field or Method, Error verifying method (in a Java Micro Edition emulator)</a></li> 64<li><a href="#failingmidlets">Failing midlets (on a Java Micro Edition device)</a></li> 65<li><a href="#disappearingloops">Disappearing loops</a></li> 66<li><a href="#securityexception">SecurityException: SHA1 digest error</a></li> 67<li><a href="#classcastexception">ClassCastException: class not an enum</a></li><li><a href="#classcastexception">IllegalArgumentException: class not an enum type</a></li> 68<li><a href="#arraystoreexception">ArrayStoreException: sun.reflect.annotation.EnumConstantNotPresentExceptionProxy</a></li> 69<li><a href="#compilererror">CompilerError: duplicate addition</a></li> 70<li><a href="#classformaterror">ClassFormatError: repetitive field name/signature</a></li> 71<li><a href="#nosuchmethoderror">NoSuchMethodError or AbstractMethodError</a></li> 72<li><a href="#verifyerror">VerifyError</a></li> 73</ul> 74 75 76<a name="processing"> </a> 77<h2>Problems while processing</h2> 78 79ProGuard may print out some notes and non-fatal warnings: 80 81<dl> 82<dt><a name="dynamicalclass"><b>Note: can't find dynamically referenced class</b></a></dt> 83 84<dd>ProGuard can't find a class or interface that your code is accessing by 85 means of introspection. You should check if you want to add the jar that 86 contains this class.</dd> 87 88<dt><a name="dynamicalclasscast"><b>Note: ... calls '(...)Class.forName(variable).newInstance()'</b></a></dt> 89 90<dd>ProGuard lists all class casts of dynamically created class instances, 91 like "<code>(MyClass)Class.forName(variable).newInstance()</code>". 92 Depending on your application, you may need to keep the mentioned classes 93 with an option like "<code>-keep class MyClass</code>", or their 94 implementations with an option like "<code>-keep class * implements 95 MyClass</code>". You can switch off these notes by specifying the 96 <a href="usage.html#dontnote"><code>-dontnote</code></a> option.</dd> 97 98<dt><a name="dynamicalclassmember"><b>Note: ... accesses a field/method '...' dynamically</b></a></dt> 99 100<dd>ProGuard lists a number of constructs like 101 "<code>.getField("myField")</code>". Depending on your application, you 102 may need to figure out where the mentioned class members are defined and 103 keep them with an option like "<code>-keep class MyClass { MyFieldType 104 myField; }</code>". Otherwise, ProGuard might remove or obfuscate the 105 class members, since it can't know which ones they are exactly. It does 106 list possible candidates, for your information. You can switch off these 107 notes by specifying the <a 108 href="usage.html#dontnote"><code>-dontnote</code></a> option.</dd> 109 110<dt><a name="descriptorclass"><b>Note: the configuration keeps the entry point '...', but not the descriptor class '...'</b></a></dt> 111 112<dd>Your configuration contains a <code>-keep</code> option to preserve the 113 given method (or field), but no <code>-keep</code> option for the given 114 class that is an argument type or return type in the method's descriptor. 115 You may then want to keep the class too. Otherwise, ProGuard will 116 obfuscate its name, thus changing the method's signature. The method might 117 then become unfindable as an entry point, e.g. if it is part of a public 118 API. You can switch off these notes by specifying the <a 119 href="usage.html#dontnote"><code>-dontnote</code></a> option.</dd> 120 121<dt><a name="duplicateclass"><b>Note: duplicate definition of program/library class</b></a></dt> 122 123<dd>Your program jars or library jars contain multiple definitions of the 124 listed classes. ProGuard continues processing as usual, only considering 125 the first definitions. The warning may be an indication of some problem 126 though, so it's advisable to remove the duplicates. A convenient way to do 127 so is by specifying filters on the input jars or library jars. You can 128 switch off these notes by specifying the <a 129 href="usage.html#dontnote"><code>-dontnote</code></a> option.</dd> 130 131<dt><a name="duplicatezipentry"><b>Warning: can't write resource ... Duplicate zip entry</b></a></dt> 132 133<dd>Your input jars contain multiple resource files with the same name. 134 ProGuard continues copying the resource files as usual, skipping any files 135 with previously used names. Once more, the warning may be an indication of 136 some problem though, so it's advisable to remove the duplicates. A 137 convenient way to do so is by specifying filters on the input jars. There 138 is no option to switch off these warnings.</dd> 139 140</dl> 141<p> 142 143ProGuard may terminate when it encounters parsing errors or I/O errors, or 144some more serious warnings: 145 146<dl> 147<dt><a name="unresolvedclass"><b>Warning: can't find superclass or interface</b><br/><b>Warning: can't find referenced class</b></a></dt> 148 149<dd>If there are unresolved references to classes or interfaces, you most 150 likely forgot to specify an essential library. For proper processing, all 151 libraries that are referenced by your code must be specified, including 152 the Java run-time library. For specifying libraries, use 153 the <a href="usage.html#libraryjars"><code>-libraryjars</code></a> option. 154 <p> 155 If the class that is reported as missing is a non-public library class, 156 you should specify the <a 157 href="usage.html#dontskipnonpubliclibraryclasses"><code>-dontskipnonpubliclibraryclasses</code></a> 158 option. Common examples are the classes 159 <code>javax.swing.TransferHandler$HasGetTransferHandler</code> and 160 <code>java.util.zip.ZipConstants</code>, which are used as interfaces in 161 some public classes, even though they are only package visible. This 162 option is not set by default for reasons of efficiency. Setting it increases 163 the processing time a bit, but it won't hurt the output in any way. 164 <p> 165 If you're missing a library and you're absolutely sure it isn't used 166 anyway, you can try your luck with the <a 167 href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a> option, 168 or even the <a href="usage.html#dontwarn"><code>-dontwarn</code></a> 169 option. Only use these options if you really know what you're doing 170 though.</dd> 171 172<dt><a name="unresolvedclassmember"><b>Warning: can't find referenced field/method</b></a></dt> 173 174<dd>If there are unresolved references to class members in input classes, your 175 class files are most likely inconsistent. Possibly, some class file didn't 176 get recompiled properly, or some class file was left behind after its 177 source file was removed. Try removing all class files, recompiling them, 178 zipping them up, and running ProGuard again. 179 <p> 180 If the class member that is reported as missing is actually implemented in 181 a non-public library class, you should specify the 182 <a href="usage.html#dontskipnonpubliclibraryclasses"><code>-dontskipnonpubliclibraryclasses</code></a> option. A common example is 183 the method <code>setLength(int)</code> in the public class 184 <code>java.lang.StringBuilder</code>. This method is actually defined in 185 the package visible superclass 186 <code>java.lang.AbstractStringBuilder</code>, which ProGuard ignores by 187 default. 188 <p> 189 If your program classes reside in the same packages as library classes, 190 and refer to their package visible class members, then you should specify 191 the <a 192 href="usage.html#dontskipnonpubliclibraryclassmembers"><code>-dontskipnonpubliclibraryclassmembers</code></a> 193 option.</dd> 194 195<dt><a name="unresolvedenclosingmethod"><b>Warning: can't find enclosing class/method</b></a></dt> 196 197<dd>If there are unresolved references to classes that are defined inside 198 methods in your input, once more, your class files are most likely 199 inconsistent. Possibly, some class file didn't get recompiled properly, or 200 some class file was left behind after its source file was removed. Try 201 removing all class files, recompiling them, zipping them up, and running 202 ProGuard again.</dd> 203 204<dt><a name="dependency"><b>Warning: library class ... depends on program class ...</b></a></dt> 205 206<dd>If any of your library classes depend on your program classes, by 207 extending, implementing or just referencing them, your processed code will 208 generally be unusable. Program classes can depend on library classes, but 209 not the other way around. Program classes are processed, while library 210 classes always remain unchanged. It is therefore impossible to adapt 211 references from library classes to program classes, for instance if the 212 program classes are renamed. You should define a clean separation between 213 program code and library code, and try again.</dd> 214 215<dt><a name="unexpectedclass"><b>Warning: class file ... unexpectedly contains class ...</b></a></dt> 216 217<dd>The given class file contains a definition for the given class, but the 218 directory name of the file doesn't correspond to the package name of the 219 class. ProGuard will accept the class definition, but the current 220 implementation will not write out the processed version. Please make sure 221 your input classes are packaged correctly. Notably, class files that are 222 in the <code>WEB-INF/classes</code> directory in a war should be packaged 223 in a jar and put in the <code>WEB-INF/lib</code> directory. If you don't 224 mind these classes not being written to the output, you can specify the <a 225 href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a> option, 226 or even the <a href="usage.html#dontwarn"><code>-dontwarn</code></a> 227 option.</dd> 228 229<dt><a name="mappingconflict1"><b>Warning: ... is not being kept as ..., but remapped to ...</b></a></dt> 230 231<dd>There is a conflict between a <code>-keep</code> option in the 232 configuration, and the mapping file, in the obfuscation step. The given 233 class name or class member name can't be kept by its original name, as 234 specified in the configuration, but it has to be mapped to the other given 235 name, as specified in the mapping file. You should adapt your 236 configuration or your mapping file to remove the conflict. Alternatively, 237 if you're sure the renaming won't hurt, you can specify the <a 238 href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a> option, 239 or even the <a href="usage.html#dontwarn"><code>-dontwarn</code></a> 240 option.</dd> 241 242<dt><a name="mappingconflict2"><b>Warning: field/method ... can't be mapped to ...</b></a></dt> 243 244<dd>There is a conflict between some new program code and the mapping file, in 245 the obfuscation step. The given class member can't be mapped to the given 246 name, because it would conflict with another class member that is already 247 being mapped to the same name. This can happen if you are performing 248 incremental obfuscation, applying an obfuscation mapping file from an 249 initial obfuscation step. For instance, some new class may have been added 250 that extends two existing classes, introducing a conflict in the name 251 space of its class members. If you're sure the class member receiving 252 another name than the one specified won't hurt, you can specify the <a 253 href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a> option, 254 or even the <a href="usage.html#dontwarn"><code>-dontwarn</code></a> 255 option. Note that you should always use the <a 256 href="usage.html#useuniqueclassmembernames"><code>-useuniqueclassmembernames</code></a> 257 option in the initial obfuscation step, in order to reduce the risk of 258 conflicts.</dd> 259 260<dt><a name="keep"><b>Error: You have to specify '-keep' options</b></a></dt> 261 262<dd>You either forgot to specify <a 263 href="usage.html#keep"><code>-keep</code></a> options, or you mistyped the 264 class names. ProGuard has to know exactly what you want to keep: an 265 application, an applet, a servlet, a midlet,..., or any combination of 266 these. Without the proper seed specifications, ProGuard would shrink, 267 optimize, or obfuscate all class files away.</dd> 268 269 270<dt><a name="filename"><b>Error: Expecting class path separator ';' before 'Files\Java\</b>...<b>'</b> (in Windows)</a></dt> 271 272<dd>If the path of your run-time jar contains spaces, like in "Program Files", 273 you have to enclose it with single or double quotes, as explained in the 274 section on <a href="usage.html#filename">file names</a>. This is actually 275 true for all file names containing special characters, on all 276 platforms.</dd> 277 278<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> 279 280<dd>In MacOS X, the run-time classes may be in a different place than on most 281 other platforms. You'll then have to adapt your configuration, replacing 282 the path <code><java.home>/lib/rt.jar</code> by 283 <code><java.home>/../Classes/classes.jar</code>.</dd> 284 285</dl> 286<p> 287 288Should ProGuard crash while processing your application: 289 290<dl> 291<dt><a name="outofmemoryerror"><b>OutOfMemoryError</b></a></dt> 292 293<dd>You can try increasing the heap size of the Java virtual machine (with the 294 usual <code>-Xms</code> and <code>-Xmx</code> options). You can also 295 reduce the amount of memory that ProGuard needs by removing unnecessary 296 library jars from your configuration, or by filtering out unused library 297 packages and classes. Remember that only classes or interfaces that are 298 extended or implemented by classes in your input jars are required.</dd> 299 300<dt><a name="stackoverflowerror"><b>StackOverflowError</b></a></dt> 301 302<dd>This error might occur when processing a large code base on Windows 303 (surprisingly, not so easily on Linux). In theory, increasing the stack 304 size of the Java virtual machine (with the usual <code>-Xss</code> option) 305 should help too. In practice however, the <code>-Xss</code> setting 306 doesn't have any effect on the main thread, due to <a 307 href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4362291">Sun Bug 308 #4362291</a>. As a result, this solution will only work when running 309 ProGuard in a different thread, e.g. from its GUI.</dd> 310 311<dt><a name="unexpectederror"><b>Unexpected error</b></a></dt> 312 313<dd>ProGuard has encountered an unexpected condition, typically in the 314 optimization step. It may or may not recover. You should be able to avoid 315 it using the <a 316 href="usage.html#dontoptimize"><code>-dontoptimize</code></a> option. In 317 any case, please report the problem, preferably with the simplest example 318 that causes ProGuard to crash.</dd> 319 320<dt><a name="otherwise"><b>Otherwise...</b></a></dt> 321 322<dd>Maybe your class files are corrupt. See if recompiling them and trying 323 again helps. If not, please report the problem, preferably with the 324 simplest example that causes ProGuard to crash.</dd> 325 326</dl> 327<p> 328 329<a name="afterprocessing"> </a> 330<h2>Unexpected observations after processing</h2> 331 332If ProGuard seems to run fine, but your processed code doesn't look right, 333there might be a couple of reasons: 334 335<dl> 336<dt><a name="disappearingclasses"><b>Disappearing classes</b></a></dt> 337 338<dd>If you are working on Windows and it looks like some classes have 339 disappeared from your output, you should make sure you're not writing your 340 output class files to a directory (or unpacking the output jar). On 341 platforms with case-insensitive file systems, such as Windows, unpacking 342 tools often let class files with similar lower-case and upper-case names 343 overwrite each other. If you really can't switch to a different operating 344 system, you could consider using ProGuard's <a 345 href="usage.html#dontusemixedcaseclassnames"><code>-dontusemixedcaseclassnames</code></a> 346 option. 347 <p> 348 Also, you should make sure your class files are in directories that 349 correspond to their package names. ProGuard will read misplaced class 350 files, but it will currently not write their processed versions. Notably, 351 class files that are in the <code>WEB-INF/classes</code> directory in a 352 war should be packaged in a jar and put in the <code>WEB-INF/lib</code> 353 directory.</dd> 354 355<dt><a name="notkept"><b>Classes or class members not being kept</b></a></dt> 356 357<dd>If ProGuard is not keeping the right classes or class members, make sure 358 you are using fully qualified class names. If the package name of some 359 class is missing, ProGuard won't match the elements that you might be 360 expecting. It may help to double-check for typos too. You can use the <a 361 href="usage.html#printseeds"><code>-printseeds</code></a> option to see 362 which elements are being kept exactly. 363 <p> 364 If you are using marker interfaces to keep other classes, the marker 365 interfaces themselves are probably being removed in the shrinking step. 366 You should therefore always explicitly keep any marker interfaces.</dd> 367 368<dt><a name="notobfuscated"><b>Variable names not being obfuscated</b></a></dt> 369 370<dd>If the names of the local variables and parameters in your obfuscated code 371 don't look obfuscated, because they suspiciously resemble the names of 372 their types, it's probably because the decompiler that you are using is 373 coming up with those names. ProGuard's obfuscation step does remove the 374 original names entirely, unless you explicitly keep the 375 <code>LocalVariableTable</code> or <code>LocalVariableTypeTable</code> 376 attributes.</dd> 377 378</dl> 379 380<a name="preverifying"> </a> 381<h2>Problems while preverifying for Java Micro Edition</h2> 382 383If ProGuard seems to run fine, but the external preverifier subsequently 384produces errors, it's usually for a single reason: 385 386<dl> 387<dt><a name="invalidclassexception1"><b>InvalidClassException</b>, <b>class loading error</b>, or <b>verification error</b></a></dt> 388 389<dd>If you get any such message from the preverifier, you are probably working 390 on a platform with a case-insensitive file system, such as Windows. The 391 <code>preverify</code> tool always unpacks the jars, so class files with 392 similar lower-case and upper-case names overwrite each other. You can use 393 ProGuard's <a 394 href="usage.html#dontusemixedcaseclassnames"><code>-dontusemixedcaseclassnames</code></a> 395 option to work around this problem. 396 <p> 397 If the above doesn't help, there is probably a bug in the optimization 398 step of ProGuard. Make sure you are using the latest version. You should 399 be able to work around the problem by using the <a 400 href="usage.html#dontoptimize"><code>-dontoptimize</code></a> option. You 401 can check the bug database to see if it is a known problem (often with a 402 fix). Otherwise, please report it, preferably with the simplest example on 403 which you can find ProGuard to fail.</dd> 404 405</dl> 406 407Note that it is no longer necessary to use an external preverifier. With the 408<a href="usage.html#microedition"><code>-microedition</code></a> option, 409ProGuard will preverify the class files for Java Micro Edition. 410<p> 411 412<a name="runtime"> </a> 413<h2>Problems at run-time</h2> 414 415If ProGuard runs fine, but your processed application doesn't work, there 416might be several reasons: 417 418<dl> 419<dt><a name="stacktraces"><b>Stack traces without class names or line numbers</b></a></dt> 420 421<dd>If your stack traces don't contain any class names or lines numbers, 422 even though you are keeping the proper attributes, make sure this debugging 423 information is present in your compiled code to start with. Notably the Ant 424 javac task has debugging information switched off by default.</dd> 425 426<dt><a name="noclassdeffounderror"><b>NoClassDefFoundError</b></a></dt> 427 428<dd>Your class path is probably incorrect. It should at least contain all 429 library jars and, of course, your processed program jar.</dd> 430 431<dt><a name="classnotfoundexception"><b>ClassNotFoundException</b></a></dt> 432 433<dd>Your code is probably calling <code>Class.forName</code>, trying to create 434 the missing class dynamically. ProGuard can only detect constant name 435 arguments, like <code>Class.forName("mypackage.MyClass")</code>. For 436 variable name arguments like <code>Class.forName(someClass)</code>, you 437 have to keep all possible classes using the appropriate <a 438 href="usage.html#keep"><code>-keep</code></a> option, e.g. "<code>-keep 439 class mypackage.MyClass</code>" or "<code>-keep class * implements 440 mypackage.MyInterface</code>".</dd> 441 442<dt><a name="nosuchmethodexception"><b>NoSuchMethodException</b></a></dt> 443 444<dd>Your code is probably calling something like 445 <code>myClass.getMethod</code>, trying to find some method dynamically. 446 Since ProGuard isn't detecting this (yet), you have to keep the missing 447 method in using the appropriate <a 448 href="usage.html#keep"><code>-keep</code></a> option, e.g. "<code>-keep 449 class mypackage.MyClass { void myMethod(); }</code>".</dd> 450 451<dt><a name="missingresourceexception"><b>MissingResourceException</b> or <b>NullPointerException</b></a></dt> 452 453<dd>Your processed code may be unable to find some resource files. ProGuard 454 simply copies resource files over from the input jars to the output jars. 455 Their names and contents remain unchanged, unless you specify the options 456 <a 457 href="usage.html#adaptresourcefilenames"><code>-adaptresourcefilenames</code></a> 458 and/or <a 459 href="usage.html#adaptresourcefilecontents"><code>-adaptresourcefilecontents</code></a>. 460 <p> 461 Furthermore, directory entries in jar files aren't copied, unless you 462 specify the option <a 463 href="usage.html#keepdirectories"><code>-keepdirectories</code></a>.</dd> 464 465<dt><a name="invalidjarfile"><b>Invalid or corrupt jarfile</b></a></dt> 466 467<dd>You are probably starting your application with the java option 468 <code>-jar</code> instead of the option <code>-classpath</code>. The java 469 virtual machine returns with this error message if your jar doesn't 470 contain a manifest file (<code>META-INF/MANIFEST.MF</code>), if the 471 manifest file doesn't specify a main class (<code>Main-Class:</code> ...), 472 or if the jar doesn't contain this main class. You should then make sure 473 that the input jar contains a valid manifest file to start with, that this 474 manifest file is the one that is copied (the first manifest file that is 475 encountered), and that the main class is kept in your configuration,</dd> 476 477<dt><a name="invalidclassexception2"><b>InvalidClassException</b>, <b>class loading error</b>, or <b>verification error</b> (in Java Micro Edition)</a></dt> 478 479<dd>If you get such an error in Java Micro Edition, you may have forgotten to 480 specify the <a 481 href="usage.html#microedition"><code>-microedition</code></a> option, so 482 the processed class files are preverified properly.</dd> 483 484<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> 485 486<dd>If you get such a message in a Motorola or Sony Ericsson phone emulator, 487 it's because these emulators don't like packageless classes and/or 488 overloaded fields and methods. You can work around it by not using the 489 options <code><a href="usage.html#repackageclasses">-repackageclasses</a> 490 ''</code> and <a 491 href="usage.html#overloadaggressively"><code>-overloadaggressively</code></a>. 492 If you're using the JME WTK plugin, you can adapt the configuration 493 <code>proguard/wtk/default.pro</code> that's inside the 494 <code>proguard.jar</code>.</dd> 495 496<dt><a name="failingmidlets"><b>Failing midlets</b> (on a Java Micro Edition device)</a></dt> 497 498<dd>If your midlet runs in an emulator and on some devices, but not on some 499 other devices, this is probably due to a bug in the latter devices. For 500 some older Motorola and Nokia phones, you might try specifying the <a 501 href="usage.html#useuniqueclassmembernames"><code>-useuniqueclassmembernames</code></a> 502 option. It avoids overloading class member names, which triggers a bug in 503 their java virtual machine. 504 <p> 505 You might also try using the <a 506 href="usage.html#dontusemixedcaseclassnames"><code>-dontusemixedcaseclassnames</code></a> 507 option. Even if the midlet has been properly processed and then 508 preverified on a case-sensitive file system, the device itself might not 509 like the mixed-case class names. Notably, the Nokia N-Gage emulator works 510 fine, but the actual device seems to exhibit this problem.</dd> 511 512<dt><a name="disappearingloops"><b>Disappearing loops</b></a></dt> 513 514<dd>If your code contains empty busy-waiting loops, ProGuard's optimization 515 step may remove them. More specifically, this happens if a loop 516 continuously checks the value of a non-volatile field that is changed in a 517 different thread. The specifications of the Java Virtual Machine require 518 that you always mark fields that are accessed across different threads 519 without further synchronization as <code>volatile</code>. If this is not 520 possible for some reason, you'll have to switch off optimization using the 521 <a href="usage.html#dontoptimize"><code>-dontoptimize</code></a> 522 option.</dd> 523 524<dt><a name="securityexception"><b>SecurityException: SHA1 digest error</b></a></dt> 525 526<dd>You may have forgotten to sign your program jar <i>after</i> having 527 processed it with ProGuard.</dd> 528 529<dt><a name="classcastexception"><b>ClassCastException: class not an enum</b>, or <br><b>IllegalArgumentException: class not an enum type</b></a></dt> 530 531<dd>You should make sure you're preserving the special methods of enumeration 532 types, which the run-time environment calls by introspection. The required 533 options are shown in the <a 534 href="examples.html#enumerations">examples</a>.</dd> 535 536<dt><a name="arraystoreexception"><b>ArrayStoreException: sun.reflect.annotation.EnumConstantNotPresentExceptionProxy</b></a></dt> 537 538<dd>You are probably processing annotations involving enumerations. Again, you 539 should make sure you're preserving the special methods of the enumeration 540 type, as shown in the examples.</dd> 541 542<dt><a name="compilererror"><b>CompilerError: duplicate addition</b></a></dt> 543 544<dd>You are probably compiling or running some code that has been obfuscated 545 with the <a 546 href="usage.html#overloadaggressively"><code>-overloadaggressively</code></a> 547 option. This option triggers a bug in 548 <code>sun.tools.java.MethodSet.add</code> in Sun's JDK 1.2.2, which is 549 used for (dynamic) compilation. You should then avoid this option.</dd> 550 551<dt><a name="classformaterror"><b>ClassFormatError: repetitive field name/signature</b></a></dt> 552 553<dd>You are probably processing some code that has been obfuscated before with 554 the <a 555 href="usage.html#overloadaggressively"><code>-overloadaggressively</code></a> 556 option. You should then use the same option again in the second processing 557 round.</dd> 558 559<dt><a name="nosuchmethoderror"><b>NoSuchMethodError</b> or <b>AbstractMethodError</b></a></dt> 560 561<dd>You should make sure you're not writing your output class files to a 562 directory on a platform with a case-insensitive file system, such as 563 Windows. Please refer to the section about <a 564 href="#disappearingclasses">disappearing classes</a> for details. 565 <p> 566 Furthermore, you should check whether you have specified your program jars 567 and library jars properly. Program classes can refer to library classes, 568 but not the other way around. 569 <p> 570 If all of this seems ok, perhaps there's a bug in ProGuard (gasp!). If so, 571 please report it, preferably with the simplest example on which you can 572 find ProGuard to fail.</dd> 573 574<dt><a name="verifyerror"><b>VerifyError</b></a></dt> 575 576<dd>Verification errors when executing a program are almost certainly the 577 result of a bug in the optimization step of ProGuard. Make sure you are 578 using the latest version. You should be able to work around the problem by 579 using the <a href="usage.html#dontoptimize"><code>-dontoptimize</code></a> 580 option. You can check the bug database to see if it is a known problem 581 (often with a fix). Otherwise, please report it, preferably with the 582 simplest example on which ProGuard fails.</dd> 583 584</dl> 585 586<hr> 587<address> 588Copyright © 2002-2009 589<a href="http://www.graphics.cornell.edu/~eric/">Eric Lafortune</a>. 590</address> 591</body> 592</html> 593