Obfuscation is a helpful tool to reduce the size of a deployed application, prevent outsiders from stealing your work, and possibly making your application perform better. However, nothing in software engineering comes for free and you should also be aware of some potential issues when obfuscating your code.
First, make sure you thoroughly test your obfuscated code. The goal of obfuscation is to scramble your application enough to make decompiling and understanding your application difficult. Sometime, the obfuscator goes a bit too far. Today's products are good, but occasionally there are cases where the obfuscator stumbles on unforeseen code or the user is not aware of the various coding rules and configuration settings available with most obfuscators and the result is code that will not run when deployed to the device.
Platform independence may be compromised using obfuscation. For example, depending on the implementation, an obfuscator that knows about all the rich features in Java 5.0 may generate code that will not work on lesser JVMs.
Use of reflection tends to be one of the biggest obstacles in obfuscation. If you use a lot of reflection in your application, confer with the obfuscation vendor on potential issues and, in some cases, tips and tricks on how to avoid issues when the obfuscator comes in contact with reflective code.
Some methods of obfuscation actually increase the size of the application and/or reduce performance. In an exaggerated case, imagine what would happen if each line of code was surrounded by psuedo-conditional statements to effect control obfuscation? Check the size and performance of your obfuscated code to insure you are getting the benefits of obfuscation and not suffering from the opposite.
Turn to your favorite Internet search and type "Java Obfuscation" and you will find dozens of obfuscators. Click here for a list of obfuscators to get you going.
Two of the most popular open source obfuscators are ProGuard and RetroGuard. On the commercial side, PreEmptive Solution's DashO and Zelix KlassMaster Java Obfuscator are both well-touted Java obfuscators that also seem to understand and document special J2ME issues associated with obfuscation.
Most of the well known IDEs also offer built in obfuscators. NetBeans 4.1 with Mobility Pack comes with the open source ProGuard obfuscator already built in. In fact, obfuscation can be made part of the normal build process. Right click on any J2ME project in NetBeans and request properties from the resulting menu option. In the Properties window, one of the build options is "Obfuscating." You have a slide bar dial that allows you to turn obfuscation on and off and to set the level of obfuscation when on (see Figure 1). A setting of two causes just private fields and methods to be obfuscated while a setting of nine causes "everything except public methods of MIDlet classes" to be obfuscated.
Figure 1. NetBeans Obfuscation Configuration: Obfuscation is easily made part of the build process by simply setting the level of obfuscation in the project properties.
Figure 2. Stubs for Obfuscators: When not immediately available, most IDEs provide the means to add an Obfuscator, as do Eclipse and the Wireless Toolkit. The Wireless Toolkit is shown here.
Both EclipseME and the J2ME Wireless Toolkit (now called the Sun Java Wireless Toolkit with release 2.3) are equipped to use the ProGuard obfuscator as well, but ProGuard must be downloaded and configured separately. Help with how to configure the obfuscator with the Wireless Toolkit is available here.
Obfuscating the Obvious
No, obfuscation is not the panacea solution for all J2ME problems. In some cases, because the IDEs are getting much better at helping us take advantage of all available development improvement options, you may already be obfuscating and you didn't even know it. If so, great! Now you might also explore what obfuscator you are using and how you have it configured to give you optimal results.
As with all tools, a little research and some trial/error may be in order. But in J2ME, when something offers the promise of a smaller footprint, faster provisioning, possible performance enhancements, and better intellectual property security, I am hard pressed to find a reason not to at least explore it.