On Mon, 20 Apr 2026 14:58:57 GMT, Alan Bateman <[email protected]> wrote:
>> 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). Well I've obviously not pushed back changes made during this PR review into lworld yet, but those are the only differences, and are not functional. lworld has the exploded image logic in and all the plumbing to make the compiler stuff work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29414#discussion_r3116150402
