Hook in PreferredClassProvider to determine class boomerang

[Mark Brouwer <ma...@cheiron.org>]

See
http://archives.java.sun.com/cgi-bin/wa?A2=ind0608&L=jini-users&P=R7915&I=-3
and an existing RFE in the Sun bug database
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6190433

I have modified my version of PreferredClassProvider and added the
following method to it that provides the requested hook, although I'm
not satisfied so I would like to get some input.

/**
  * Indicates whether a class with the specified codebase annotation
  * <code>URL</code>s is defined within the specified class loader,
  * for the purpose of deciding whether the class originated from the
  * <code>defaultLoader</code> or that the class is considered a
  * 'class boomerang'.
  * <p>
  * This implementation will consider a class to be defined in the
  * specified class loader when the codebase annotation for that class
  * loader matches the <code>URL</code>s passed in.
  *
  * @param urls annotation <code>URL</code>s that serve as the codebase
  *        for the class being loaded
  * @param loader class loader for which must be verified whether it
  *        represents the class loader from which a class with the
  *        codebase as in <code>urls</code> could have originated
  * @return <code>true</code> when the class is defined within the
  *         class loader passed in, <code>false</code> otherwise
  */
protected boolean isClassDefinedInClassLoader(URL[] urls,
                                               ClassLoader loader) {
     try {
         return Arrays.equals(urls, getLoaderAnnotationURLs(loader));
     }
     catch (MalformedURLException e) {
         return false;
     }
}

While the above works and represent no semantic change to the current
implementation and it allows me to extend PreferredClassProvider to add
my own logic, I don't like the fact a class boomerang must be determined
based on an array or URLs while it is the codebase annotation used while
marshalling of type String that is what I keep track of in Seven.

That means that I have to create an array of URLs based on the codebase
annotation which is not that hard, but it also means I must compare an
array of URLs and the URL object I find a problematic object to perform
equals on, it can result in a match even while I never handed out a
particular codebase annotation and it can be a slow operation therefore
I don't want to do that in code might have to check a lot of these
arrays when services are deployed under many codebases (see other post).

Therefore I would like to change my current semantics and use as the
first argument a String representing the codebase instead of an array of
URLs. This means that the current implementation likely has to parse
that string into an array of URLs but there is already a cache for that
(URL[] pathToURLs(String)).

If somebody has an opinion to share it is appreciated,
-- 
Mark

Re: Hook in PreferredClassProvider to determine class boomerang

[Bob Scheifler <Bo...@Sun.COM>]

Mark Brouwer wrote:
> Looking at the specs for RMIClassLoader and RMIClassLoaderSpi I'm of the
> opinion that codebase as String is the real discriminator here for
> making decisions and that the usage of URL (instead of URI) in some of
> the language is an unfortunate choice and I would rather steer away from
> it than exposing it even more in the public API.

For public methods I agree with you.  But for a protected method
I could see avoiding the duplicate pathToURLs call by passing in both.
Not a big deal either way.

- Bob

Re: Hook in PreferredClassProvider to determine class boomerang

[Mark Brouwer <ma...@cheiron.org>]

Bob Scheifler wrote:
> Mark Brouwer wrote:
>> Therefore I would like to change my current semantics and use as the
>> first argument a String representing the codebase instead of an array of
>> URLs. This means that the current implementation likely has to parse
>> that string into an array of URLs but there is already a cache for that
>> (URL[] pathToURLs(String)).
> 
> Since it's a protected method, why not pass in both?

Looking at the specs for RMIClassLoader and RMIClassLoaderSpi I'm of the
opinion that codebase as String is the real discriminator here for
making decisions and that the usage of URL (instead of URI) in some of
the language is an unfortunate choice and I would rather steer away from
it than exposing it even more in the public API.

But I also believe that given previous discussions you are not going to
give me a high five for saying this, so if this satisfies everybody here
I'm totally fine with it.
-- 
Mark

Re: Hook in PreferredClassProvider to determine class boomerang

[Bob Scheifler <Bo...@Sun.COM>]

Mark Brouwer wrote:
> Therefore I would like to change my current semantics and use as the
> first argument a String representing the codebase instead of an array of
> URLs. This means that the current implementation likely has to parse
> that string into an array of URLs but there is already a cache for that
> (URL[] pathToURLs(String)).

Since it's a protected method, why not pass in both?

- Bob