Scanning multi version jars?

[Peter Levart]

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