<div dir="ltr"><div dir="ltr">On Tue, Jun 11, 2024 at 12:11 PM Stephan Herrmann <<a href="mailto:stephan.herrmann@berlin.de">stephan.herrmann@berlin.de</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am 11.06.24 um 17:57 schrieb Archie Cobbs:<br>
> On Tue, Jun 11, 2024 at 10:35 AM Maurizio Cimadamore <br>
> <<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank">maurizio.cimadamore@oracle.com</a> <mailto:<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank">maurizio.cimadamore@oracle.com</a>>> wrote:<br>
>     My point is that we'd probably want the two examples above to align, which<br>
>     probably means going with the rules in JEP 482 (or some alternate rules<br>
>     which achieve the same effects).<br>
> <br>
> I agree.<br><br>
Can you help me fully appreciate your agreement? Somewhere in the discussion I <br>
lost track which example was presented to prove which point and what the <br>
consequences would be.<br></blockquote><div><br></div><div>I'm simply agreeing that (a) we should stick with the rules in JEP 482 and (b) how an anonymous class and the lambda equivalent are treated should be consistent (which is what you get with (a)).<br></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">
What I took home so far is:<br>
* javac and ecj both accept some programs that violate JLS version 22<br></blockquote><div><br></div><div>Yes - and note, it's not just about outer instances. The JLS says "static context", which means no generic type variables, etc. See <a href="https://bugs.openjdk.org/browse/JDK-8301649">JDK-8301649</a>.</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">* the concept "chain of enclosing instances" can be an illusion<br>
   (but replacing this.this$0 with val$this$0 could pretend it's real)<br></blockquote><div><br></div><div>There are really two illusions, which the compiler has to deal with internally because happen "below" the specification, and these cause a bunch of compiler pain/complexity:<br></div><div><ul><li>An indirect outer instance is not accessed directly but must be accessed by "hopping" through a direct outer instance<br></li><li>The synthetic instance field that stores an outer instance cannot be used in an early construction context, so the constructor bytecode has to use the synthetic constructor parameter that provided it directly instead.<br></li></ul></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* did you say implementing JEP 482 will cause code to be rejected that is <br>
currently accepted?<br></blockquote><div><br></div><div>No! JEP 482 should be a strict expansion of the set of valid source files. This is true both at a specification level and a "what javac compiles" level (these levels are different because the compiler doesn't perfectly match the specification).<br></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">* some post spoke of tweaking JLS to model what the implemented behavior is.<br>
    - does anyone still think this is what's happening?<br>
    - if so, which rule reflects implementation rather than principle?<br clear="all"></blockquote><div><br></div><div>As far as I know, *modulo bugs*, the implemented behavior in javac matches JEP 482.</div><div><br></div><div>The current *modulo bugs* are for example <a href="https://bugs.openjdk.org/browse/JDK-8333766">JDK-8333766</a>, <a href="https://bugs.openjdk.org/browse/JDK-8333822">JDK-8333822</a>, <a href="https://bugs.openjdk.org/browse/JDK-8334037">JDK-8334037</a>.</div><div><br></div><div>I'm trying to help figure these out but so far am flummoxed. Maurizio has made some progress though and I'm hoping he'll keep going :)<br></div><div><br></div><div>-Archie<br></div></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>