How to reduce Java ME application size?

Question

Working with Java ME I encountered the following problem:

All classes (including anonymous) in project transforms into separated files after the project building. This leads to an increase of application size as each individual file is not less than 1 kilobyte in the assembled package.

This problem is especially critical in J2ME where the application size is so critical.

My questions are:

1. Is there a way to get around this problem?
2. Is it possible to use the specific method for reducing the size of the application?

Jayjaycee

Is your issue specific to Java ME or do you want answers for core Java too? – Dynamiter

This issue concerns the whole of Java and in particular J2ME. – Jayjaycee

Does your jar file contain anything that is not a .class file? images, audio files... we can also help shrink individual .class files if you post the source code for the largest ones. – Dalliance

@QuickRecipesOnSymbianOS Yes it does, but all media files already compressed. Also lwuit helps us to compress all files like images to single resource file. The main question concerns the compression on the level of the code. – Jayjaycee

Answer 1

So Proguard did a good job already cutting 300K from you final Jar file. Can it do more? Maybe. What settings did you use? I always go with at least:

• defaultpackage="", all obfuscated classes are moved to the default package
• overloadaggressively="true", multiple fields and methods can get the same names, as long as their arguments and return types are different
• optimizationpasses="3", number of optimization passes to be performed. This may vary from one application to another. Check the final jar size, when it does not shrink any further, stop incresing this value.

But it is very unlikely that your jar file drops to the desired 256kb you need only with proguard.

When you say that your media files are already compressed, did you use something like PNGGauntlet before adding them to lwuit?

Plumage

Answer 2

Which devices are you targeting? This used to be a problem on legacy devices years ago, but unless your MIDlet is really huge you shouldn't have too much of a problem these days. Have you actually encountered an issue, or are you seeking advice on how to prevent it in future?

You can obfuscate and reduce compiled class sizes using Proguard.

Luftwaffe

+1 for recommending Proguard. We used it on our J2ME project - it reduced a 2 MiB MIDlet JAR to less than 100 KiB. – Dynamiter

For example Samsung 3010c or 3050. Maximum jar file size for this phones is 256 kb. – Jayjaycee

ProGuard is really, really good at identifying and trimming unused dependencies. +1. – Cutworm

I use Proguard too but it's reduces application size from 800 kb to 500 kb. It's still much then 256 kb and the application cannot be installed on the old devices. – Jayjaycee

@Jayjaycee How much of the 800 KiB is third-party JAR's you're bundling with you app? – Dynamiter

We interested to support old devices up to 2005 year. We are rebuilding our j2me project with lwuit. Old build was less then 256 kb. – Jayjaycee

@Mikaveli The third-party JAR's: cldcapi11.jar, jsr184.jar and mmapi.jar. Summary size 180 kb. – Jayjaycee

They shouldn't make up part of the deployed jar as they will be on the device itself – Luftwaffe

Then it's means that we have all source without any third-part jars. – Jayjaycee