This is the mail archive of the
java-discuss@sourceware.cygnus.com
mailing list for the Java project.
Re: java.net: Classpath vs. libgcj Comparison
- To: Bryce McKinlay <bryce at albatross dot co dot nz>
- Subject: Re: java.net: Classpath vs. libgcj Comparison
- From: Jeff Sturm <jsturm at sigma6 dot com>
- Date: Tue, 18 Apr 2000 22:06:24 -0400
- CC: "Aaron M. Renn" <arenn at urbanophile dot com>, classpath at gnu dot org, gs at sevenmountains dot no, java-discuss at sourceware dot cygnus dot com
- Organization: AppNet Inc.
- References: <20000416184936.A1920@urbanophile.com> <38FA9C2D.21393C42@albatross.co.nz>
Bryce McKinlay wrote:
> These are just some arbritary examples I came up with because I happened to have the two InetAddress implementations open on my screen, but the types of issues here apply to all the
> classes that need to be merged. I jsut want to stress that merging shouldn't a case of "well take this class from libgcj, that one from classpath", but something that needs to be
> done on a lower level than that.
Having looked over the code a bit, I agree. I'm also discovering a
trend that while Classpath's Java source tends to be more polished and
complete than libgcj's Java sources, the libgcj native code in general
looks more portable and thorough.
Case in point: libgcj's java.net checks for availability of IPv6 (though
support is surely not complete) and reentrant functions gethostbyname_r,
gethostbyaddr_r.
Classpath however has very little conditional compliation in java.net,
so it relies only on functions that are widely available. For that
matter, it doesn't appear to call gehostbyname/gethostbyaddr in a
synchronized block, which must be a mistake.
Too bad CNI and JNI aren't compatible (not that I want to start that
discussion again, but... couldn't Japhar do CNI?)
--
Jeff Sturm
jsturm@sigma6.com