JEP draft: Concise Method Bodies

[u/lukaseder]

http://openjdk.java.net/jeps/8209434

[u/donte9181]

Shorter != better.

This feels like it's solving a non-problem. Not once have I ever felt that I was unable to complete a project on time because I had to type some curly braces for trivial methods. On top of that, I don't even type them - my IDE does, so I actually type the same number of characters the "long way" today as I would in the "short way" described here, so it doesn't affect my coding velocity at all.

What it does do is make code significantly harder to read/understand because now you're overloading the arrow/method-reference notation. Currently it's limited to method invocation but now you're suggesting that it could be used while defining methods, too. It requires extra (unnecessary) brain cycles to figure out where the method definition ends and what it's actually doing - especially in the examples w/ multiple arguments.

It's unnecessary complexity that adds to the amount of mental cycles required to consume existing Java code - which is 90% of our jobs. This will make reading Java code harder while having 0 effect on our ability to write code efficiently.

This seems like one of those things someone suggested because they saw something similar in another language and thought it was cool, but will only make Java worse. Keep Java simple. Keep Java readable. Let your IDE write the boilerplate for you.

[u/lukaseder → u/donte9181]

So, you don't use lambdas but keep writing anonymous classes?

Stream.of(1, 2, 3)
      .filter(new Predicate<Integer>() {
          @Override
          public boolean test(Integer i) {
              return i % 2 == 0;
          }
      })
      .map(new Function<Integer, String>() {
          @Override
          public String apply(Integer i) {
              return i.toString();
          }
      })
      .collect(toList());

[u/donte9181 → u/lukaseder]

I do, but that is not even close to an equivalent comparison. Anonymous inner classes make it really hard to find the code that actually provides the meaning as to "what is this code trying to do". You have to sift through multiple lines of annotations and additional method definitions just to get to the "what does this do" whereas lambdas are much more direct.

This is not the case with the "problem" that this draft attempts to solve:

public String getName() { return name; }
public String getName() -> name;

There's no scouring the code for the actual logic of the first function. Your not sifting through extra crap the compiler needs to stay type safe and avoid warnings like you do with inner classes. It's just replacing curly braces with arrow notation or double colons. You basically got to get rid of the word 'return'. That's not that big of a win to me given that it will increase the mental gymnastics required to read Java code.

It's not better - it's just different - and we don't get anything interesting as a result of having yet another way to define functions.

If the community wants to take a swag at first-class properties like C# and the syntax is something like this, I'm all ears. But this just seems like trying to convince people that the barrier between them and great code is a couple of curly braces.