On Mon, 20 Apr 2026 09:04:30 GMT, Severin Gehwolf <[email protected]> wrote:
>> That's is not how this feature works. The set of values in the enum is >> correct. You can't load both the preview class and the non-preview class in >> the same runtime. As Alan says, this isn't the same semantics as MR Jars. >> >> Think of it as: If I pass "--enable-preview", I get a completely different >> runtime. >> >> There are a couple of subtle ways in which this can be observed to not >> (quite) be true, but that's the intent (and we might one days fix the edge >> cases). > >> Some users of this enum would be in need of a fourth option: `NONE`. A mode >> that would return the contents of the `jimage` verbatim, preview or not. I >> wonder if `PreviewMode` is the right name. > > Yes. I'm worried about subtle bugs in JEP 493 enabled JDKs. There is a > mechanism to discover changed bytes for certain classes (called a "diff"), > but this change of adding preview/non-preview classes to a jimage should > rather be handled outside the diff as the intention of that was to handle the > difference between jlink transformations rather than resources not being > observed anymore from the jimage. > > What this patch potentially changes is that (at runtime, post running > `jlink`) `--enable-preview` might change how the resulting runtime works > between jmod-based and non-jmod-based `jlink`. Basically the aim of this design is that, with `--enable-preview` it should behave as if you potentially ran a different VM with a different jimage file. Anything not behaving like this is note-worthy and could (depending on how easy it is to find) be considered a bug. There are a very small set of observable differences between this PR and the "separate jimage file" approach, but these were considered and deemed acceptable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29414#discussion_r3111007687
