Decrease Jar filesize

[ardent1]

Hi, I'm wondering if anyone have some good tips on how to decrease the filesize of jar files ?

Right now i'm developing a small game and my current framework takes about 15K! Is this normal? I'm sure that image data is not the problem because my images only take about 1K.

So any tips on compiler and/or jar commands to decrease filesize or other tools would be great!

And btw:
Do you gain anything on spesify the classes you want to import instead of a general import java.some.package.* ?

Jan ge Johnsen

[Elwoodini]

Hi,

here is a forum article from another forum member (LongSteve) i found, maybe this will work for you:

------------------
05/17/02 03:48AM (7 ratings)

I've found JODE (jode.sourceforge.net) and Jax (www.alphaworks.ibm.com) to be good at code size reduction, these will often save you quite a bit. JODE is GPL too.

Here also are a few tips that have worked for me.

Use the fewest number of classes possible in your application. You really only need 2 or 3, one that extends MIDlet, one that extends Canvas and possibly a TimerTask. Lots of classes takes up lots of room in the jar file, and the preverifier adds more size to each one.

Use bytes and shorts as member variables where you can, rather than ints. Don't use booleans (which are ints), use a single int as 32 booleans!

Don't have static arrays in your code. Static arrays of anything take up lots of space in the final class file. Use a resource file of data and load that into dynamically created arrays as necessary.

Get rid of all "strings" in your code too, again, use a seperate data file and load them with a loop into an array. Reference them by index into the array in your code. This is also good for producing midlets that support multiple languages.

Believe it or not, switch statements produce more bytecodes than if/elseif statements.

If you don't mind using the Nokia UI, write a utility program that takes PNG files and produces a 'raw' data file which contains the image data in the format of the device you're coding for. TYPE_1_BYTE_GRAY for example. These data files will often compress much better in a jar file than PNGs do, thus saving you space. At runtime, load the data file into a byte [] array and use DirectGraphics.drawPixels to create Image objects.

Finally, compact all your resource files into a single data file and read the resources (array data, images, strings) using offsets into that file. The less files in the jar, the better.

Hope this helps,

Steve

Request for Clarification posted by FSTEINER on 05/17/02 07:01AM
--------------------------------------------------------------------------------
Have you any code sample that create and fill transparent imgage from byte[] ? I haven't been able to do such thing.

Comment posted by LongSteve on 05/20/02 09:20AM
--------------------------------------------------------------------------------
I will post a new topic that gives an example of creating a raw resource file from a png and using this with the Nokia UI to create Image objects.

Steve

[atomictag]

Hi all.

- There's a post on this forum about "Loading Image data from 'raw' bytes".You can find it here:
http://nkn.forum.nokia.com/devrel/threadshow.cfm?mb=3665071750056882&msg=2332258400498288&page=1

- You can also consider javax.microedition.lcdui.Image.createImage(byte[] imagedata, int imageoffset, int imagelength) instead of Nokia's drawPixel(...) if you wanna be MIDP 1.0 compatible. Some "funky" code and customization will reduce the .jar-size anyway.

- Another post on this forum about .jar file-size optimization ("What can be done to decrease JAR size?&quot:
http://nkn.forum.nokia.com/devrel/threadshow.cfm?mb=3665071750056882&msg=38853547499&page=3

- I know this is silly, but if youre using JBuilder, don't forget to set the "Debug Options" to 'none' (in the "Build" tab of your project properties) when you build your archive.

- I personally would not suggest to use a series of If/else-if statements instead of "switch-case" to optimize your code. Most of times the "switch" statement is slightly faster (even if your data types are automatically promoted to ints) especially if the numbers are close together (uses a fast direct lookup). Moreover i would not sacrifice the readability and the "constrains" of a good switch statement in most cases. I've frankly always found that substitution a messy hassle.

hope this can help
cheers

davide
<AtomicTag.com/>