On Fri, 17 Apr 2026 17:03:33 GMT, David Beaumont <[email protected]> wrote:
>> src/java.base/share/classes/jdk/internal/jimage/PreviewMode.java line 38:
>>
>>> 36: * to the jimage file provided by the shipped JDK by tools running on
>>> JDK 8.
>>> 37: * */
>>> 38: public enum PreviewMode {
>>
>> 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.
>
> 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`.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29414#discussion_r3109472176
