Lambda expression vs method reference

Question

IntelliJ keeps proposing me to replace my lambda expressions with method references.

Is there any objective difference between both of them?

Solution 1

Let me offer some perspective on why we added this feature to the language, when clearly we didn't strictly need to (all methods refs can be expressed as lambdas.)

Note that there is no right answer. Anyone who says "always use a method ref instead of a lambda" or "always use a lambda instead of a method ref" should be ignored.

This question is very similar in spirit to "when should I use a named class vs an anonymous class"? And the answer is the same: when you find it more readable. There are certainly cases that are definitely one or definitely the other but there's a host of grey in the middle, and judgment must be used.

The theory behind method refs is simple: names matter. If a method has a name, then referring to it by name, rather than by an imperative bag of code that ultimately just turns around and invokes it, is often (but not always!) more clear and readable.

The arguments about performance or about counting characters are mostly red herrings, and you should ignore them. The goal is writing code that is crystal clear what it does. Very often (but not always!) method refs win on this metric, so we included them as an option, to be used in those cases.

A key consideration about whether method refs clarify or obfuscate intent is whether it is obvious from context what is the shape of the function being represented. In some cases (e.g., map(Person::getLastName), it's quite clear from the context that a function that maps one thing to another is required, and in cases like this, method references shine. In others, using a method ref requires the reader to wonder about what kind of function is being described; this is a warning sign that a lambda might be more readable, even if it is longer.

Finally, what we've found is that most people at first steer away from method refs because they feel even newer and weirder than lambdas, and so initially find them "less readable", but over time, when they get used to the syntax, generally change their behavior and gravitate towards method references when they can. So be aware that your own subjective initial "less readable" reaction almost certainly entails some aspect of familiarity bias, and you should give yourself a chance to get comfortable with both before rendering a stylistic opinion.

Solution 2

Long lambda expressions consisting of several statements may reduce the readability of your code. In such a case, extracting those statements in a method and referencing it may be a better choice.

The other reason may be re-usability. Instead of copy&pasting your lambda expression of few statements, you can construct a method and call it from different places of your code.

Solution 3

As user stuchl4n3k wrote in comments to question there may exception occurs.

Lets consider that some variable field is uninitialized field, then:

field = null;
runThisLater(()->field.method());
field = new SomeObject();

will not crash, while

field = null;
runThisLater(field::method);
field = new SomeObject();

will crash with java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.Class java.lang.Object.getClass()', at a method reference statement line, at least on Android.

Todays IntelliJ notes "may change semantics" while suggesting this refactoring.

This happens when do "referencing" of instance method of a particular object. Why? Lets check first two paragraphs of 15.13.3. Run-Time Evaluation of Method References:

At run time, evaluation of a method reference expression is similar to evaluation of a class instance creation expression, insofar as normal completion produces a reference to an object. Evaluation of a method reference expression is distinct from invocation of the method itself.

First, if the method reference expression begins with an ExpressionName or a Primary, this subexpression is evaluated. If the subexpression evaluates to null, a NullPointerException is raised, and the method reference expression completes abruptly. If the subexpression completes abruptly, the method reference expression completes abruptly for the same reason.

In case of lambda expression, I'm unsure, final type is derived in compile-time from method declaration. This is just simplification of what is going exactly. But lets assume that method runThisLater has been declared as e.g. void runThisLater(SamType obj), where SamType is some Functional interface then runThisLater(()->field.method()); translates into something like:

runThisLater(new SamType() {  
    void doSomething() { 
        field.method();
    }
});

Additional info:

• 15.27.4. Run-Time Evaluation of Lambda Expressions
• Translation of Lambda Expressions
• State of the Lambda, version 3, where SAM was mentioned.
• State of the Lambda, final.

Comments

[Dmitry Ginzburg]

It is just the same things, BUT don't you find beautiful something like files.stream().map(File::getName)?

[Dmitry Ginzburg]

"looks like" is not an argument here, I think.

[Gerard]

Of course! But "don't you find" either... It is a matter of taste, I was more worried about more technical aspects. In fact, as you already said that they are the same, that is a good answer to me. Anyway, as IntelliJ proposes it, I guess that it is generally more appreciated to see a method reference than a lambda (not for me, though).

[tobias_k]

I guess using lambda is a bit more overhead for creating the lambda (anonymous function class and instance) and calling it. But anyway if you just want to call an exiting method, I'd go with the method pointer, too. It's just cleaner. If you use lambda, you just have to visually parse the expression to check whether there's maybe a - hidden in there or stuff.

[soulcheck]

I'd wager that java does the same thing with method reference.

[Gerard]

It seems then that the only discussion is about syntax, and that seems rather subjective (with some exceptions).

[Marko Topolnik]

Overhead of either is an implementation detail and is bound to be quite variable, tending towards zero as the lambda support evolves in HotSpot.

[Holger]

The code of a lambda expression is compiled to a synthetic method while method references work without (exception: special constructs like Type[]::new). The anonymous class generated at runtime will be the same. The JRE does not make any difference between them. So using a method reference will save you one method in your compiled code, on the other hand, you can’t stop at them when doing step-by-step debugging…

[Gerard]

Now the question is going to be shut down... Too bad for all the users like me that don't know the difference between lambdas and references, even if there isn't any decisive one. I also wonder why nobody dared answering that? That is the right answer to me.

[tomorrow]

Answering a two years old closed question is probably a bad idea but for those who ACTUALLY READ the question this is what Oracle's tutorial (docs.oracle.com/javase/tutorial/java/javaOO/…) says: Method references ... are compact, easy-to-read lambda expressions for methods that already have a name.

[stuchl4n3k]

Well I'm a bit puzzled that nobody mentioned this MAJOR difference: expression setCallback(object::method); throws NPE if object == null, but setCallback(() -> object.method()); does not!

[Trunk]

@Holger: A few words seem missing from your comment. Can you elaborate on how each is compiled and subsequently run ? If they're the same (or nearly so) in performance, then I'd usually tend to go for a method reference as the code statement's purpose is clearer.

[Holger]

@Trunk the format of a comment is not sufficient to describe the details (more than my previous comment already did). You may read this and that, if you are interested in more details. But the takeaway regarding your question is simple: there is no significant difference, so if you prefer method references, go for it. Just don’t try to bend code towards using them excessively, i.e. when a lambda is much simpler, don’t stay away from using it.

[Gerard]

Compare: houses.map(House::getName) and houses.map(h -> h.getName()). The lambda takes two less characters. It is true that the type is not explicit, but any IDE would tell you, and besides, lambdas should be used when type is obvious. I might agree with you with reusability, but lambdas are precisely tiny so they can be chained instead of creating big specific methods. In that sense, small methods are more reusable than some big and complex method, and due to lambdas's clarity (and to certain degree, verbosity) they are still easy to read.

[Marko Topolnik]

I'm with Gerald. Readability actually suffers when you move out code, so you have to jump to it to keep reading, then jump back. You want to have all the relevant code in the same place. Also, House is a very benign example; what about ThreeStoryRedBrickHouseWithBlueDoors. I prefer method references for multiple-argument lambdas, and sometimes to emphasize that the lambda is only about a single method call. There is less to go wrong with a method reference: you might misspell the argument at use site, accidentally referring to a variable from outer scope, etc.

[Torsten]

@Gerard I disagree with your first statement. If you use well describing method names and if you extract large piles of code, moving code improves readability. If you use obfuscating method names I agree with you.

[Keshav]

maybe this is exactly happening to me, while using onDraw function in treeObserver.onDrawListner, if I use lambda, app would run, but if use method reference it would crash

[zivce]

Why does this happen exactly? I've tried it on my local and I'm getting the sequential runs with lambda. This is with OpenJDK11.

[michid]

@zivce, when the argument to thenCompose is evaluated it causes a call to supplyAsync(slow("foo")) to obtain the method reference on the returned instance. OTOH, when refactoring to lambda, supplyAsync(slow("foo")) is only called once the lambda is evaluated, which is after the first future completed. Because only then will the argument to the lambda be available.