During review of JDK-8311302 (implementation of JEP 493) it was pointed out that we should handle the case of JDK modules being patched better. After JDK-8311302 there is this code in JRTArchive, specifically in JRTArchiveFile.toEntry() which handles this case:
try {
return Files.size(archive.getPath().resolve(resPath));
} catch (NoSuchFileException file) {
// This indicates that we don't find the class in the
// modules image using the JRT FS provider. Yet, we find
// the class using the system module finder. Therefore,
// we have a patched module. Mention that module patching
// is not supported.
throw new RuntimeImageLinkException(file.getFile(), PATCH_MODULE);
}
It might make more sense to detect JDK module patches earlier and abort the link for links from the run-time image.
try {
return Files.size(archive.getPath().resolve(resPath));
} catch (NoSuchFileException file) {
// This indicates that we don't find the class in the
// modules image using the JRT FS provider. Yet, we find
// the class using the system module finder. Therefore,
// we have a patched module. Mention that module patching
// is not supported.
throw new RuntimeImageLinkException(file.getFile(), PATCH_MODULE);
}
It might make more sense to detect JDK module patches earlier and abort the link for links from the run-time image.
- is blocked by
-
JDK-8311302 Implement JEP 493: Linking Run-Time Images without JMODs
-
- Resolved
-
- relates to
-
JDK-8345184 Remove restriction of disallowing patched runtime when linking from the run-time image
-
- Open
-
- links to
-
Commit(master) openjdk/jdk/05ee562a
-
Review(master) openjdk/jdk/22037