Preview language features in JDK source code

[Adam Sotona]

You may have noticed that java.base and several other JDK modules are now being compiled with preview features enabled (PR 10982<https://github.com/openjdk/jdk/pull/10982/files#diff-4a446a73ca506b45b138c61b4270f0c3fce100dad55415c065a4458d5ca23ec2>). Here I would like to explain the rationale behind this move and discuss the usage of preview language features within the JDK source code.

As you might know, the Classfile API is a library for parsing, generating, and transforming Java class files. One of Classfile API goals is to enable replacement of existing uses of other class manipulation libraries (e.g. ASM) across the JDK. Due to the multitude and variety of existing code generation idioms co-existing inside the JDK, the design and development of the Classfile API has spanned across several years and it is not yet fully complete. That said, even in its current state, we believe that the Classfile API has reached a sufficient level of stability and maturity which makes us confident that it can be used reliably within the JDK codebase itself. As more code is replaced to use the new Classfile API, we expect to receive feedback that would enable us to further iterate on the design and implementation of the Classfile API.

Pattern Matching for switch (JEPs 406, 420, 427, 433 and 441) is a fundamental building block which enables clients of the Classfile API to express complex transformations in a clear and succinct fashion. In fact, pattern matching is so central to the design of the Classfile API that is also used in the API implementation classes. As the Classfile API was integrated before the finalization of the Pattern Matching for switch, we had to come up with a pragmatic solution. After some discussion (issuecomment-1380014924<https://github.com/openjdk/jdk/pull/10982#issuecomment-1380014924>) we decided to enable preview language features when compiling specific JDK modules, while at the same time disabling the associated "classfile version" pollution which is typically associated with the usage of preview language features.

This process above highlighted the current asymmetry of treatment between preview language features and preview APIs. More specifically, when working with preview APIs, JDK developers can take advantage of the notion of "participating source code" (JEP 12): that is, code in the same module as some preview API can freely use the preview API w/o having its classfiles being polluted. However, as no such concept exists for preview language features, each and every usage of a preview language feature (even uses within the JDK itself) will result in classfile pollution.

It would be good if this asymmetry in the notion of "participating source code" could be rectified in JEP 12, so as to allow future JDK APIs (much like the Classfile API did) to take full advantage of preview language features and APIs.

Thank you,
Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230329/b3e2fd72/attachment.htm>