Re: Relieving some ClassLoader contention in PreferredClassProvider

Bob Scheifler wrote:
>> Up to this point has something passed by from which
>> I should be able to *really* conclude that you are extremely reserved
>> for such a change?
>
> I'm generally reserved about incompatible spec changes.  The change
> hasn't really been described well enough to fully evaluate (e.g.,
> what to do about MalformedURLException vs URISyntaxException).

Ok, I'm working on the version that is based on URIs in stead of URLs,
that one will also have the hook for detecting class boomerangs.

> The change seems largely motivated by a performance concern, but
> the actual performance impact is unclear to me. If you don't like
> the default semantics of URL.equals, it seems you could install your
> own URLStreamHandler(s)/URLStreamHandlerFactory to override it.

I think reliability doesn't equals performance so I would also like to
add that to the list, because many of the equals calls are within the
synchronized block. And virtual hosting is affected by the current
semantics.

The spec for java.net.URL doesn't make it obvious to me that installing
your own URLStreamHandler(s)/URLStreamHandlerFactory will alter the
behavior of equals and hashCode, peeking in the code it does. However
such a move would alter the semantics of URL all over the place and as
the relevant bug in the Sun bug database shows this is likely not
something you want as this would have security implications, among other
things. And it would be a violation of the semantics of URL itself.

But than again you didn't hear me complain about the specs of URL.equals ...
--
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]