<div dir="ltr"><div>Hello!</div><div><br></div>Thank you for your replies and for terminology clarification. I've created an issue based on this discussion:<div><a href="https://bugs.openjdk.org/browse/JDK-8372010">https://bugs.openjdk.org/browse/JDK-8372010</a></div><div>Feel free to edit it if it's not clearly formulated.</div><div><br></div><div>With best regards,</div><div>Tagir Valeev</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, Nov 16, 2025 at 7:28 PM Archie Cobbs <<a href="mailto:archie.cobbs@gmail.com">archie.cobbs@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi Chen,</div><div><br></div><div>You're right, I had it backwards re: old vs. new behavior. Instead, I'm guessing the new (and better) behavior in the 
"withLocalClassInsideNoInstance" case is just a side effect of recent 
code refactorings. Also my speculation that the reason for the capture was due to the newly added null check was incorrect; instead, the capture was already there before.</div><div><br></div><div>So to summarize (correct me if I'm wrong) it should be possible to eliminate the capture for local and anonymous classes when the outer instance is not actually used, and that would fix both of the remaining cases in Tagir's test ("withAnonymousRunnableInside" and "withLocalClassInside").</div><br></div><div dir="ltr">Thanks for clarifying!</div><div dir="ltr"><div><br></div><div>-Archie</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 14, 2025 at 9:15 AM Chen Liang <<a href="mailto:chen.l.liang@oracle.com" target="_blank">chen.l.liang@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>




<div dir="ltr">
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
The situation in which non-member nested classes capture the enclosing instance unconditionally can be treated as an implementation artifact of javac; we discussed this within Oracle a while ago. The enclosing instance capture being the leading parameter and
 the null check are for linkage, but local and anonymous classes do not have such linkage links, and it should be JLS-compliant that unused enclosing instance capture is dropped altogether. There are local and anonymous classes in early construction context
 and static context that don't perform enclosing instance capture, yet reflectively they are not distinguished from the ones that do, so I believe the compatibility impact is low.</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
Re Archie: I think Tagir means that for 23 and below, the lambdas with local or anonymous classes are still captured. It is interesting withLocalClassInsideNoInstance() is suddenly deduplicated.</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div><div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
P.S. "Deduplication" is a confusing term - in javac I believe it refers to identical lambda expressions reusing the same InvokeDynamic constant (which still generates different call sites per JVMS rules), but in this thread it refers to the singleton lambda
 instances.</div><br></div></div></blockquote><div><br></div><div> </div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>
</div>
</div>
</blockquote></div>