On 09/19/2017 09:34 AM, Alan Bateman wrote:
On 19/09/2017 05:37, Greg Wilkins wrote:
:

Which raises an interesting point....   with the multi versioned jar I have
used as an example, which contains:

    - org/example/Foo.class
    - org/example/Foo$Bar.class
    - META-INF/versions/9/org/example/Foo.class

What does the classloader do when asked to load "org.example.Foo$Bar" ?
  If it loads it OK, then the JarFile enumerator/iterator/stream should also
return it.   If it throws a ClassNotFoundException, then the
JarFile enumerator/iterator/stream should skip it.
A class loader that loads from a JAR file will just map "org.example.Foo$Bar" to entry "org/example/Foo$Bar.class" and attempt to define the class bytes to VM.  It shouldn't care if the entry comes from the base or a versioned section. It also shouldn't care if the class name looks like it might have been compiled from an inner class.

The one case where a custom class loader does need to know more is when it loading resources (findResource/findResources implementation usually). For that case then the returned URL needs to locate the right resource and so may encode a path to a resource in a versioned section. You'll see URLClassLoader does the right thing, as does the built-in class loaders for cases where you have modular MR JARs on the module path. There were a few threads on core-libs-dev discussing whether to add a getRealName method but in the end it was kicked down the road to re-examine later.

-Alan

Just a though,

The only problem with ClassLoader API is that it doesn't have any means to enumerate all the resources it is able to resolve. If it had such API, the code for scanning would be much simpler.

But how would such API look like if we know that resolving works by delegation, might work by lazily generating the resource with a particular path on the fly, etc... Perhaps simply by ignoring the delegation and lazy generation and just return a stream of resources that a particular ClassLoader instance is responsible for and are backed by real bytes in some repository which has a means of enumeration (like filesystem, jar file, etc...)

Regards, Peter

Reply via email to