On 15/09/2017 22:58, Greg Wilkins wrote:
:
* I think the stream needs to handle inner classes and only include
them if their matching outerclass is available at the same
version. So for example a base Foo$Bar.class will only be
included if the stream includes a base Foo.class, and it will not
be included if the Foo.class is version 9 or above. Likewise a
version 9 Foo$Bar.class will only be included in the stream if the
stream also includes a version 9 Foo.class, and will not be
included if the stream has a version 10 or above Foo.class
If you think this last point is possible, then I'll move the
discussion back the EE expert groups to try to get an agreement on the
exact stream code that will be used in the mid term until it is
available in the JRE lib, at which time the specs should be amended to
say they will defer the decision of which classes to scan the JRE lib
so they will be future proof for any changes in java 10, 11 etc.
I don't think this should be pushed down to the JarFile API. The JarFile
API provides the base API for accessing JAR files and should not be
concerned with the semantics or relationship between entries. I agree
that annotation scanning tools and libraries need to do additional work
to deal with orphaned or menacing inner classes in a MR JAR but it's not
too different to arranging a class path with a JAR file containing the
"classes for JDK 9" ahead of a JAR file containing the version of the
library that runs on JDK 8. I do think that further checks could be done
by the `jar` tool to identify issues at packaging time.
-Alan
