Preview features and class file formats

[Chen Liang]

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.

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?

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.
________________________________
From: Alex Buckley <alex.buckley at oracle.com>
Sent: Monday, April 21, 2025 9:44 AM
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/20/2025 9:13 PM, Chen Liang wrote:
> 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?

This is getting into fairly fine distinctions about the functionality of
specific APIs, but I think the short answer to your question is "Yes".

As you suggest, the notion of a _reflective_ preview API is usually
about consuming pre-existing class file artifacts (and, crucially, doing
so when preview features are not enabled at run time) rather than
producing new artifacts.

For example, on JDK 16, before Sealed Classes were permanent, a
framework that used a reflective preview API to ask "Is this class
sealed?" did so because it expected someone else to have generated a
<<major>>.65535 class file with a PermittedSubclasses attribute.

In general, though, the "someone else" could be another framework ... or
even the same one! Imagine: The end user doesn't have to enable preview
features but behind the scenes, the framework both produces and consumes
class files that exploit preview features. (Obviously this speaks to
scenarios where the class files are invisible to the end user, not
persisted to disk where other tools might pick them up, etc.)

We offer this flexibility to framework developers so they can get a head
start on utilizing the features and provide feedback on them while
they're still in preview and able to change.

It's something of a safe choice to evolve reflective APIs in java.* and
javax.* with normal preview APIs (whether classes, methods, or fields),
but I would be happy to see more additions of reflective preview APIs
that give framework developers the earliest possible chance at use and
feedback.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250421/333c9c09/attachment-0001.htm>