Re: I can make your gcj-compiled binaries much smaller.

[Andrew Haley <aph at redhat dot com>]

Adam Megacz writes:
 > 
 > Andrew Haley <aph@redhat.com> writes:
 > > I don't see how this can work, because you don't know what libraries
 > > might have dependencies that they resolve by reflection.  Even the gcj
 > > startup code does this.
 > 
 > You have this problem whenever you link statically, whether you use my
 > technique or not.

Indeed yes, which is why static linkage doesn't work either.

 > The solution is to make a reference like this:
 > 
 >    static final class foo = TheClassThatIsReferencedByReflection.class;

Well, kinda sorta.  The problem is that interfaces like 

   java.security.MessageDigest.getInstance ("MD5");

don't translate into static class references in any obvious way.  

I reckon that to make this example work you'd need a reference to
gnu.java.security.provider.MD5, but I can't be sure without trying it.
However, you don't really want your program to specify
gnu.java.security.provider.MD5 because that is not an exported class
and its name may change.  What if, for example, the target class is
package private?  

As far as I understand (although I've enver used it) Sun has a system
whereby a Java runtime is built from a number of modules, so at build
time you get to specify what you need.  This avoids these problems.

We would need to find those classes in libgcj that are resolved by
reflection and find a reasonable way to force them to be linked.
However, I don't think we should get into the situation where libgcj
contains static class references "in order to make static linkage
work."  This is, to say the very least, bad software engineering
practice and might well lead to all kinds of support headaches.

Andrew.