New JEP: Concise Method Bodies

[Kevin Bourrillion]

Hello,

I think it's relatively easy to see the benefits when there a fair number
of parameters to pass through.

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?

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> wrote:

> 2018/9/19 11:42:16 -0700, 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180919/08354f04/attachment.html>