Preview features and class file formats

[Chen Liang]

Thanks, Alex, for your detailed response!

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.

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?

Regards, Chen

________________________________
From: Alex Buckley <alex.buckley at oracle.com>
Sent: Friday, April 18, 2025 7:28 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/18/2025 3:55 PM, Chen Liang wrote:
> In AccessFlag, there are two APIs: locations() and
> locations(ClassFileFormatVersion). Currently, both are affected by
> the enabling of preview features: when preview features are enabled,
> for both new flags, both locations() and
> locations(ClassFileFormatVersion.RELEASE_25) return their supported
> locations as preview features; otherwise, they report they support
> no location. However, I felt that was wrong: when preview features
> are enabled, applications should still be able to obtain right
> reflective information applicable to 69.0 class files.
I wasn't familiar with AccessFlag and ClassFileFormatVersion, but I see
they were introduced in Java 20 with the intent of accurately modeling
class file versions and artifacts.

It strikes me as an oversight that for ClassFileFormatVersion, "this
enum only models the major version". This major-only design decision
prevents an enum constant RELEASE_25_PREVIEW that models 69.65535. Such
an enum constant would completely answer the question of what
locations(ClassFileFormatVersion) should return.

If all we have is RELEASE_25, then I agree with you that uniformly
returning "no location" is the right answer -- even if preview features
are enabled. Having reflective APIs vary their answer based on whether
preview features are enabled is possible but inessential.

As you say, having locations(RELEASE_25) return <<some locations>> on
JDK 25 _when preview features are enabled_ is inconsistent with the
future. Roll forward to JDK 33, enable preview features, and call
locations(RELEASE_25) again: the preview features are different than in
25, so it doesn't make sense to still answer <<some locations>>. Even if
it did make sense, we don't want a future JDK (33) to have to remember
the semantics of preview features from a prior JDK (25).


JEP 12 contemplates "reflective preview APIs" that expose in-preview
aspects of classes, fields, etc, without requiring preview features to
be enabled; the expectation is that reflective preview APIs are upgraded
to permanent APIs later. Examples were Class::isRecord in Java 14 and
ImportTree::isModule in Java 24. You could in theory introduce a
reflective preview API like `supportsIdentityFlag()` on
java.lang.reflect.Field (just an illustration) ... but the nature of the
reflection that you want to offer for the preview feature ("Is the
STRICT_INIT flag allowed here?") is _already_ exposed by AccessFlag, a
permanent API, so it would be redundant to introduce a reflective
preview API.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250421/44954f81/attachment.htm>