Reducing the size of a j2me jar

In J2ME application development , the size of the j2me application jar file is very important as the application has limited resources in mobile devices. Below you can see some of the points would help you to reduce the size for the jar.

Some points for j2me jar size reduction

There are many ways to reduce the size of your wireless Java application.

* Keep it simple. Simplicity of design can yield robustness, speed, and efficient use of space.
* Recompute rather than store. Recomputing a value rather than storing it for later retrieval can save space. As an example consider the following code fragment:
* Choose an elegant data structure to store information. You should always consider your options for a data structure to store your information on the device.
* Remove unnecessary classes. One way to "keep it simple" is to review your application design and eliminate classes that are not actually needed.
* Reduce functionality and features. Is all the functionality you've planned actually needed?
* Avoid inner classes. Many programmers use inner classes, to implement event listeners for example. Convenient, but behind the scenes the compiler generates special instructions to allow the inner class to access the outer class's private data.
* Avoid deep inheritance hierarchies. Although the benefits of inheritance (such as software reuse, increased reliability, and code sharing) are great, nothing is without cost of some sort, including inheritance. Programs must use memory and time to construct fields inherited from a base class even when the derived class makes no use of them. When a method is invoked and it is not part of the derived class, its immediate superclass will be searched; if that class doesn't define the method, its superclass will be searched, and so on. All that extra message passing adds bulk to the bytecode and steals processor time. If a class doesn't use most of the resources it inherits from the base class, it's better to reimplement the resources it does use, instead of inheriting them.
* Avoid using inheritance when it isn't necessary. For example, if you wish to use multiple threads, implement the Runnable interface rather than extending the Thread class.
* Use short names for classes, methods, and fields. Savings from abbreviating any one name aren't dramatic, but they add up. An automated way to get shorter names is to use obfuscation tools. Although their primary intent is to make it harder for a competitor to reverse-engineer your application by decompiling your .class files into easily read .java files, obfuscators also reduce code size by shortening names. There are several obfuscators available, but you may want to try RetroGuard, which is available for free. You can use this obfuscator from the J2ME Wireless Toolkit.

* Take advantage of resource-processing tools that reduce PNG resolution and color depth. Many devices are capable of displaying only a few colors per pixel, so creating images with many colors per pixel may increase your app's memory footprint without adding any value to it. You may also want to reduce the dimensions of the image.
* Don't include unnecessary images. Why use memory for images that don't enhance your application?
* Eliminate access methods. Get and set methods can cause your application to run more slowly than if it accessed member variables directly, and they increase program size. Once again, though, it is all about trade-offs.
* Refactor. As applications evolve over time, they often become less space-efficient. Sometimes the best way to save space is to refactor the application, with space-efficiency as a high-level design goal.
* Minimize object creation. Object creation consumes memory and processor cycles, and leads to object destruction, which further reduces performance. Look for ways to reuse existing objects rather than create new ones.
* Avoid string concatenation. It is well known that concatenating objects with the + operator causes object creation and subsequent garbage collection, and thus chews up both memory and processor time. It is more efficient to use StringBuffer. Note, however, that merely switching from concatenation to use of StringBuffers is not always sufficient because of the way arrays are reallocated. Inefficiencies arise, chiefly because the default character buffer for StringBuffer is 16, and when the buffer is full a new one (usually twice the size of the original) must be allocated. Once the content is copied to the new one, the old buffer is released. This frequent reallocation can be avoided if you create a StringBuffer big enough to hold the longest string you're likely to store.

This information was captured form Sun developer network. Click here for the full article.