<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="en-CZ" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="color:#212121">You may have noticed that java.base and several other JDK modules are now being compiled with preview features enabled</span><span class="apple-converted-space"><span lang="EN-US" style="font-size:12.0pt;color:#212121"> </span></span><span lang="EN-US" style="font-size:12.0pt;color:#212121">(<a href="https://github.com/openjdk/jdk/pull/10982/files#diff-4a446a73ca506b45b138c61b4270f0c3fce100dad55415c065a4458d5ca23ec2" title="https://github.com/openjdk/jdk/pull/10982/files#diff-4a446a73ca506b45b138c61b4270f0c3fce100dad55415c065a4458d5ca23ec2"><span style="color:#0078D7">PR
10982</span></a>)</span><span lang="EN-US" style="color:#212121">.</span><span class="apple-converted-space"><span lang="EN-US" style="font-size:12.0pt;color:#212121"> </span></span><span lang="EN-US" style="font-size:12.0pt;color:#212121">Here I would like
to explain the rationale behind this move and discuss the usage of preview language features within the JDK source code. <br>
<br>
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. <br>
<br>
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 (<a href="https://github.com/openjdk/jdk/pull/10982#issuecomment-1380014924">issuecomment-1380014924</a>)
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. <br>
<br>
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. <br>
<br>
It would be good if this asymmetry in the notion of "participating source code" could be rectified in JEP 12, so as to<span class="apple-converted-space"> </span>allow future JDK APIs (much like the Classfile API did) to take full advantage of preview language
features and APIs.</span><span style="font-size:10.0pt;color:#212121"><o:p></o:p></span></p>
<p class="MsoNormal" style="caret-color: rgb(33, 33, 33);font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<span lang="EN-US" style="color:#212121"> </span><span lang="EN-US" style="font-size:10.0pt;color:#212121"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Thank you,</span></p>
<p class="MsoNormal"><span lang="EN-US">Adam</span></p>
</div>
</body>
</html>