Jason Salas' WebLog

On-air and online: making people laugh, making people think, pissing people off

Sponsors

ASP.NET sites that kick ass

Pals with blogs

Podcasts I listen to

Java "trick"? - Using an obfuscator to compact source code in mobile apps

I'm reading APress' book on embedded Java development, "Beginning J2ME - From Novice to Professional", which I'm thoroughly enjoying (review forthcoming).  In the book's second chapter, authors Sing Li and Jonathan Knudsen discuss the importance of compacting source code for a MIDlet-based mobile application to ensure efficient program execution.  One of the tips they recommend for doing so is to use an obfuscator to rename classes, data members, and methods - and in so doing reducing the total amount of code to be interpreted, compiled, and ultimately executed within the JAR.  This leads to better performance.

This is something I've not thought about before.  In my work with smart client development using .NET, I've been taught to use such tools to protect code, shielding it from reverse-engineering encounters.  Further, I've heard of people obfuscating their source code to intentionally screw-up decompilers.  But even in my research into MMIT and the .NET Compact Framework, I'd not heard of this being mentioned before.  Maybe .NET's just that good that this isn't so much of a concern, and/or maybe Java's got memory leak/consumption tendencies.  Depends whom you ask, I guess.

Although the RAM/ROM occupancy concerns would obviously be much less for an app running on the desktop, the same concept surely can be applicable in non-mobile environments.  This is a neat little trick I hadn't considered, so I'm shelving it in Ye Olde Mental Rolodex for future use.

Posted: Jul 24 2005, 09:29 PM by guam-aspdev | with 5 comment(s)
Filed under:

Comments

Thomas Tomiczek said:

It is o fless concern. .NET still is of no relevace to programming mobile phones at large. Not enough phones around with .NET.

The trick is old - it has nothing to do with any sort of compiler effectiveness. It is just that "a" is a shorter name than "_CustomerName". By renaming variables to shorter equivalents (which is what obfuscators do) you save space - savings that a compression can only handle in storage, but not at runtime. Latest in memory variable names (necessary for reflection) are taking space. And if you try to get your game running under 100kb, this CAN be an issue.

The compact framework is just not relevant here at all - at least for the moment - so the "right" people just never use it and start thinking about it.

::Although the RAM/ROM occupancy concerns
::would obviously be much less for an app
::running on the desktop, the same concept
::surely can be applicable in non-mobile
::environments.

Hardly, and if, then only with academic relevance. When you start measudring program size in megabytes, saving some bytes is less relevant.
# July 24, 2005 6:38 AM

Jason Salas said:

Hi Thomas,

Thanks for your comments! Very helpful. Is it therefore safe to say that not only because there aren't enough phones that can use .NET-developed embedded apps, but also because they're typically smart phones or PDAs, they're better equipped to process such apps and don't have the spec concerns that other micro devices might have?
# July 24, 2005 6:56 AM

JosephCooney said:

Hi Jason - I thought about this a while ago and did some measuring. It looks like they could have saved about 100K over the whole CF 1.0. Here is a link:

http://jcooney.net/archive/2004/10/21/171.aspx
# July 24, 2005 9:41 AM

Daniel Moth said:

Search for obfuscators with netcf and you'll find most of them have issues with v1.0

The one(s) that work, tend to generate larger assemblies!
# July 24, 2005 11:08 AM

Thomas Tomiczek said:

::Is it therefore safe to say that not only
::because there aren't enough phones that can
::use .NET-developed embedded apps, but also
::because they're typically smart phones or
::PDAs, they're better equipped to process
::such apps and don't have the spec concerns
::that other micro devices might have?

I do not think so. The issue is that people simply do not develop for .NET phones. The market is too small. Look at all the handy games - they are in Java.

It IS safe to say that if people WOULD develop for .NET, it would be an issue, but one that is less grave, as .NET hardware would typically be more powerfull. The issue that it is not an issue wright now is totally dependant on the development not being there. If I dmake something for phones, Javaa is the standard platform. It is established.
# July 24, 2005 12:50 PM
Leave a Comment

(required) 

(required) 

(optional)

(required)