On Mon, 20 Apr 2026 14:09:56 GMT, Alan Bateman <[email protected]> wrote:
>> 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 see "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 that start with > META-INF/preview. The only inconsistency I see is that APIs 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 in 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. > Also note, this is all tested for (either in tests in the PR, or tests in > lworld which will come in with later PRs). That fine. Is the lworld branch and this PR mostly in sync? I just want to makes sure that any testing I do with the lworld branch is applicable to the PR (it's easier to trying things out in the branch). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29414#discussion_r3111601180
