>
Master could easily include support for Java 24; as long as the file support Java 23, the Java 24 code wouldn't harm; just as it won't harm after Java 24 is released and the BETA_JAVA24 branch is merged.
I request you to look at the code around preview flags, for e.g., AST#isPreviewEnabled() . In master, preview can only be enabled with Java 23, but in BETA_JAVA24, preview can only be enabled with Java 24.
I see some cases where the condition is used with `ast.apiLevel() == AST.JLS20 && ast.isPreviewEnabled()`. Isn't it a good thing we could try to use more?
Note that the same "problem" exists with Javac: is you used a Java N preview feature, the feature is standardized in Java N+1 and you use Javac N+1, then the feature is enabled in, independently of the -preview flag.
In practice, it's not really harming as usage of preview features seems to be rarely reaching production code. At least, not so many people complain about this possible misalignment between the (older) spec and the (newer) compiler behavior when it comes to toggling preview features.
Similarly, JavaFeature that specifies the @since version a preview feature is supported, will change between master and BETA.
OK, so maybe we could consider to refine it, replacing the boolean with some "previewFeatureIn" listing the related JDK versions ?
