| When using ProGuard, you should be aware of a few technical issues, all of | |
| which are easily avoided or resolved: | |
| - For best results, ProGuard's optimization algorithms assume that the | |
| processed code never **intentionally throws NullPointerExceptions** or | |
| ArrayIndexOutOfBoundsExceptions, or even OutOfMemoryErrors or | |
| StackOverflowErrors, in order to achieve something useful. For instance, it | |
| may remove a method call `myObject.myMethod()` if that call wouldn't have | |
| any effect. It ignores the possibility that `myObject` might be null, | |
| causing a NullPointerException. In some way this is a good thing: optimized | |
| code may throw fewer exceptions. Should this entire assumption be false, | |
| you'll have to switch off optimization using the `-dontoptimize` option. | |
| - ProGuard's optimization algorithms currently also assume that the processed | |
| code never creates **busy-waiting loops** without at least testing on a | |
| volatile field. Again, it may remove such loops. Should this assumption be | |
| false, you'll have to switch off optimization using the `-dontoptimize` | |
| option. | |
| - When obfuscating, ProGuard writes out class files named "`a.class`", | |
| "`b.class`", etc. If a package contains a large number of classes, ProGuard | |
| may also write out **"`aux.class`"**. Inconveniently, Windows refuses to | |
| create files with this reserved name (among a few other names). It's | |
| generally better to write the output to a jar, in order to avoid such | |
| problems. Alternatively, you can use the Uniform Naming Convention (UNC) for | |
| your Windows paths, which doesn't suffer from the constraint. |