<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hi Adam,</p>
<p>Thanks for explaining rationale for this change. This makes good
sense for the Classfile API.</p>
<p>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.</p>
<p>Thus I think the general rule should be that the JDK code should
<i>not</i> 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.</p>
<p>Does that make sense?</p>
<p>s'marks<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 3/29/23 8:38 AM, Adam Sotona wrote:<br>
</div>
<blockquote type="cite" cite="mid:CY4PR1001MB215085D17A8591C41219D9278C899@CY4PR1001MB2150.namprd10.prod.outlook.com">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@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;}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;}div.WordSection1
{page:WordSection1;}</style>
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#212121" lang="EN-US">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 style="font-size:12.0pt;color:#212121" lang="EN-US"> </span></span><span style="font-size:12.0pt;color:#212121" lang="EN-US">(<a href="https://github.com/openjdk/jdk/pull/10982/files#diff-4a446a73ca506b45b138c61b4270f0c3fce100dad55415c065a4458d5ca23ec2" title="https://github.com/openjdk/jdk/pull/10982/files#diff-4a446a73ca506b45b138c61b4270f0c3fce100dad55415c065a4458d5ca23ec2" moz-do-not-send="true"><span style="color:#0078D7">PR
10982</span></a>)</span><span style="color:#212121" lang="EN-US">.</span><span class="apple-converted-space"><span style="font-size:12.0pt;color:#212121" lang="EN-US"> </span></span><span style="font-size:12.0pt;color:#212121" lang="EN-US">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" moz-do-not-send="true">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 style="color:#212121" lang="EN-US"> </span><span style="font-size:10.0pt;color:#212121" lang="EN-US"><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>
</blockquote>
</body>
</html>