New JEP: Concise Method Bodies

Remi Forax forax at
Fri Oct 5 21:09:34 UTC 2018

> De: "Kevin Bourrillion" <kevinb at>
> À: "Alex Buckley" <alex.buckley at>
> Cc: "amber-spec-experts" <amber-spec-experts at>
> Envoyé: Vendredi 5 Octobre 2018 22:25:28
> Objet: Re: New JEP: Concise Method Bodies

> Oops - sorry for the rapid-fire responses here. A couple more points while this
> is all still actively rattling in the brainpan.
> Today, method references are a thing, and can be bound to expressions:
> `foo()::bar`.

> A piece of folk knowledge that we count on developers to pick up along the way
> is that the `::` separates that which is evaluated now from that which is
> evaluated later. Any who don't grasp that will eventually get into some trouble
> sooner or later.

> Now we want to introduce a second way to use method references, where that
> creation/evaluation distinction doesn't exist. Or does it? Some number of users
> will think "maybe what's before the :: is evaluated the first time the method
> is called and then reused? In fact, I think I remember learning something just
> like that... they were really clear about the difference between what's before
> vs. after the ::. This must be it." This is problematic.

> Finally, to my earlier screed about the trade-offs of "multiple ways to do the
> same thing" I want to add a nice (very paraphrased) point that was made on
> reddit by a now-deleted account. (Thanks, mystery person.) Offering users a
> choice between two ways to do the same thing isn't just offering them a choice.
> It's also burdening them with having to read and maintain code that made each
> of those choices, for whatever reasons that may be unknowable now. Now, no one
> in amber-spec-experts will say "I never thought of that before", but I'm just
> explaining why I'm advocating for a high bar here.

but we have method ref and lambda as expression since Java 8, two ways to do the same things ? 

As expression, method ref are useful compared to lambda because 
- you name things i.e. if the code is more meaningful than a name, use a lambda, if a name is more meaningful, use a method ref 
- the operator :: is the real operation, a lambda is just a syntactic sugar for an anonymous method ref. 

With the concise method body, a method ref is is 
- convenient way to express delegation. 
- the lambda is the way to express a concise body, the method ref is conceptually a sugar way to express a lambda 

the main difference is that the method ref syntax for concise method body still requires to write the types of parameter types, so while method ref is useful as an expression because you can choose if you want to name things (method ref) or don't (lambda), it seems there is no such rational for method ref for concise method body compared to a lambda, it seems more like a kind of gimmick. 

and there is still the issue that the '=' between the method declaration and the method ref is not an assignment too. 


> On Fri, Oct 5, 2018 at 1:03 PM Kevin Bourrillion < [ mailto:kevinb at |
> kevinb at ] > wrote:

>> On Mon, Sep 24, 2018 at 10:17 AM Alex Buckley < [ mailto:alex.buckley at
>> | alex.buckley at ] > wrote:

>>> On 9/21/2018 4:07 PM, Kevin Bourrillion wrote:
>>> > "The method reference form can use most kinds of method references after
>>> > the = sign: static and unbound method references, bound method
>>> > references (if the receiver *variable* is in scope for the method
>>> > declaration)"

>>> > Can we still bind to any expression?

>>> > private String a(String b, int c)
>>> > throws SomeCheckedException = *d.e()*::f;

>>> No limitation is intended on the receiver, as long as the method
>>> reference expression would be legal if it appeared in the traditional
>>> body of method `a`. (Details of this translation remain to be worked out.)

>> Can the expression before the :: refer to any method parameters? Of course, it
>> would still expect to pass those parameters into the method, so it's weird to
>> have the same parameter used in both ways, but does it make sense to forbid it?

>> --
>> Kevin Bourrillion | Java Librarian | Google, Inc. | [ mailto:kevinb at |
>> kevinb at ]

> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | [ mailto:kevinb at |
> kevinb at ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the amber-spec-experts mailing list