Executable size problem

[Andrea aime <andrea dot aime at aliceposta dot it>]

Hi,
as you may know, I'm experimenting with gcj as a way to avoid
shipping the jre with the application.

So far I've been relatively successful (and many thanks to the
people that helped me get this far).

Now, the main problem so far is the size of the generated executables.
A "hello world" style app is 8MB (or 5, is you strip it).
I've seen that micro-libgcj can be used to generate small executables,
but most of the platform I rely on usually is stripped out (I develop
Swing apps, web apps, Eclipse RCP apps and the like usually).

I'm wondering, why every class of the standard runtime has to
be compiled into the simple hello world style app? I understand dynamic
class loading is a problem, but one should be able to provide a list
of packages/classes that are dynamically loaded without much problems
(either you know because you have written the code, or you can
get a list by running the application in testing/interactive mode
and see what classes get loaded).
This should allow to compute and strip every uneeded class from the 
executable.

Another approach could be to generate lots of dynamic libraries from
the standard runtime, using packages as a guidance (so, an AWT library,
a Swing library, a XML library, and so on). This way dll could be loaded
at runtime when needed, no? The startup time for a 30MB executable (the 
one I generated from a sample JFace application) is quite noticeable
(at least on Windows XP, I still haven't tried on Linux),
trying to compress it with upx just make things worse memory wise 
(althought it helps with disk usage and startup time as well).

Am I completely off base? Sorry for the naive questions.
Best regards
Andrea Aime