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
