methods-in-methods, can they be static? Should they be externally accessible?

[Reinier Zwitserloot]

In regards to:
https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-January/001904.html
('Towards Cleaner Nesting' - Brian Goetz)

My only comment to the majority of that post is to applaud it. From the
text I gather that the most (to me, anyway) exotic aspect of the plan:
methods in methods – are not really part of milestone 1.

1.The 'local method branch' that Jesper and Maurizio were talking about
last Saturday – is that about methods in methods? Is 'local method' the
terminology for the concept of a method whose immediate enclosing lexical
context is a method?

2. Is it too early to talk about the semantics of methods in methods? Just
in case I misinterpreted the term 'local method' (see #1), I'm going to use
the term 'inner method' for any method whose immediate enclosing instance
is itself a method.

Syntactically, you can of course put the modifier 'static' on an inner
method. But what does that mean? Clearly it means you cannot access the
(non-static) fields of the instance that the enclosing method is in, even
if your enclosing method is itself non-static. That is obvious. However, if
I apply Brian's sense of what static means (namely: The lexical context of
a static anything is solely for namespacing purposes, not for access), it
would also mean I have no access to any (effectively) final local variables
declared 'above' me in the enclosing method – something method local
classes (and, presumably, non-static inner methods) DO get. This also
conveniently means the inner method can actually be hoisted up to the class
level by the compiler verbatim; nothing the method could possibly access
requires synthetic bridgers, the way captured local vars are currently
transmitted to method local classes via synthetic constructors.

Do I follow Brian's thought process on what 'static' means correctly and,
thus, will static inner methods be allowed?

3. If static inner methods are indeed allowed, any thoughts on allowing
code that isn't in the outer method to invoke the inner method? The point
of 'inner methods' is presumably that they are relevant only to the outer
method and thus this seems to go against the idea, but, for unit tests I
can foresee some utility in being able to do this. However, because of the
separated namespace rules (fields and methods each are their own
namespace), what would the syntax look like? Given:

    class Example {
        int instanceOuter = 10;
        void instanceOuter() {
            static boolean inner() { return true; }
        }
    }

How would one invoke the inner method from, say, a unit test class in the
same package for the Example class? Example.instanceOuter.inner() is
tricky. Example::instanceOuter.inner() doesn't really feel right, though I
believe syntactically that can be made to work.

Before we get bogged down in syntax debates, is this use case (unit tests)
worthwhile enough to try to find a way?

NB: For non-static inner methods, the required context is missing, so
invoking those is a no-go in any case, just like (short of reflective
shenanigans) you just can't touch method local classes from anywhere except
within that method right now. In that sense, now that method local classes
can be static, the same consideration applies there: There is some utility
to being able to reference a static method-local class (construct them,
call methods declared in them) from test classes.



 --Reinier Zwitserloot