We are a bit concerned with providing reasonable support for annotation scanning in java 9 multi version jars.
We are already seeing these jars in our java 8 deployments (from some logging frameworks), so we are having to update our scanning to ignore the versioned classes (as they can't be java 8).
However, we want to update our scanning to support running on java 9, but just cannot work out a good algorithm for doing so, specially when confronted with inner classes.
A multi versioned jar might contain something like:
So 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??
So it looks like we are going to need to analyse the actual Foo class version used to see if Foo$Bar is referenced and only then scan Foo$Bar for annotations (and recursive analysis for Foo$Bar$Bob class )! It means that given the index only of a jar, it is impossible to come up with the list of classes that will be provided by that jar for a given JVM! The only 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.
Is this something the other containers are assuming (ie if there is no META-INF/versions/9/org/example/Foo$Bar.class, then the inner class is not used by the versioned outer class and thus do not scan org/example/Foo$Bar.class)?
Or are we going to have to engage in code analysis just to determine which classes we need to analyse for annotations?