-
Bug
-
Resolution: Unresolved
-
P3
-
None
-
None
Consider this program:
class Outer {
class Inner { }
static class InnerOuter extends Outer {
class InnerInnerOuter extends Outer {
InnerInnerOuter() {
this(new Inner()); // 1
}
InnerInnerOuter(Object o) { }
}
}
}
This fails to compile in (1) with:
error: cannot reference this before supertype constructor has been called
According to JLS 15.9.2, there's three important classes:
* C is the class being created
* U is the immediately enclosing class or interface declaration of the class instance creation expression.
* O is the innermost enclosing class declaration of which C is a member
The spec checks that O is enclosed by U. And then picks as enclosing instance the i-th enclosing instance from U corresponding to O.
In this case we have:
* C = Inner
* U = InnerInnerOuter
* O = InnerInnerOuter (because this class extends Outer, so Inner is a member of this class)
I think this combo will cause the JLS to "pick" an enclosing instance (InnerInnerOuter.this) that is not really available (as we're in the early construction context for InnerInnerOuter).
What the spec fails to acknowledge here is that there can be _many_ enclosing classes O1, O2 ... On of which C is a member. And we should pick the _first_ accessible one.
class Outer {
class Inner { }
static class InnerOuter extends Outer {
class InnerInnerOuter extends Outer {
InnerInnerOuter() {
this(new Inner()); // 1
}
InnerInnerOuter(Object o) { }
}
}
}
This fails to compile in (1) with:
error: cannot reference this before supertype constructor has been called
According to JLS 15.9.2, there's three important classes:
* C is the class being created
* U is the immediately enclosing class or interface declaration of the class instance creation expression.
* O is the innermost enclosing class declaration of which C is a member
The spec checks that O is enclosed by U. And then picks as enclosing instance the i-th enclosing instance from U corresponding to O.
In this case we have:
* C = Inner
* U = InnerInnerOuter
* O = InnerInnerOuter (because this class extends Outer, so Inner is a member of this class)
I think this combo will cause the JLS to "pick" an enclosing instance (InnerInnerOuter.this) that is not really available (as we're in the early construction context for InnerInnerOuter).
What the spec fails to acknowledge here is that there can be _many_ enclosing classes O1, O2 ... On of which C is a member. And we should pick the _first_ accessible one.