Scanning multi version jars?

[Alan Bateman]

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