This is the mail archive of the
java-discuss@sources.redhat.com
mailing list for the Java project.
Re: Importing sources (?)
- To: "green at cygnus dot com" <green at cygnus dot com>
- Subject: Re: Importing sources (?)
- From: Jeff Sturm <jeff dot sturm at appnet dot com>
- Date: Mon, 27 Nov 2000 12:31:59 -0500
- CC: "'Mo DeJong'" <mdejong at cygnus dot com>, "java-discuss at sourceware dot cygnus dot com" <java-discuss at sourceware dot cygnus dot com>
- Organization: Commerce One
- References: <01C05801.64D583E0.green@redhat.com>
- Reply-To: jeff dot sturm at commerceone dot com
Anthony Green wrote:
> This doesn't solve the build time problem, but I don't think there's any way
> around this. It doesn't compare with glibc yet, but it's still getting pretty
> big. If we import the org.omg classes, that's an extra ~800 files right there!
GCC users who do a full checkout are going to get a lot of sources they don't
necessarily want. I don't see that as a problem, but can imagine that somebody
will complain.
The libgcj.so shared object continues to grow, creating a rather large memory
footprint for some very simple Java programs. Class registration takes longer
too. Unfortunately this is eroding one of gcj's compelling advantages:
small-footprint executables that load extremely fast (compared to VM's at
least).
The solution may be some sort of finer-grained control over object linking.
Some packages, like javax.servlet and javax.ejb, aren't defined in J2SE at all
so building these should be optional if they are in the libgcj tree.
How about embedded users? Does static linking still yield a reasonable-sized
executable?
--
Jeff Sturm
jeff.sturm@commerceone.com