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
