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
