Scanning multi version jars?

[Greg Wilkins]

Paul,

yeh... I guess I concede it's not JarFiles job... as much as that would
make things easier for containers to reach agreement:(

However, can we at least look at having a new default method on JarEntry to
query the version. Without that, containers don't have the information
available to perform the semantic filtering required and thus will not be
able to use the stream API and will have to work from an unversioned stream.

regards

On 19 September 2017 at 03:04, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> I agree with Alan here, we should not be pushing a semantic understanding
> of inner classes into JarFile.
>
> I do sympathise with the case of annotation class scanning, which has
> always tunnelled through the class loader view to directly get at class
> file bytes possibly dealing with various URI schemes, since that is
> currently the only effective way of accessing the required information in
> an efficient manner.
>
> As Alan mentioned we should add a traversable versioned view of a JarFile,
> returning a Stream, from which it should be possible to filter according to
> certain semantics.
>
> Paul.
>
>
> > On 17 Sep 2017, at 12: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