<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thanks, Alex, for your detailed response!</div>
<div class="elementToProof" style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
For the lack of PREVIEW enum constants in ClassFileFormatVersion or javax.lang.model.SourceVersion, I believe that is a deliberate choice to indicate that each Java SE release must not support any preview feature from any other release. I have examined where
SourceVersion is used as method parameters - they are currently used for their static methods of isName() and isKeyword(), both of which currently do not face a scenario where for a specific source version, when preview features are enabled, these methods
would behave differently, even though such a scenario is considered in JEP 12. I believe we are facing a new scenario; however, SourceVersion APIs cannot quite follow suit from my AccessFlag handling, because compiling a program to use preview features happens
on each compilation task instead of the whole Java Runtime Environment, and we might consider another solution that unifies these two usages.</div>
<div class="elementToProof" style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
In addition, I wonder about the extent of reflective preview APIs: starting with the simplest, the new AccessFlag enum constants from Value Objects (Preview) JEP must be reflective - users may obtain them from accessFlag() reflection methods already. Meanwhile,
the ClassFile API also models certain preview class file constructs - for example, Strict Fields (Preview), a draft JEP, introduces updated StackMapTable attributes. I think the new accessors on the attribute for the new properties can be reflective preview
features, like the preview visitors provided in javax.lang.model.util; however, I am not sure if the factory methods that construct new StackMapTable attributes with these new properties are still eligible as reflective preview APIs. They don't seem necessary
for parsing preview class files, and look more like essential preview APIs instead. It all comes down to one question: does it make sense for class file generators to generate preview class files when the Java Runtime Environment does not have preview features
enabled?</div>
<div class="elementToProof" style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Regards, Chen</div>
<div class="elementToProof" style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="appendonsend"></div>
<hr style="display: inline-block; width: 98%;">
<div dir="ltr" id="divRplyFwdMsg"><span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><b>From:</b> Alex Buckley <alex.buckley@oracle.com><br>
<b>Sent:</b> Friday, April 18, 2025 7:28 PM<br>
<b>To:</b> Chen Liang <chen.l.liang@oracle.com>; valhalla-dev@openjdk.org <valhalla-dev@openjdk.org>; compiler-dev@openjdk.org <compiler-dev@openjdk.org><br>
<b>Subject:</b> Re: Preview features and class file formats</span>
<div> </div>
</div>
<div style="font-size: 11pt;">On 4/18/2025 3:55 PM, Chen Liang wrote:<br>
> In AccessFlag, there are two APIs: locations() and<br>
> locations(ClassFileFormatVersion). Currently, both are affected by<br>
> the enabling of preview features: when preview features are enabled,<br>
> for both new flags, both locations() and<br>
> locations(ClassFileFormatVersion.RELEASE_25) return their supported<br>
> locations as preview features; otherwise, they report they support<br>
> no location. However, I felt that was wrong: when preview features<br>
> are enabled, applications should still be able to obtain right<br>
> reflective information applicable to 69.0 class files.<br>
I wasn't familiar with AccessFlag and ClassFileFormatVersion, but I see<br>
they were introduced in Java 20 with the intent of accurately modeling<br>
class file versions and artifacts.<br>
<br>
It strikes me as an oversight that for ClassFileFormatVersion, "this<br>
enum only models the major version". This major-only design decision<br>
prevents an enum constant RELEASE_25_PREVIEW that models 69.65535. Such<br>
an enum constant would completely answer the question of what<br>
locations(ClassFileFormatVersion) should return.<br>
<br>
If all we have is RELEASE_25, then I agree with you that uniformly<br>
returning "no location" is the right answer -- even if preview features<br>
are enabled. Having reflective APIs vary their answer based on whether<br>
preview features are enabled is possible but inessential.<br>
<br>
As you say, having locations(RELEASE_25) return <<some locations>> on<br>
JDK 25 _when preview features are enabled_ is inconsistent with the<br>
future. Roll forward to JDK 33, enable preview features, and call<br>
locations(RELEASE_25) again: the preview features are different than in<br>
25, so it doesn't make sense to still answer <<some locations>>. Even if<br>
it did make sense, we don't want a future JDK (33) to have to remember<br>
the semantics of preview features from a prior JDK (25).<br>
<br>
<br>
JEP 12 contemplates "reflective preview APIs" that expose in-preview<br>
aspects of classes, fields, etc, without requiring preview features to<br>
be enabled; the expectation is that reflective preview APIs are upgraded<br>
to permanent APIs later. Examples were Class::isRecord in Java 14 and<br>
ImportTree::isModule in Java 24. You could in theory introduce a<br>
reflective preview API like `supportsIdentityFlag()` on<br>
java.lang.reflect.Field (just an illustration) ... but the nature of the<br>
reflection that you want to offer for the preview feature ("Is the<br>
STRICT_INIT flag allowed here?") is _already_ exposed by AccessFlag, a<br>
permanent API, so it would be redundant to introduce a reflective<br>
preview API.<br>
<br>
Alex</div>
</body>
</html>