<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <font size="+1"><tt>Understood; restricting to methods only here was
        probably gratuitously bespoke.  I would indeed like to clean
        this up too (though, while it might sound like a "one line
        change to the compiler", it is actually way more work than it
        sounds, because it affects both JLS and JVMS, so requires code
        changes not only in javac but in the runtime, along with JCK and
        spec changes for both language and VM.)  <br>
        <br>
        (On the other hand, the less narrowly-targeted the set of
        changes are, the more it is to become an attractive nuisance,
        where people seek to characterize their favorite bit of
        non-orthogonality or chafing restriction as a "better nesting"
        proposal, in the hopes of jumping on the bus.)  <br>
        <br>
        The main question is how.  It seems justifiable for the Records
        JEP to expand somewhat beyond the boundary of record-specific
        functionality so that it can "complete" rows or columns on the
        feature matrix; by this, it is reasonable to address the
        static-in-inner restrictions (because that impinges on nested
        records) and local enums/interfaces (because these are
        row-completing moves.)  On the other hand, trying to cram local
        methods in with records is clearly way over the line, and things
        like this are somewhere near the line and could probably be
        pulled in (this impinges on "private records in interfaces.")  <br>
        <br>
        If they were impractical to do as part of the remaining records
        effort (either because it is too far from the design center of
        records, or because we don't want to burden the records timeline
        with this), it is not obvious what the best alternative delivery
        vehicle is.  Seems too small for a JEP on its own; we don't do
        language features without JEPs; and while a general "better
        nesting" JEP is possible, as per the above "other hand" comment
        it is likely to be a sort of attractive nuisance.<br>
        <br>
        <br>
        <br>
        <br>
      </tt></font><br>
    <div class="moz-cite-prefix">On 1/22/2020 1:19 PM, Alan Malloy
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAC1Wh8G+bSYf+t-u3JC2KqS7nzyW2qAMb0rSCJCm1-8L8bwWQg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">The recent thread about "cleaner nesting" reminded
        me of a related language constraint that has caused me a bit of
        a headache recently, and I wonder if we can clean it up at the
        same time.
        <div><br>
        </div>
        <div>Somewhat recently, interfaces have gained the ability to
          have private methods, for use as helpers in implementing
          default methods. However, there is currently no plan for
          private fields or private nested classes to be allowed in
          those contexts, even private static final fields. I don't see
          any particularly compelling reason for this: private fields
          made no sense for interfaces in Java 1.0, but since interfaces
          can now have private behavior, it makes sense for them to have
          private state to support that behavior, or at the very least
          private constants. </div>
        <div><br>
        </div>
        <div>For example, it seems like it should be totally fine to
          write:</div>
        <div><br>
        </div>
        <div>interface Actor {</div>
        <div>  private static final Logger logger = new Logger();</div>
        <div>  default void act() {</div>
        <div>    logger.log("act not implemented");</div>
        <div>  }</div>
        <div>}</div>
        <div><br>
        </div>
        <div>But this is illegal because logger is not permitted to have
          the private modifier. Instead, you have to either make the
          logger public (polluting the namespace of inheriting classes
          and breaking encapsulation of your interface), or else invent
          some public class that's allowed to hold a private method
          (still polluting the namespace, but keeping the field hidden):</div>
        <div><br>
        </div>
        <div>interface Actor {</div>
        <div>  /** Do not use. */</div>
        <div>  public static final class Private {</div>
        <div>    private static final Logger logger = new Logger();</div>
        <div>  }</div>
        <div>  default void act() {</div>
        <div>    Private.logger.log("act not implemented");</div>
        <div>  }</div>
        <div>}</div>
        <div><br>
        </div>
        <div>Is this something we could include in the overall nesting
          reform plan?</div>
      </div>
    </blockquote>
    <br>
  </body>
</html>