Preview language features in JDK source code

[Alex Buckley]

Hi Stuart,

On 3/30/2023 10:54 PM, Stuart Marks wrote:
> 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.

(I think you meant "should /not/ use preview language features" above.)

Do you have cases in mind whose reason for using preview language 
features in the JDK is strong, but distinct from the <<mutual 
dependence>> reason seen with {pattern matching, the ClassFile API, the 
JDK's use of the ClassFile API} ?

I agree that the JDK should lean very heavily toward _not_ admitting use 
of preview language features, especially since compilation with 
`--enable-preview` is most practically enabled on a per-module basis, so 
admitting use in one package opens the door to easily-overlooked uses in 
another package.

An example of a use that doesn't make the cut: replacing a chain of 
StringBuilder.append calls with a string template. This kind of 
opportunistic refactoring can perfectly well wait until the language 
feature is final.

Alex

> 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
>>