Scanning multi version jars?

[Alan Bateman]

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