Scanning multi version jars?

[Greg Wilkins]

I hope this is the right group for this question. please redirect me if not.

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 )!

An alternative would be if there was an enforced convention that any
versioned class would also version all of it's inner classes - which may be
a reasonable assumption given that they would be compiled together, but we
see nothing in the specifications that force a jar to be assembled that way.

Any guidance anybody can give would be helpful.

cheers
Greg Wilkins

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






-- 
Greg Wilkins <gregw at webtide.com> CTO http://webtide.com