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
Anthony Green wrote:
> Sun's "solution" was to add an implementation specific property,
> sun.net.inetaddr.ttl, which you set to the number of seconds to cache
> addresses for (or -1 for forever).
Ick. I suppose it defaults to -1 too...
> I looked this up in Sun's bug parade a while ago because I couldn't
> believe they actually force implementations to cache in the spec.
> Perhaps this was a mistake.
There are times like this I have mixed feelings about implementing Sun's
spec to that level of detail. It seems hard to believe any user code
would rely on such caching anyway.
One item I didn't see in Gaute's comparison is any mention of IPv6
conformance. That could come in handy.
Also, java.net.SocketInputStream and SocketOutputStream are classes I
was going to propose for libgcj, since the current assumption that
sockets can be represented by FileDescriptors just isn't portable (win32
at least has a completely separate API for socket I/O).
--
Jeff Sturm
jsturm@sigma6.com