Feedback on concise methods

[Jorn Vernee]

Hello,

I saw the recently proposed JEP for concise methods [1], and wanted to 
voice my opinion while I have the chance.

I have some experience with similar features in C# and Kotlin, and I 
have to say that I generally don't like them.

     public static int length(String s) -> s.length();

I believe this harms readability by blurring the lines between the way 
fields and methods look too much. This is problematic when visually 
scanning a class, as it becomes harder to tell at a glance whether 
you're looking at a field or a method. It was mentioned in the JEP that 
lambdas also have a more concise form with the curly braces and return 
statement omitted, but by doing the some for method declarations, that 
also means that different language elements will look similar, and it 
becomes harder to distinguish between them. In the pragmatic context of 
a class body together with other field and verbose-form method 
declarations, imho the concise form is harder to read since you have to 
spend extra time deciding whether you're looking at a field or a method. 
The JEP gives a good example of this as well:

     class C {
         Function<String,String> fun1() -> this::bar;
         Function<String,String> fun2() =  this::bar;

         String bar(String s) { return null; }
         Function<String,String> bar() { return null; }
     }

Where I find it difficult to tell whether the first declaration is a 
concise-form method, or it is a field with a functional interface type 
and a lambda expression as initializer.

I also feel that there is a serious readability malice to having 3 ways 
of reading a method, instead of just one, and having to multiplex 
between reading the different forms.

I feel all this goes against the "reading is more important than 
writing" principle.

Though, to be honest, I don't see how it makes writing code any easier 
either. One of the main use cases for the arrow form seems to be 
getters, but I don't manually write getters any ways, I always generate 
them with my IDE. In other cases IDE auto-completion could fill in the 
curly braces and return statement:

     public static int length(String s) { <enter>

Becomes:

     public static int length(String s) {
         return <cursor>;
     }

It might seem that the method reference form makes a stronger case here, 
since it also allows you to avoid having to manually forward parameters. 
But I find that my IDE tries to automatically fill in the arguments to a 
method call I'm auto-completing with variables from the context scope 
already:

     public String m(A a, B b) {
         return x.m <ctrl+space>;
     }

Becomes:

     public String m(A a, B b) {
         return x.m(a, b);
     }


And in that sense it kind of feels like the language is trying to do the 
IDE's job, as far as writeability goes.

To be frank; I don't see the concise form as better, just different, and 
having different ways of doing the same thing has it's own cost to it. I 
just don't see what weakness or restriction is being removed by adding 
this feature.

Best regards,
Jorn Vernee

[1] : http://openjdk.java.net/jeps/8209434