Protecting Code

As you probably already know, Java class files aren't very well protected from being decompiled. Plenty of free Java class file decompilers (such as Jode and Jad) can decompile your class files into Java files, and even show the original method and field names, all with the click of a button. If your game is open source, this isn't an issue. But there are a few reasons why you might want to protect your code, such as to prevent cheating in multiplayer games or to protect your work from being copied and used by others. One way to protect code is to create your own class-encryption mechanism. However, you still need to create a "bootloader" class to actually decrypt everything. This bootloader class could be decompiled, which is a problem: If the decryption methods can be decompiled, the class files can be decrypted and decompiled outside the game. Although it's not a secure solution, it would make it harder for the game to be decompiled. An imperfect but very useful way to protect code is to use an obfuscator. An obfuscator mangles class names, method names, and field names, with the idea that the resulting class file, if decompiled, would be extremely difficult to read and comprehend (though not impossible). For example, an obfuscator would take some code that looks like this:

public int getSecretValue(int code) {
 return translator[code];
}

and mangle it into something like this:

public int a(int a) {
 return b[a];
}

Of course, obfuscators mangle these names in ways that still produce valid Java code—the VM won't think the class file is broken. A couple issues arise with obfuscation, however. For example, using Class.forName() to get a class by its name won't work anymore. Also, you should be careful not to obfuscate public APIs that plug-ins or scripts use. Another advantage of obfuscators is that they can dramatically shrink class size, making them smaller for distribution. Some useful obfuscators include ProGuard (free) and DashO (commercial).