Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Use Obfuscation to Improve the Size, Performance, and Security of Your J2ME Applications : Page 2

Are you working too hard to improve the footprint and performance of your J2ME application? Perhaps you have overlooked a readily available Java tool. Obfuscation may not only help you improve the size and performance of your application, it also gives you security over your intellectual property.


advertisement
Footprint Reduction
Somewhere in your object-oriented training, you were probably taught to try to name packages, classes, methods, and fields after the real world things they represented. Instead of names like h, i, and j programmers have opted for names like com.intertechtraining.services.financial, bank_account, getInterest, and interest_level. Though this naming convention is much more human readable and much easier to later maintain or modify, it turns out that all this "natural" naming tends to bloat the byte code that ultimately goes on the devices. Just how much bloat? Results are going to vary depending on your code (how it was written, how much of it is public vs. private, etc.) and what obfuscation tool is used and how it is configured to output code. In a non-scientific experiment, I used NetBeans 4.1 to build four different projects with NetBeans obfuscator on (NetBeans used ProGaurd's obfuscator) and off. Table 1 shows the results.

Project



Description

Non-obfuscated jar size

Obfuscated jar size

% Reduction

Games

Demo MIDlet Suite provided with WTK 2.2

54.1K

38.7K

28.5%

Obex demo

Demo of Object Exchange provided with WTK 2.2

75.4K

70.7K

6.2%

Web Service Client

J2ME WS client from http://www.devx.com/wireless/Article/28046

11.2K

6.6K

41.3%

Stock Quote Suite

J2ME Stock Quote MIDlet demo from http://www.manning.com/books/white/source

16.6K

11.3K

31.9%


Table 1. Four different projects built using the NetBeans obfuscator.

As you can see, some tools report as much as 70 percent reduction and the overall results suggest that 30-40 percent is normal for most applications. While you cannot always expect to reap a 40 percent reduction in your application, there is a good chance that an obfuscator is going to get you a significant chunk of space back. This has the impact of making it easier to obtain your application over the air and the application will load into memory faster when executed. Or, use the new-found space to build even more features into that killer application.

Improve Runtime Performance
This last benefit, again, depends on your choice in obfuscator and your code structure/functionality. However, several obfuscation vendors report that their techniques of obfuscation actually help improve the performance of the application. In some cases, the performance is improved by as much as 30 percent. PreEmptive Solutions' DashO product claims to use "its comprehensive analysis to provide clues to Java runtimes so they can work better."

In fact, a new set of tools is growing up around the ideas offered by traditional obfuscators. Products such as Innaworks’ mBooster and J2ME Polish offer tools that offer to help optimize your J2ME applications beyond obfuscation.

What Does an Obfuscator Do?
In general, an obfuscator changes the byte code (the code stored in your .class files). What the obfuscator changes and how it determines what to change depends on the obfuscator implementation. There are many obfuscators and each use a variety of byte code transforming methods.

Additionally, obfuscation has changed over time. The first obfuscators (known generally as first generation obfuscators) simply changed the package, class, method, field, and variable names of your code to meaningless strings and removed any comments or debugging information. In a simplified example, all com.intertech.financial.Bank_Account objects get transformed to simple x objects. Second generation obfuscators change the actual control flow (loops, conditionals, etc.). As another simple example, an obfuscator could take a simple statement like acct.setBalance(newBalance) and wrap it with a conditional:

if (x=0) then { acct.setBalance(newBalance); } else{ //do something else }

The x=0 condition may always be true and the else portion of the statement may never get executed, but it's tough for someone looking at decompiled code to know that. The runtime outcome of control-modified code should be the same, but tracing the functionality inside a program where the control has been modified is much tougher. Finally, there is data obfuscation whereby actual data structures are altered to further confuse anyone working with decompiled code. Again, a simple example includes increasing or decreasing the size of an array that is used in the code.

Obfuscator vendors today use a combination of these methods and other proprietary methods as well. Hongying Lai has written an excellent and often-referenced paper documenting some of the obfuscation methods and comparing several Java obfuscators that were on the market at the time the article was written in February 2001.

One more thing with regard to obfuscation and J2ME CLDC applications is the consideration of obfuscation before or after preverification. Recall that in limited devices, byte code verification of classes is usually too big of an operation to be done on the devices, so class files are "preverified" or annotated with byte code "properties" when the application is built and readied for deployment. The KVM on a J2ME CLDC device checks the class files for the preverification "properties."

So, how does obfuscation that also modifies the byte codes affect this process? In most cases, obfuscation will be accomplished prior to the preverification step of your development build process. In this case, the obfuscated code is preverified and, when deployed, the KVM is none the wiser. Some tools offer options to obfuscate after preverification. This requires the preverification tool to also update the byte code properties so as not to invalidate the information already inserted by the preverification process.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap