This is the mail archive of the java-discuss@sourceware.cygnus.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: java.net: Classpath vs. libgcj Comparison


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

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