On Mon, 16 Mar 2026 12:00:12 GMT, David Beaumont <[email protected]> wrote:
>> Are you are sure that ClassPathImageEntry::open_stream_for_loader can't use >> Arguments::enable_preview to test if preview features are enabled? The >> command line has --enable-preview or it doesn't, so I think I'm missing the >> sequencing that requires PREVIEW_MODE_UNINITIALIZED. > > Preview mode is not only controlled by --enable-preview because Javac needs > to have different values from its runtime during compilation. > > PREVIEW_MODE_UNINITIALIZED is more of an internal guard to prevent a future > change from reading the jimage file "too early" and getting the non-preview > version of something by accident. > > Some options are read from the jimage itself, and are read without reference > to "preview mode", and they must be processed before anyone starts reading > anything else. The "raw" read of the options from the jimage file is the only > read allowed while PREVIEW_MODE_UNINITIALIZED is set, and any "normal" reads > must be done after initialisation is complete. > > See `lookup_vm_options()` for where the "raw" read is performed *before* > preview mode can be set. > > `Arguments::parse()` calls `lookup_vm_options()` and we can't access the > preview mode flag until that's complete (even if in theory > `lookup_vm_options()` wouldn't be able to affect the preview mode flag > itself). "Preview mode is not only controlled by --enable-preview because Javac needs to have different values from its runtime during compilation". That is correct. It's normal for preview features *disabled* in the execution environment when compiling with `--enable-preview`. I think I need a good summary on why this impacts class loading with the boot class loader as class loader as I would expect javac to use jrtfs to locate the class bytes, not the boot class loader. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29414#discussion_r2940339713
