On Mon, 30 Mar 2026 16:15:07 GMT, David Beaumont <[email protected]> wrote:
>> Implementation of preview-mode support for jimage modules file, migrated >> from Valhalla related work (see JDK-8352750). >> >> This PR (the first of several) migrates work from Valhalla (lworld) to the >> JDK mainline repository in relation to "preview mode" support. It affects >> the creation and reading of the jimage file, both in Java >> (BasicImageReader/ImageReader) and C++ (imageFile.xpp/jimage.xpp). >> >> Preview mode is a mechanism by which alternate version of JDK class files >> and resources can be made available for class loading and reflection when >> the '--enable-preview' flag is passed to the runtime. >> >> Alternate classes/resource appear in each module under the: >> >> /<module>/META-INF/preview/<path-to>/<resource-or-class> >> >> and replace the original: >> >> /<module>/<path-to>/<resource-or-class> >> >> files when preview mode is enabled. >> >> While initially useful for Valhalla work, this mechanism will be used for >> other cases where preview features (in the JEP 12 sense) require alternate >> classes/resources to be provided. None of the changes in this (or the >> follow-up PRs) are Valhalla specific. >> >> In this PR: >> * the writing of jimage files is modified to recognize and handle preview >> mode paths >> * flags in the jimage file are added or modified to support preview mode >> efficiently >> * (C++) the class loader is modified to permit reading preview versions of >> classes >> * (Java) the image reader and associated JRT file-system classes are >> modified to permit reading preview files >> * unit tests are added to ensure preview mode works as expected when enabled >> * (temporary) any code calling into the affected API (other than tests) >> specifies that preview mode is disabled >> >> Future PRs will add the plumbing to enable preview mode correctly, but with >> the PR there should be no observable change in behaviour (especially since >> no preview classes or resources are being supplied at this point). >> >> --------- >> - [ ] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > David Beaumont has updated the pull request incrementally with two additional > commits since the last revision: > > - Rename ModuleReference to ModuleLink > - tweak comments src/java.base/share/classes/jdk/internal/jimage/ResourceEntries.java line 34: > 32: * <p>This is a special-case API designed only for use by the jlink > classes, > 33: * which read the raw jimage files. It is not the correct API for > accessing > 34: * jimage resources at runtime. Maybe better to just say that is intended for use by the jlink tool rather than than "jlink classes". Also just to note that runtime would be okay with just getting "raw access", it doesn't strictly need the "view" that the image reader exposes. It would be functionally equivalent of the boot loader and system module reader located resources/classes based whether preview features are enabled. What you have is is more efficient but I think remains to me seen if the view needs to be relaxed, e.g. the jrt URI to a resource in META-INF/preview does not reveal the real path whereas a URL to a resource in the versioned section of a MR JAR will "reveal" the real path. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29414#discussion_r3087123459
