Scanning multi version jars?

[Alan Bateman]

On 13/09/2017 23:12, Greg Wilkins wrote:
> I hope this is the right group for this question. please redirect me if not.
Probably core-libs-dev as this isn't anything to do with modules but in 
any case ...

>
> The Jetty project is trying to implement annotation scanning for multi
> version jars and have some concerns with some edge cases, specifically with
> inner classes.
>
> A multi versioned jar might contain something like:
>
>     - org/example/Foo.class
>     - org/example/Foo$Bar.class
>     - META-INF/versions/9/org/example/Foo.class
>
> It is clear that there is a java 9 version of Foo.  But what is unclear is
> the inner class Foo$Bar?  Is that only used by the base Foo version? or
> does the java 9 version also use the Foo$Bar inner class, but it didn't use
> any java 9 features, so the base version is able to be used??
>
> It is unclear from just an index of the jar if we should be
> scanning Foo$Bar for annotations.  So currently it appears that we have to
> actually scan the Foo class to see if Foo$Bar is referenced and only then
> scan Foo$Bar for annotations (and recursive analysis for any Foo$Bar$Bob
> class )!
Is Foo$Bar public and part of org.example's API? If so then I would 
expect compiling the 9 version of Foo.java will generate a class file 
for each of the inner classes and so the scenario shouldn't arise.  If 
Foo$Bar is not public (and so not part of org.example's API), and you 
scanning non-public classes, then it would need special handling and 
examination of the InnerClasses attribute in both classes. I wouldn't 
expect it will arise too often to cause a performance issue (assuming 
that is the concern).

>
> PS. The JarFile.getEntry method does not appear to respect it's javadoc
> with respect to multiversioned jars: it says it will do a search for the
> most recent version, however the code indicates that the search is only
> done if the base version does not exist.  This is kind of separate issue,
> but makes it difficult to defer the behaviour of what to scan to the
> implementation in JarFile
getEntry/getJarEntry will return a JarEntry if it is present in the base 
section or a versioned section (<= max version you specified when 
opening the JarFile) or both. I agree the javadoc is a bit confusing and 
could be improved but I assume you don't actually have an issue here as 
the JarEntry returned will locate the entry in the versioned section if 
it exists.

-Alan