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