This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: gnu.java.locale
- From: "Erik Poupaert" <erik dot poupaert at chello dot be>
- To: <tromey at redhat dot com>
- Cc: <java at gcc dot gnu dot org>
- Date: Tue, 11 Feb 2003 12:27:45 +0100
- Subject: RE: gnu.java.locale
Brian> Would it make sense to always automatically link in a special
Brian> gnu.java.StaticLinkRequired class within libgcj when statically
Brian> linking? That way, average code will work and any further changes to
Brian> reflection requirements are located in a single location.
>>>>> We already do this in gnu.gcj.runtime.FirstThread.
>>>>> Right now we only list those required to bootstrap the runtime.
>>>>> The danger of adding more is that then you begin to counteract one of
>>>>> the benefits of static linking, namely smaller footprint.
Since I'm always amongst the first to complain about the footprints of
GCJ-compiled executables, I must definitely concede this point.
The better solution would be to establish a list of these reflection-using
classes in libGCJ, and the reflection-dependent classes that would not be
loaded, but should be, and then adapt the compiler to add hard references
only when such reflection-using class is used in the statically-linked
executable. This would be really nice to have. On the other hand, I guess
that adding such logic to the compiler, would be quite involved as an
excercise.