<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 7/28/2023 4:18 PM, Dan Heidinga
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAJq4Gi5BtLncLZsFuyGaJfk=+Z73O-r9sw49xvyUw11z4_F2Ag@mail.gmail.com">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<div class="gmail_quote">
<div>I'm with you on that goal.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"> Such “things” might be
condensers (as Brian also mentions), </blockquote>
<div><br>
</div>
<div>As much as I want condensers (please, let's get
condensers asap!), I'm concerned that features which depend
on condensers to get good performance will live in an
unstable state unless we can make running condensers so
cheap and routine and natural that doing so fits in
developers workflows </div>
</div>
</div>
</blockquote>
<br>
Agreed. And we intend to make this cheap and routine. <br>
<br>
As one example of the pain that the JDK is in, we often have
bootstrapping problems where we can't use lambdas in code that runs
early. So some code in java.base gets refactored to use inner
classes (e.g., classfile API), and eventually invariably another
lambda sneaks in and causes a bootstrap regression. We can address
this by condensing lambdas to explicit classes during the JDK build
for a specific set of classes in java.base. For this to work, it
has to be easy, cheap, and straightforward to integrate as a build
step. The actual condensation work is pretty trivial (the most
expensive part is a scan of all the classfiles for the offending
bytecode), so this is mostly a matter of ensuring that the tooling
is easy to integrate in build workflows.<br>
</body>
</html>