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 (?)


Mo> If you have to build everything to get libgcj, I think it would be
Mo> a bad idea. It already takes too long. On the other hand, I don't
Mo> see why you could not provide another library along with
Mo> libgcj. Call it "libjutils" or something.  It would get built and
Mo> delivered with every gcj install, but folks would need to link to
Mo> it with -ljutils. That way you still get the benefits without the
Mo> downside of confusing folks about what exactly is in libgcj.

The nice part of having it directly in libgcj is that you don't have
to set CLASSPATH when building or anything like that.  If I write a
program that uses CORBA I can use "javac" (no args) to compile it and
I can use "java" (no class path) to run it.  If we put something like
CORBA into its own .so alongside libgcj, then doing this will be
harder for gcj users than for ordinary JDK users.

But I agree bloat is a factor.

One idea is to limit libgcj to include those things that would be
included with the JDK.  So, for instance, we might include CORBA and
Cryptix, but not something like javax.servlet or the SAX/XML stuff.

As far as bloat goes, I think we should try to be careful to make new
shared objects when possible.  For instance, with java.security,
security service providers are loaded via Class.forName() and so are
good candidates for being made into their own shared objects.

Tom

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