Java Modules and Multi-Release Jar

[Luke Hutchison]

Thanks for the helpful explanation.



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

> On 30/09/2018 08:57, Luke Hutchison wrote:
>
> :
>
> I have a related question about this specifically. I just added
> multi-release jar support to ClassGraph (
> https://github.com/classgraph/classgraph ). If one or more versioned
> sections are present and the code is running on JRE9+, then the
> highest-numbered section number less than or equal to the running JRE
> version is scanned, and the other sections (including the base section) is
> ignored by ClassGraph. Does this more or less match the JRE semantics, or
> should I be rather using the versioned section to shadow/mask the base
> section, but scan / read from both?
>
> ie. does the JRE find resources and classes in both the versioned section
> and the base section, or does the presence of a versioned section preclude
> reading from the base section? Your comments seem to indicate the former,
> since it sounds like module-info.class can be in either the versioned
> section or the base section, and if it is in the base section, that means
> module-info.class applies to all versions. That could mean that the base
> section shadows the version sections, not the other way around (at least
> for module-info.class).
>
> 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.
>
> -Alan
>
>
>
>
>