Scanning multi version jars?

[Greg Wilkins]

Alan,

thanks for correcting me on the API of JarFile - I can see it kind of
works, but in a very bizarre way (it gives different content for entries
obtained via the enumerator vs the getJarEntry API, even though both
entries report the same name).  But I'll discuss that elsewhere.



The main issue still remains is that it is entirely unclear what files we
should scan.   I understand the nuanced point that you are trying to make,
ie "that it depends"  on if the class is public or private, if it is an API
change, if it is an alternate implementation rather than a new version of
the same library etc. etc.  I also totally understand that there are
intended uses and unintended uses for this feature.

However, as an implementer of an application container, it does not matter
if I understand the nuances of MR jars and intended usage.  What matters is
do the developers of the 3rd party jars that will be deployed in my
container understand those nuances?    We have to look at jars that are
supplied by third parties, with various levels of understanding, perhaps
with some tricky clever ideas how to mess with the system, and we have to
decide which classes we are going to scan for annotations.

This is NOT a performance issue.  It is a consistency/portability issue. We
have to make exactly the same decisions as all the other application
containers out there, else 3rd party library jars will act differently on
different containers.

Thus it looks like we need some kind of heuristic to guess what the 3rd
party developer intended when they used the MR feature.    Some approaches
will need us to scan all the outer and inner classes to determine if the
inner classes are referenced and if they are public or private.

The heuristic could then be to analyse an inner class IFF it is public and
referenced.    Or perhaps that should be if it is public OR referenced?

Alternately, can we just have an heuristic based only on the index.  If Foo
exists as a versioned class, then only similarly versioned Foo$Bar classes
should be scanned and base Foo$Bar classes will be ignored?

All of these are possible.  But we need an official documented (perhaps
tool enforced) policy so that all containers can implement the same
heuristic so that we can have portability.

Ideally, the containers would not need to implement this heuristic, as it
would be implemented in the enumerator of JarFile.  Unfortunately that is
not the case and the enumerator returns all the entries regardless of
version.   So containers must implement their own enumeration and we need
to make sure we all implement it the same!

regards





On 14 September 2017 at 20:44, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 14/09/2017 10:58, Weijun Wang wrote:
>
>> :
>> I know an MR jar allows you to shadow a class file with a
>> release-specific one, but what if the new release has removed an old class?
>> It will not appear in the release-specific directory but still exists in
>> the root. Should we describe this in the MANIFEST?
>>
>> A MR JAR is not intended to support multiple versions of the same
> library, instead the versioned sections are for classes that take advantage
> of newer language or API features. They help with the migration from using
> JDK internal APIs to supported/standard APIs for example. So I don't think
> it should be complicated by an additional list of entries to "hide" in the
> base or overlaid version sections.
>
> Greg's mail doesn't say if Bar is public so I can't tell if his example
> involves an attempted API change or not. Assuming Bar is not public then
> compiling the 9 version of Foo.java will generate Foo.class and no
> Foo$Bar.class. This doesn't mean it's completely orphaned of course as
> there may be other classes in the base section, and in the same package,
> that were compiled with references to Bar. The `jar` tool could do some
> additional validation to catch these references and so avoid
> IncompatibleClassChangeError at runtime (as might arise if
> getEnclosingClass were invoked on the inner class). That would help with
> Greg's annotation scanning scenario too.
>
> -Alan
>



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