Scanning multi version jars?
peter.levart at gmail.com
Fri Sep 22 14:11:16 UTC 2017
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.
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...)
More information about the core-libs-dev