Preview features and class file formats

[Alex Buckley]

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