Draft Spec for Second Preview of Flexible Constructor Bodies (JEP 482)
Archie Cobbs
archie.cobbs at gmail.com
Mon Jun 10 22:40:55 UTC 2024
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>
More information about the amber-spec-experts
mailing list