More constraints on nesting that could be relaxed

[Anthony Vanelverdinghe]

For the record (no pun intended), this is tracked by [1], in which John 
describes the design pattern I'm interested in: combining a public 
factory method with a private member type that provides the instances.

Kind regards, Anthony

[1] https://bugs.openjdk.java.net/browse/JDK-8182549

On 22/01/2020 19:52, Brian Goetz wrote:
> 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?
>