More constraints on nesting that could be relaxed

[Brian Goetz]

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.)

(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.)

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.")

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.





On 1/22/2020 1:19 PM, Alan Malloy wrote:
> 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.
>
> 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.
>
> For example, it seems like it should be totally fine to write:
>
> interface Actor {
>   private static final Logger logger = new Logger();
>   default void act() {
>     logger.log("act not implemented");
>   }
> }
>
> 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):
>
> interface Actor {
>   /** Do not use. */
>   public static final class Private {
>     private static final Logger logger = new Logger();
>   }
>   default void act() {
>     Private.logger.log("act not implemented");
>   }
> }
>
> Is this something we could include in the overall nesting reform plan?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200122/1c8fb57c/attachment.htm>