Re: java.net: Classpath vs. libgcj Comparison

["Aaron M. Renn" <arenn at urbanophile dot com>]

Jeff Sturm (jsturm@sigma6.com) wrote:
> 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 can't remember exactly why I decided to implement caching.  I just
glanced at my implementation and discovered a few things:

It limits the number of addresses that can be cached, and also
limits the length of time an address can be cached.  The defaults
are 400 entries and 4 hours.  However, the implementation is not
complete because the purge logic is not written.

The size of the cache, the length of time to cache and entry, and
the percentage of the cache that will be purged if it fills up (default
30%) can be set by properties:

gnu.java.net.dns_cache_size
gnu.java.net.dns_cache_period
gnu.java.net.dns_cache_purge_pct

By setting the cache size to 0, caching is disabled.

I personally think that caching is a potentially useful operation.
For example, if a web page is loading many images off of the same
server, it would be nice to not have to perform DNS lookups for every
image loaded.  The browser app could cache these, I suppose, but why
should it have to?  Perhaps there's something to be said for disabling 
caching by default though, which is easy to do.

One reason not to rely on OS or native library level caching is that
this necessitates a round trip into native code, which can be very
expensive in JNI.  In the compiled libgcj environment using CNI, this
might be less of a concern.

I believe there is a free 100% Java implementation of DNS called
DNSJava, which would allow a 100% Java implementation of InetAddress.
I have not looked at this package in detail, but the homepage is
http://www.xbill.org/dnsjava/.  It is licensed under the LGPL, but
the author might allow  libstdc++ license.  This implementation also
contains caching, I noticed.  My only question is how to configure
it, which the README file indicates is via a property, with fallback
to /etc/resolv.conf and several other sources.  It might be worth a
look.  For ideas if nothing else.
 
> > 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.

I am not aware that caching is part of the spec.
 
> One item I didn't see in Gaute's comparison is any mention of IPv6
> conformance.  That could come in handy.

The Classpath implementation does not support IPv6 currently.
 
-- 
Aaron M. Renn (arenn@urbanophile.com) http://www.urbanophile.com/arenn/