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

[Brian Jones <cbj at gnu dot org>]

Mark Wielaard <mark@klomp.org> writes:

> Hi,
> 
> On Tue, 2003-01-14 at 22:38, Tom Tromey wrote:
> > >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
> > 
> > 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.
> > 
> > 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.
> 
> We also do it in case of the GNU security provider see
> gnu/java/security/provider/Gnu.java where we have for each algorithm.
> 
>   put("MessageDigest.MD5",
>       gnu.java.security.provider.MD5.class.getName());

I recently applied a patch from JRVM to Classpath that changes a
.class reference to a Class.forName() lookup so that it works with
their JVM; to me the two were essentially the same and it made no
difference.  The point I'm taking from this discussion is that the
.class syntax is helpful for static compilation and compile time
checking the referenced class name.  Should this then be a preferred
method for obtaining static references to classes within the core
library or is it a bad engineering practice?

I think it is okay to make changes such as I did as long as it does
not break other JVMs; but does this break gcj/static linking?  Patch
attached.  Btw, my paperwork should be arriving/accepted by the FSF
for GCC soon.  My goal is to help keep GCJ/Classpath in sync.

Brian
-- 
Brian Jones <cbj@gnu.org>

Attachment: resource.patch
Description: Text document