This is the mail archive of the
java-discuss@sources.redhat.com
mailing list for the Java project.
Re: Importing Sources (?)
- To: Java/GCJ List <java-discuss at sourceware dot cygnus dot com>
- Subject: Re: Importing Sources (?)
- From: Mojo Jojo <david-b at pacbell dot net>
- Date: Tue, 28 Nov 2000 10:42:00 -0800
Tom Tromey opened the floodgates with:
> Today I started trying to build a tree that includes both libgcj and
> other free software Java pieces. My particular tree includes parts of
> Cryptix and javax.servlet. However, there are other bits out there:
> SAX/XML stuff, audio stuff, and CORBA (at least).
>
> Assuming licensing problems can be worked out, and assuming that we
> can get the blessing of the package developers, do you think it would
> be worthwhile to import packages like this into libgcj?
In some cases, yes. But how to choose what APIs go into the "core",
which is to say into "libgcj"? Even if we had Free implementations
of all the J2EE APIs, I'd vote against them going into libcj because
they don't belong in any "most applications need these" API profile.
Micro Edition (J2ME) APIs seem a lot more like a "core" profile;
even the standard JDK (J2SE) is a bit fat. I'd also vote against
just shipping interfaces, without implementations to back them.
Maybe the real issue is how to get GCJ-enabled versions of lots of
such libraries, and how they'll get distributed. It'd be fine (IMHO)
for applications to link against multiple libraries -- but as some
folk have implied, we need conventions for how to build such things,
analagous to the "configure/make/install" of most C software. And
then there are the testing issues ... :-)
I for one would be willing to sign over some good GPL'd SAX2/XML code,
that's fast and conformant. Stable, and even the validation is proven.
(This was the first stuff I ever got going with GCJ!) Even Sun looks
to finally be getting around to bundling such code in the next JDK,
meeting the suggestion that GCJ should only have JDK-ish APIs.
- Dave