Re: Binary size of statically linked java application

[Marco Trudel <mtrudel at gmx dot ch>]

Lehner, Michael wrote:
> Hi,
>
> I am using java on an embedded system, for that reason, memory is very
> low. This is one of the reasons why I am using statically linking. But
> this doesn't solve my problems, an unstripped "hello world" application
> still needs more than 20MB and stripping it only reduces it's size to
> about 9MB. I read about guys getting it down to 300-500kB,

micro-libgcj might be interesting for you. It's linked in the "Done with 
GCJ" wiki. Unfortunately that wiki page is quite hidden. But it will 
replace the current section on the homepage somewhen...
Here the link: http://gcc.gnu.org/wiki/Done_with_GCJ


> but not how
> they managed that or this is because this messages were sent at the
> beginning of the 21st century and classpath had several classes missing
> this time. But I can't believe that I am really using this 9MB for
> simply printing out one single line to the console. What options can a
> additionally provide to the compiler to make it leave out unnecessary
> classes?

I usually remove AWT/Swing (the whole GUI stuff) and the whole 
javax.crypto stuff. Then a real application is about 4.5mb (stripped of 
course).
After that, you can UPX (http://upx.sf.net) your binary, so it will be 
about 1.3mb. Well, UPX might be the wrong thing to do for an embedded 
system because it will unpack the binary into ram and then execute it.
You can play with it a little by using my GCJ packages: 
http://nativeJ.mtSystems.ch

But getting a 4.5mb binary instead of a 9mb one is a start, right? Just 
extract all objects from the libgcj.a and remove those objects which you 
know you don't need. Then create the libgcj.a again. You can exclude way 
more objects than only the GUI and crypto stuff... These two will just 
give you the biggest size reduction.
Of course it would be cleaner to do all that before compiling GCJ 
itself. But this way it is easier to maintain.


Marco