Re: java.net: Classpath vs. libgcj Comparison

[Jeff Sturm <jsturm at sigma6 dot com>]

Per Bothner wrote:
> > java.net.InetAddress          Really liked the caching mechanism of the classpath implementation, this classpath class seems very strong, and is preferable
> >                               to the libgcj version.
> 
> Is having java.net.InetAddress do caching really a good idea?  It
> seems to me that if caching is a good idea (which it is), doing it in
> the Java library is the wrong place, since there is a good chance it
> duplicates a cache in the C library, in the kernel, or the local name
> server.  If none if these actually do caching (which would surprise
> me), then that is an suggestion that caching is not worthwhile.

I know from experience the JDK also caches name domain name lookups. 
That "feature" might be required of a conforming implementation, I don't
know... but I consider it flawed.

One problem is that the cache never expires, and consequently doesn't
obey the expiration times given in the SOA record.  One one occasion I
had a Java server process begin failing after running continuously
several months.  I found that the IP address of a remote host had
changed and java.net.InetAddress never picked up the new value.

Also there is round-robin DNS.  A proper BIND implementation should
choose one IP address at random on each query.  Instead, InetAddress
caches one address and uses it on every subsequent lookup by the Java
process.

Unless the classpath code somehow avoids these problems, I don't
recommend caching address lookups.

--
Jeff Sturm
jsturm@sigma6.com