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.