Late I spoke with Rege Wagner in person about GNU classpath and other free software to run them on some PDA device like the iPaq. We both agreed that the glibj.zip from GNU classpath e.g. used by jamvm is way too big for small devices with 8MB or 16MB of RAM. Now I thought about this a bit and found three possible ways to reduce the size:
1) Removing of unused stuff.
2) Obfuscating/shrinking stuff that is not in the public API.
3) Using a different format to store the classes.
Point 1 is relatively easy to describe: remove all classes from glibj.zip that you don’t need at runtime, e.g. remove javax.swing.* when you don’t wanna run Swing applications. I will try to make this easy with the GNU classpath build system soon. My idea is to use some kind of profiles on what classes should be put into glibj.zip. With these profiles the user then gets only what he asked for. Another approach to this might be to use annotations and process the code with an annotation processing tool. This can reduce the size too and has the net effect that you can remove some stuff from classes instead of using the whole class or removing it completely. We don’t have such a tool yet in out toolchain. Any volunteers?
Point 2 is relatively easy to to. You just call proguard on glibj.zip and tell it what stuff should be obfuscated/shrinked and what not. As I currently use proguard a lot currently at work I know its advantages and disadvantages. I will publish some isntructions in my blog in some time. What this works really well we can adopt this in our build system.
Jar/zip is a really ineffective file format to store stuff inside. There better ways to store files inside a file and load it into memory at runtime. The problem with most formats is that you need some information in memory that are needed for extraction. Better compression algorithms need normally more CPU and/or memory to decompress stuff. We need to investigate this and perhaps support different formats like tar.gz and tar.bz2 to store the class files and resources provided by GNU classpath. Another problem is that our runtimes need to support the formats. I will experiment with jamvm a bit and implement decompression from different formats in it.