Preview features and class file formats
Chen Liang
chen.l.liang at oracle.com
Mon Apr 21 20:53:10 UTC 2025
Alex, thanks for the Q&A's we have had! Looking at the history, I get one more question about reflective preview APIs:
Per JEP 12, reflective preview APIs do not allow preview features to be used; rather, they allow programs compiled without preview to run correctly in a Java Runtime Environment running with preview features enabled.
I just reviewed the preview APIs introduced for Value Objects JEP: it has a few, such as IdentityException, Objects.requireIdentity, that perform inspection on object instances but are not marked as reflective. I believe they should be marked reflective, as they are critical for non-preview programs to run correctly when preview is enabled (when they can receive value objects, and JVM can throw IdentityException for certain bytecode instructions). Meanwhile, the constructor for IdentityException are all essential preview APIs - they are necessary for the Value Objects feature, but not for non-preview programs to run correctly when preview features are enabled.
Is my rationale for categorizing reflective vs essential preview APIs correct? In particular, can inspection on object instances via getClass() be considered reflection as well?
Regards, Chen
________________________________
From: Alex Buckley <alex.buckley at oracle.com>
Sent: Monday, April 21, 2025 12:26 PM
To: Chen Liang <chen.l.liang at oracle.com>; valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>; compiler-dev at openjdk.org <compiler-dev at openjdk.org>
Subject: Re: Preview features and class file formats
On 4/21/2025 9:20 AM, Chen Liang wrote:
> That said, I wish to come back to the non SourceVersion/
> ClassFileFormatVersion-aware query methods - should they just return the
> behavior when preview is enabled in the current release even when
> preview is not enabled?
I thought we had agreed that if version-sensitive query methods can only
be made aware of "25", not "25 with preview enabled", then their results
should indicate the permanent behavior of 25 _regardless of whether the
Java runtime was started with --enable-preview_.
> Coming back to the JEP 12 example of reserving _ as a keyword, the
> SourceVersion.isIdentifier API will return false for _ in an
> implementation of Java SE 8, regardless if the runtime has preview
> features enabled or not, instead of only declaring that _ is not an
> identifier when preview is enabled
That's tricky because _ in 8 caused a warning but was technically legal.
We knew there would be code compiled and run on 8 for many years, and
did not wish to break it. _ only caused an error in 8 with
--enable-preview. So, consistent with my cautious position above,
SourceVersion.isIdentifier("_") would have returned true on an 8 runtime
_regardless of whether the runtime was started with --enable-preview_.
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250421/00e5262e/attachment.htm>
More information about the compiler-dev
mailing list