On Thu, 18 Jun 2026 17:24:30 GMT, Xueming Shen <[email protected]> wrote:
>> Chen Liang has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains seven additional >> commits since the last revision: >> >> - Structural revision per Sherman >> - Merge branch 'lworld' of https://github.com/openjdk/valhalla into >> cleanup/lw-jrtfs >> - Review comments >> - Merge branch 'lworld' of https://github.com/openjdk/valhalla into >> cleanup/lw-jrtfs >> - Review remarks >> - Merge branch 'lworld' of https://github.com/openjdk/valhalla into >> cleanup/lw-jrtfs >> - Cleanup ExplodedImage and enhance SystemImageTest > > src/java.base/share/classes/jdk/internal/jrtfs/ExplodedImage.java line 324: > >> 322: node = new PathNode(name, selected, attrs); >> 323: } else if (attrs.isDirectory()) { >> 324: List<Path> directories = Stream.of(regularPath, previewPath) > > Should we handle file-vs-directory conflicts like the following here? > > > modules/m/foo/ // regular directory > modules/m/META-INF/preview/foo // preview regular file > > > or the reverse case: > > > modules/m/foo // regular file > modules/m/META-INF/preview/foo/ // preview directory > > > For example, should we reject these as an invalid layout during node > creation, instead of letting `Files.newDirectoryStream(absPath)` throw later > from `collectChildNodeNames()`? > > I would expect us to detect and handle this earlier. > > Not a blocker, though. Do you recall how ImageReader is handling this situation right now? Does it ignore such inconsistencies or throw eagerly or fail latently like ExplodedImage? I'm hesitant to change ExplodedImage when we can't ensure parity with ImageReader. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/2545#discussion_r3437963971
