Re: Relieving some ClassLoader contention in PreferredClassProvider

Bob Scheifler wrote:
>> Could you also explain why the current specified behavior is as it is?
>
> Remember that PreferredClassProvider is an RMIClassLoader provider,

I'm well aware but it is my belief that the specs for RMIClassLoaderSpi
and the static methods of RMIClassLoader don't demand the current
implementation of PreferredClassProvider, but no doubt you will correct
me when I'm wrong.

> and RMIClassLoader's use of URLs dates back to JDK 1.1 (before my time),
> before URI and perhaps before virtual hosting existed.  As to why the
> semantics hasn't been revisited since, well, I don't really recall it
> being raised as an important issue in the past.

This is very well possible as it might be most people don't change
networkaddress.cache.ttl which defaults to forever, meaning that
URL.equals() won't perform that badly and is likely fairly reliable as
all hosts used in URLs have been resolved before. But still without
knowing the actual implementation of the nameresolvers I can't say that
for sure.

However in the past there were situations where we had to change the
networkaddress.cache.ttl to small values for fail-over reasons (people
modified the DNS to redirect traffic to other servers and don't ask me
whether I liked that strategy or not) so I have been exposed to the
greater risk of the semantics of URL.equals and URL.hashCode.
--
Mark

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]