<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<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, this explanation is enlightening! Indeed, it makes sense that such access is necessary even if preview features are not enabled on the runtime - for example, javac still wishes to access such information even if its runtime itself is not in preview.
Same for other class file processors.</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);">
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?</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);">
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 (and the API does not have access to that information - it does not know if the caller wishes to compile under preview or not, it only knows if the current running VM is enabling preview VM features). Same problem happens
with AccessFlag: the API doesn't know if the caller wishes to generate preview class files in a non-preview runtime environment.</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Alex Buckley <alex.buckley@oracle.com><br>
<b>Sent:</b> Monday, April 21, 2025 9:44 AM<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</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">On 4/20/2025 9:13 PM, Chen Liang wrote:<br>
> In addition, I wonder about the extent of reflective preview APIs: <br>
> starting with the simplest, the new AccessFlag enum constants from Value <br>
> Objects (Preview) JEP must be reflective - users may obtain them from <br>
> accessFlag() reflection methods already. Meanwhile, the ClassFile API <br>
> also models certain preview class file constructs - for example, Strict <br>
> Fields (Preview), a draft JEP, introduces updated StackMapTable <br>
> attributes. I think the new accessors on the attribute for the new <br>
> properties can be reflective preview features, like the preview visitors <br>
> provided in javax.lang.model.util; however, I am not sure if the factory <br>
> methods that construct new StackMapTable attributes with these new <br>
> properties are still eligible as reflective preview APIs. They don't <br>
> seem necessary for parsing preview class files, and look more like <br>
> essential preview APIs instead. It all comes down to one question: does <br>
> it make sense for class file generators to generate preview class files <br>
> when the Java Runtime Environment does not have preview features enabled?<br>
<br>
This is getting into fairly fine distinctions about the functionality of <br>
specific APIs, but I think the short answer to your question is "Yes".<br>
<br>
As you suggest, the notion of a _reflective_ preview API is usually <br>
about consuming pre-existing class file artifacts (and, crucially, doing <br>
so when preview features are not enabled at run time) rather than <br>
producing new artifacts.<br>
<br>
For example, on JDK 16, before Sealed Classes were permanent, a <br>
framework that used a reflective preview API to ask "Is this class <br>
sealed?" did so because it expected someone else to have generated a <br>
<<major>>.65535 class file with a PermittedSubclasses attribute.<br>
<br>
In general, though, the "someone else" could be another framework ... or <br>
even the same one! Imagine: The end user doesn't have to enable preview <br>
features but behind the scenes, the framework both produces and consumes <br>
class files that exploit preview features. (Obviously this speaks to <br>
scenarios where the class files are invisible to the end user, not <br>
persisted to disk where other tools might pick them up, etc.)<br>
<br>
We offer this flexibility to framework developers so they can get a head <br>
start on utilizing the features and provide feedback on them while <br>
they're still in preview and able to change.<br>
<br>
It's something of a safe choice to evolve reflective APIs in java.* and <br>
javax.* with normal preview APIs (whether classes, methods, or fields), <br>
but I would be happy to see more additions of reflective preview APIs <br>
that give framework developers the earliest possible chance at use and <br>
feedback.<br>
<br>
Alex<br>
</div>
</span></font></div>
</body>
</html>