Scanning multi version jars?

Alan Bateman Alan.Bateman at
Tue Sep 19 07:34:18 UTC 2017

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.


More information about the core-libs-dev mailing list