This is the mail archive of the java-discuss@sources.redhat.com 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]

Re: Importing sources (?)


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

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