This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Tom Tromey writes:
 > >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
 > 
 > Andrew> We would need to find those classes in libgcj that are resolved by
 > Andrew> reflection and find a reasonable way to force them to be linked.
 > Andrew> However, I don't think we should get into the situation where libgcj
 > Andrew> contains static class references "in order to make static linkage
 > Andrew> work."  This is, to say the very least, bad software engineering
 > Andrew> practice and might well lead to all kinds of support headaches.
 > 
 > We already do a little of this.  See FirstThread.java.

I know.  It's what worries me.

 > Right now I think we only do this for classes required by the startup
 > code.  The problem with us doing it in general is that it eliminates
 > an advantage of static linking, namely removing classes you really
 > don't want.

Yep.

 > The application developer can do it, as Adam suggests.  It seems to me
 > that this approach will be unreliable, though.  You can't always know
 > what classes you need to require; maybe an unusual code path requires
 > some class you omitted.

Exactly, and we run the risk of permanently restricting the way we
write classes that go in libgcj in order to be static linkage
compliant.  

Perfectly correct Classpath code won't work in libgcj if it resolves
classes by reflection.

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]