Preview features and class file formats

[Alex Buckley]

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