gcj executable size reduction?

Fri Apr 16 11:50:00 GMT 2004

Hi Boris,
Boris Kolar wrote:
>>I've also used jikes in the past, to compile java.lang.Object and let it
>>drag in all the dependencies automatically. It mostly works, as far as I
>>recall. It's a rather quick way to figure out the 'resident size' of
>>your class library.
>>> Wouldn't that also include "private" dependancies (dependancies in
> private methods,...)?

Yes.
> I think it wouldn't be that difficult to use reflection to determine
> public+protected dependancies of an object. These "public"
> dependancies can't be removed unless you are willing to sacrifice
> compliance with standards. But I guess removing private dependancies
> would help a lot.

Usually the private methods are used to implement the public ones. For 
example, when several of your public methods need to do A, then 
refactoring A into a private method of its own helps clean up the code.
Doing the jikes thing above, for example, results in a core rt.jar for 
kaffe [1] that's about 600k, whereas the normal rt.jar for kaffe is 
around 3 megs. Of course, chances are that in this 600k there is some 
necessary stuff missing, which is required to run actual programs; like 
localization or character conversion ressources, or classes only loaded 
through reflection.
But it provides a quick starting point for such 'prune down the class 
library to bare necessities' applications for embedded users. It was 
what I used when I added support for class library profiles in kaffe.
cheers,
dalibor topic
[1] Not that kaffe doesn't use the same libraries that gcj uses, so the 
actual results on gcj's class libraries may be different.