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




Reply via email to