<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hi Archie,<br>
your comment captures exactly the kind of things I'm worried
about.</p>
<p>We basically have classes which have no enclosing instances, but
where enclosing members can be accessed (via other means).</p>
<p>The solution is, for the JLS to define what's accessible and
what's not, in any given scope.</p>
<p>But this leaves javac (and other compilers) to wrestle with the
specifics on how this is actually translated, and, due to the
non-uniformity, the complexity explodes in our face.</p>
<p>Historically, the JLS used to treat this/super calls as a static
context (8.8.7.1). And then JLS also used to say that inner
classes defined in a static context had no enclosing instance
(8.1.3).</p>
<p>So, for this particular JEP, I think there's a choice in front of
us:</p>
<p>* do we keep JLS as is (and fix javac to do what the spec has
always said the behavior was) ?<br>
* or, do we keep javac as is and then tweak the JLS to model what
the implemented behavior is?</p>
<p>The latter path seems to have been chosen. Do we have a feeling
that local classes in pre-construction context will be radically
more common than they are today? Or are there other reasons behind
this decision?<br>
</p>
<p>Perhaps the tacit understanding was that "javac got this right",
but looking at the increasing numbers of bugs filed recently in
this area, and after looking more at how the code works, it seems
that javac doesn't have a very principled way to get there, and it
is in fact rather easy to come up with examples which defeats
javac's translation strategy.</p>
<p><br>
</p>
<br>
<blockquote type="cite" cite="mid:CANSoFxvZ+jp67D0UXbkpmrRsQVDK9gs=Ei9TZJaPXLUMhTpJNA@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div>Regardless, when looking at the compiler code, there's
many mentions of "enclosing instances" and "outer instances"
but it's easy to have the wrong assumption in your head
about what these terms actually mean.<br>
</div>
<div><br>
</div>
<div>In an ideal world we would all agree to use some
standard, non-ambiguous terminology, e.g.:<br>
</div>
<div>
<ul>
<li>The phrasing should always be "enclosing instance with
respect to D", where D is some lexically enclosing
class.</li>
<li>For a class C, the "enclosing instance of C with
respect to D" is <i>defined</i> if:<br>
</li>
<ul>
<li>D is a class (not interface, record, enum, etc.)<br>
</li>
<li>C is nested within D</li>
<li>There is no static class (or interface, record,
enum, etc.) declaration between C and D (including C
itself)</li>
</ul>
<li>For a class C, the "enclosing instance of C with
respect to D" is <i>accessible</i> at some point X in C
if:</li>
<ul>
<li>The enclosing instance of C with respect to D is
defined</li>
<li>X is not in an early construction context of D</li>
</ul>
<li>If C is nested directly within D with no intermediate
classes, then "enclosing instance of C with respect to
D" is also "the immediately enclosing instance of C".<br>
</li>
</ul>
</div>
</div>
<br>
</div>
</blockquote>
<p>I agree this is confusing and we need better terminology. But I'm
having trouble with the model that A is an enclosing instance of
B, but A's members are not accessible in B. I understand why the
spec does this - but it would be vastly simpler (at least from an
implementation perspective) then to say that A is not in fact an
enclosing instance of B, but that B still has some other enclosing
instance (some enclosing class of A). A model such as this would
inform the translation strategy quite clearly. In fact, I'm
starting to think if we really want to go down the path of
non-static local classes in pre-construction contexts, then javac
should do things this way regardless of how things are specified,
as that will make the translation strategy more uniform and less
buggy than the one we have today.</p>
<p>Maurizio<br>
</p>
<p><br>
</p>
</body>
</html>