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 <gr...@webtide.com> CTO http://webtide.com
