ProGuard is a free Java class file shrinker, optimizer, obfuscator, and preverifier. It detects and removes unused classes, fields, methods, and attributes. It optimizes bytecode and removes unused instructions. It renames the remaining classes, fields, and methods using short meaningless names. Finally, it preverifies the processed code for Java 6 or for Java Micro Edition.

Feature are:

• Creating more compact code, for smaller code archives, faster transfer across networks, faster loading, and smaller memory footprints.
• Making programs and libraries harder to reverse-engineer.
• Listing dead code, so it can be removed from the source code.
• Retargeting and preverifying existing class files for Java 6, to take full advantage of Java 6's faster class loading.

ProGuard is fast. It only takes seconds to process programs and libraries of several megabytes. The results section presents actual figures for a number of applications. ProGuard's main advantage compared to other Java obfuscators is probably its compact template-based configuration. A few intuitive command line options or a simple configuration file are usually sufficient. For instance, the following configuration option preserves all applets in a jar:

    -keep public class * extends java.applet.Applet

ProGuard is a command-line tool with an optional graphical user interface. It also comes with plugins for Ant and for the JME Wireless Toolkit. ProGuard is probably the most popular java shrinker, optimizer, and obfuscator world-wide. It is being used by developers at companies and organizations like Sun, IBM, HP, Siemens, Nokia, Google, and NATO. It is the default tool in many development environments like Sun's Wireless Toolkit, Netbeans, EclipseME, and more.

Benefits are:

ProGuard typically reads the input jars (or wars, ears, zips, or directories). It then shrinks, optimizes, obfuscates, and preverifies them. Optionally, multiple optimization passes can be performed, each typically followed by another shrinking step. ProGuard writes the processed results to one or more output jars (or wars, ears, zips, or directories). The input may contain resource files, whose names and contents can optionally be updated to reflect the obfuscated class names. ProGuard requires the library jars (or wars, ears, zips, or directories) of the input jars to be specified. These are essentially the libraries that you would need for compiling the code. ProGuard uses them to reconstruct the class dependencies that are necessary for proper processing. The library jars themselves always remain unchanged. You should still put them in the class path of your final application.

In order to determine which code has to be preserved and which code can be discarded or obfuscated, you have to specify one or more entry points to your code. These entry points are typically classes with main methods, applets, midlets, etc.

• In the shrinking step, ProGuard starts from these seeds and recursively determines which classes and class members are used. All other classes and class members are discarded.
• In the optimization step, ProGuard further optimizes the code. Among other optimizations, classes and methods that are not entry points can be made private, static, or final, unused parameters can be removed, and some methods may be inlined.
• In the obfuscation step, ProGuard renames classes and class members that are not entry points. In this entire process, keeping the entry points ensures that they can still be accessed by their original names.
• The preverification step is the only step that doesn't have to know the entry points.