<!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>