gcj executable size reduction?
Fri Apr 16 11:50:00 GMT 2004
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,...)?
> 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  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
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.
 Not that kaffe doesn't use the same libraries that gcj uses, so the
actual results on gcj's class libraries may be different.
More information about the Java