Preview language features in JDK source code

[Stuart Marks]

Hi Adam,

Thanks for explaining rationale for this change. This makes good sense for the 
Classfile API.

The question I have is whether this should apply to other usage of Preview features 
within the JDK. My concern is that uncontrolled use of Preview features by JDK code 
would create friction that would slow down the evolution of the Preview language 
features. I can foresee this causing a big headache, especially near the end of a 
release cycle.

Thus I think the general rule should be that the JDK code should /not/ use Preview 
APIs, except perhaps in specific cases where the tradeoffs have been discussed and 
properly assessed. If so, then I would expect the 
"don't-pollute-participating-class-files" change to be reverted once the Pattern 
Matching for Switch feature leaves Preview.

Does that make sense?

s'marks


On 3/29/23 8:38 AM, Adam Sotona wrote:
>
> 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 toallow 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/20230330/7f13a1be/attachment-0001.htm>