Draft Spec for Second Preview of Flexible Constructor Bodies (JEP 482)

[Maurizio Cimadamore]

On 11/06/2024 16:28, Archie Cobbs wrote:
> On Tue, Jun 11, 2024 at 3:53 AM Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com> wrote:
>
>     So, back to Attr - turns out that this code (of which I’m not very
>     proud of :-) ), can be rewritted w/o accessing chk.basicHandler
>     inside the anon class.
>
>
> Sure, you could do that - but that's really beside the point.
>
> The point I'm making is simply to show that incidences of classes 
> declared in early construction contexts accessing outer instances 
> exist out there in the world. They may be rare, but they are not so 
> rare that they can be dismissed - at least not according to the high 
> Java/openjdk backward compatibility standards that I've observed over 
> the years. Do you disagree?

I think so. At times we have made other source incompatible changes 
(esp. in the context of type inference in Java 8) with the goal of 
putting the language on a firmer ground.

So far the evidence is that this code idiom is basically non-existent in 
the wild, and there's workarounds. So that, alone, wouldn't constitute a 
great argument IMHO.


>     Thinking more, I think I can perhaps find an argument in defense
>     of the strategy of the approach outlined in the current JEP:
>     migrating lambdas to classes.
>
>     So, back to your example:
>
>     |class Outer int x; class Inner extends Foo { Inner() { super(new
>     Bar() { { Outer.this.x++; } // allowed??? }); } } } |
>
>     Let’s say we write this using lambdas:
>
>     |class Outer int x; class Inner extends Foo { Inner() { super(()
>     -> { ... Outer.this.x++ ... }); }); } } } |
>
>     This is now ok, as the lambda has access to any enclosing
>     instances that were available at the time the lambda was created
>     (e.g. Outer.this).
>
> I'm not sure I understand... I don't see how an inner class vs. a 
> lambda are any different with respect to how outer instances are 
> handled or can be accessed. In both cases, the constructor is going to 
> have to construct some object and pass as a synthetic parameter a copy 
> of the synthetic "Outer.this" parameter provided to the Inner() 
> constructor. In neither case can the constructor pass the Inner "this" 
> instance at that time, because it is still uninitialized.

I don't want to dive in the specifics on how things are implemented, 
which is beyond the point I was making.

My point is that we'd probably want the two examples above to align, 
which probably means going with the rules in JEP 482 (or some alternate 
rules which achieve the same effects).

Maurizio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20240611/8b42b0e4/attachment.htm>