On Mon, 20 Apr 2026 13:47:20 GMT, David Beaumont <[email protected]> wrote:
>> `ModuleReader.open("META-INF/preview/java/lang/Byte.class")` should not also
>> return the input stream to the preview classes as far as I am aware.
>>
>> Only the `JRTArchive` code even has access to the raw API and *everything*
>> else goes via the `SystemImage` API with which it's not possible to get the
>> preview versions of anything via their "raw" path.
>>
>> See (ImageReader) where *any* preview path is rejected immediately and
>> prevents nodes for them ever existing:
>>
>> /**
>> * Builds a node in the "/modules/..." namespace.
>> *
>> * <p>Called by {@link #findNode(String)} if a {@code /modules/...}
>> node
>> * is not present in the cache.
>> */
>> private Node buildAndCacheModulesNode(String name) {
>> assert name.startsWith(MODULES_PREFIX + "/") : "Invalid module
>> node name: " + name;
>> if (isPreviewName(name)) {
>> return null;
>> }
>
> Also note, this is all tested for (either in tests in the PR, or tests in
> lworld which will come in with later PRs).
With MR JARs, the mental model is that resources in the version section overlay
over the base section, in version order. This means that ModuleReader::list (or
JarFile::versionedStream when using the JarFile API) isn't going to return
names starting with META-INF/versions. If there are resources in the versioned
stream that aren't in the base section then the stream of elements will make
these resources appear "as if" they are in the base section. The only exception
is that a URL to resource that has an overlay has to encode the "real path" so
you'll need "META-INF/versions" in the URL. This is a forced move, as I
mentioned in one of the other comments.
It's possible to disable "multi-release jar processing" by running with
`-Djdk.util.jar.enableMultiRelease=false`, in which case ModuleReader::list
will work like JarFile::stream and return a stream of all resources in the JAR
file. An attempt to locate a resource without the META-INF/versions/$N prefix
will not locate a resource in the versioned section.
For the work here, the mental model is that the resources in the
META-INF/preview section overlay when preview features are enabled. This means
that ModuleReader::list isn't going to return names started with
META-INF/preview. The only inconsistency I see is that API can locate resources
with names starting with META-INF/preview or with URLs that encode the
"META-INF/preview" in the path component.
When preview features are disabled, ModuleReader::list does not include the
resources with names starting with META-INF/preview. The resources can be
located with Class::getResource, or ModuleReader methods with resource names
that contain "META-INF/preview". There is an argument that there should be no
filtering this case, meaning ModuleReader::list would enumerate
`java/lang/Byte.class` and `META-INF/preview/java/lang/Byte.class`, just like a
MR JAR when running with MR processing disabled. It's a coin toss as it doesn't
materially impact anything.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29414#discussion_r3111269382
