Importing sources (?)
Tom Tromey
tromey@cygnus.com
Mon Nov 27 14:01:00 GMT 2000
Jeff> Class registration takes longer too.
Good point, I hadn't thought of that.
Jeff> Unfortunately this is eroding one of gcj's compelling
Jeff> advantages: small-footprint executables that load extremely fast
Jeff> (compared to VM's at least). The solution may be some sort of
Jeff> finer-grained control over object linking.
Long term I'd like to see libgcj be very configurable at compile
time. Making this work well probably requires a lot of work (both
design and implementation).
One step along the way would be selective linking ("section GC"),
which g++ already does. We've talked about this numerous times but
never had the time to implement it.
Jeff> Some packages, like javax.servlet and javax.ejb, aren't defined
Jeff> in J2SE at all so building these should be optional if they are
Jeff> in the libgcj tree.
I agree. In fact they probably should just not appear. Instead we
should just use them as periodic sanity checks: run them through the
compiler just to make sure we can compile them. (For instance if we
got automatic test builds set up again javax.servlet would make a good
test case.)
Jeff> How about embedded users? Does static linking still yield a
Jeff> reasonable-sized executable?
Static linking is probably broken in some ways right now. I think the
default boot process wants to load some classes via Class.forName --
classes which aren't referenced by any other means (and thus not
linked in).
So to static link you have to find these classes and pass `-U' options
for the appropriate symbols to the linker. This is ugly and hard to
use.
It has been this way for a while now.
Tom
More information about the Java
mailing list