Java Modules and Multi-Release Jar

Luke Hutchison luke.hutch at gmail.com
Thu Oct 4 07:04:54 UTC 2018


On Sun, Sep 30, 2018 at 2:33 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> If you are running on JDK $N then an entry in META-INF/versions/$N will
> override an entry of the same name in versioned sections < $N as well as
> the base section. The JarFile javadoc and JEP 238 describe this in detail.
> One mental model is to think of it as a search path. If you are JDK 11 then
> search path for entries in the JAR file is:
>
>     META-INF/versions/11:META-INF/versions/10:META-INF/versions/9:.
>
> where "." is the top-level directory in the JAR file.
>
> You can also verify your understanding by trying some examples with the
> JarFile API, e.g. open the JarFile with the 4-arg constructor and use the
> versionedStream method to obtain a stream of the JAR entries and then map
> each entry to its real path with JarEntry::getRealPath. This might be
> useful to verify that your library enumerates the correct set of entries.
>

I see in JEP 238 that multi-release jars "will contain" the attribute
"Multi-Release: true". Should this "will" be interpreted as "MUST"? i.e. if
a manifest file is missing this attribute, but the jar contains some
version layers in "META-INF/versions", will the JRE (possibly in some
future version) ignore the version layers, or will it detect the version
layers and use them anyway?

(I'm trying to match the semantics and the intent, including any possible
future behavior if multi-release jars become the norm, and I'm wondering if
I should ignore everything in "META-INF/versions" if the Multi-Release
attribute is missing.)


More information about the jigsaw-dev mailing list