Scanning multi version jars?

[Greg Wilkins]

Alan,

I can sympathise somewhat with that point of view, however the counter
point is that the semantics of MR jars is something that has come from a
new feature released by the JVM that was perhaps a little under specified
with regards to inner classes - probably because the JVM itself does not
need to interpret that semantic when classloader and it is only an issue
when scanning is involved.

Now that the feature has been released and is being used, it is a bit of a
tall ask to expect the disparate tool vendors, spec groups, container
implementors and general developers to come up with a common semantic
interpretation of MR jars that contain inner classes.  Specially with the
EE spec groups a bit pre-occupied with their move to eclipse.

I think my own interpretation is common sense and I'm advocating it to be
adopted by the servlet specification. But who is to say that the CDI groups
might disagree and come up with another interpretation (it's not like the
two groups can even decide on how to interpret @Resource the same way :)

If core-libs were to signal their intention to provide an implementation of
a particular semantic of inner classes in MR jars, then that would be a
great unifying action that would guide the disparate groups to a common
interpretation of the semantic  that was missing from the original
specification.

regards







On 18 September 2017 at 05:27, Alan Bateman <Alan.Bateman at oracle.com> wrote:

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



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