New JEP: Concise Method Bodies

[Alex Buckley]

Hi Kevin,

On 9/19/2018 12:31 PM, Kevin Bourrillion wrote:
> In other cases, it looks like you're gaining a very /small/ amount of
> syntactic conciseness (mostly omitting `return`) and not much else? Is
> there any actual /conceptual/ simplicity or clarity being gained?

Let me focus on the single expression form. The argument we've made is: 
statement lambdas have a concise form, expression lambdas, that improves 
clarity, and method bodies are like statement lambdas, so they should 
have a concise form too. Maybe that's stretching the connection between 
statement lambdas and method bodies too thin, but it's a fair starting 
point. Perhaps the outcome will be classes with a mishmash of method 
body forms, where the jumping between {} and -> acts to hurt readability 
overall even if individual methods are simpler. (Shades of switch 
expressions having both : and -> cases.) And, empirically, perhaps there 
are very few method bodies in your codebase simple enough to adopt the 
-> form. (Data welcome.)

Alex

> JEPs don't seem to often include any discussion of what the costs of the
> feature change. So evaluating benefit vs. cost is not easy. For example,
> in this case, it becomes harder to understand and explain what a method
> reference even /is/. I've been saying "it's just a lambda expression",
> but either that's gone, or it's now becoming harder to understand and
> explain what a lambda expression is.
>
> I think moral-hazard arguments also deserve a bit of thought.
>
>    public A b(C c, D d, E e, F f) { return g.h(c, d, e, f); }
>
> If I forgot an "if e is empty, throw" check in here, I'll just insert
> it. But if it was this:
>
>    public A b(C c, D d, E e, F f) = g::h;
>
> I'm probably less likely to do that.
>
> This is a bit similar to why our style guide requires braces around
> single-statement if blocks. It's too annoying to deal with inserting
> them and removing them all the time as conditions change.
>
> Perhaps these costs don't add up to anything massive, but we should
> still get a fix on them because if it turns out the benefits
> /also/ don't add up to something massive then....?
>
> I hope this is helpful.
>
>
> On Wed, Sep 19, 2018 at 11:58 AM <mark.reinhold at oracle.com
> <mailto:mark.reinhold at oracle.com>> wrote:
>
>     2018/9/19 11:42:16 -0700, alex.buckley at oracle.com
>     <mailto:alex.buckley at oracle.com>:
>      > https://bugs.openjdk.java.net/browse/JDK-8209434
>
>     Or, more readably: http://openjdk.java.net/jeps/8209434
>
>     - Mark
>
>
>
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com
> <mailto:kevinb at google.com>