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

[Archie Cobbs]

On Mon, Jun 10, 2024 at 3:37 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> But I suspect what you meant (but you didn't say) is


Thanks - you read my mind better than I do :) My example didn't really
prove anything.

Here's a better one. Attr.java line 617 refers to the instance field
Attr.chk
<https://github.com/openjdk/jdk/blob/master/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L617>
from anonymous inner class RecoveryInfo.Check.NestedCheckContext$1 which is
declared in a super() parameter in the RecoveryInfo() constructor.

If that anonymous inner class had no outer instances, then wouldn't it be
unable to access Attr.this.chk ?

In summarized form this example similar to others I've been showing:

class Outer
    int x;
    class Inner extends Foo {
        Inner() {
            super(new Bar() {
                { Outer.this.x++; }   // allowed???
            });
        }
    }
}

I want to make sure I'm not misunderstanding your proposal.  When you say
"treat all class declarations in pre-construction context as having no
enclosing instance" I still read the phrase "enclosing instance" as
potentially ambiguous (does that include "2nd enclosing instance"? Etc.).

But previously you said: "Wouldn't it be easier to say that every class
declared in a pre-construction context is static, period, and cannot
reference anything from enclosing contexts?" so I'll assume that's what you
mean.

So the two proposals we're talking about for when an outer class instance
expression "Foo.this" is invalid are:

   1. "Foo.this" is invalid when the expression is contained in a Foo early
   construction context (with any level of nesting) (this is what the JEP
   proposes)
   2. "Foo.this" is invalid when the expression is contained in *any* early
   construction context (your proposal?)
   3. Is there some other hybrid proposal?

I'm not going to argue that #1 is the best in all possible worlds, but I
think #1 is better than #2, if only because #2 will cause real-world code
out there to start failing to compile - including javac itself.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20240610/f0738330/attachment-0001.htm>