Java Lambdas and Closures

Question

I hear lambdas are coming soon to a Java near you (J8). I found an example of what they will look like on some blog:

SoccerService soccerService = (teamA, teamB) -> {
    SoccerResult result = null;
    if (teamA == teamB) {
        result = SoccerResult.DRAW;
    }
    else if(teamA < teamB) {
        result = SoccerResult.LOST;
    }
    else {
        result = SoccerResult.WON;
    }

    return result;
};

So right off the bat:

Where are teamA and teamB typed? Or aren't they (like some weird form of generics)?
Is a lambda a type of closure, or is it the other way around?
What benefits will this give me over a typical anonymous function?

See [what-is-the-difference-between-a-closure-and-a-lambda](http://stackoverflow.com/questions/220658/what-is-the-difference-between-a-closure-and-a-lambda) — nawfal, Jul 05 '14 at 15:32

Edwin Dalorzo · Accepted Answer · 2013-09-25T20:21:23.577

16

The Lambda expression is just syntactic sugar to implement a target interface, this means that you will be implementing a particular method in the interface through a lambda expression. The compiler can infer the types of the parameters in the interface and that's why you do not need to explicitly define them in the lambda expression.

For instance:

Comparator<String> c = (s1, s2) -> s1.compareToIgnoreCase(s2);

In this expression, the lambda expression evidently implements a Comparator of strings, therefore, this implies the lambda expression is syntactic sugar for implementing compare(String, String).

Thus, the compiler can safely assume the type of s1 and s2 is String.

Your target interface type provides all the information the compiler needs to determine what are the actual types of the lambda parameters.

Briant Goetz, Java Language Architect at Oracle Corportion has published a couple of articles of the work in progress in JDK 8 Lambdas. I believe the answers to your questions are there:

This second article explains how the lambda expressions are implemented at the bytecode level and may help you delve into the details of your second question.

edited Sep 25 '13 at 20:21

answered Jul 09 '12 at 22:51

Edwin Dalorzo

76,803
25
144
205

2

"The Lambda expression is just syntactic sugar to implement a target interface" -- No, it is not. In this case they would necessarily be syntactic sugar for inner classes. The Java language authors clearly stated that **lambdas are *not* just syntactic sugar for inner classes**! Lambdas are first class constructs. -- http://www.oracle.com/events/us/en/java8/index.html 7:30min – Alex May 08 '14 at 12:02
@AlexanderOrlov You're missreading my words. First, [syntactic sugar](http://en.wikipedia.org/wiki/Syntactic_sugar) means 'an alternative syntax that make things easier to read'. And I never said they were syntactic sugar for inner classes, I said 'syntactic sugar to implement an interface', which as far as I know is accurate since the result of evaluating a lambda expression is an synthetic implementation of the target interface. My words were wittingly chosen precisely for that reason. – Edwin Dalorzo May 08 '14 at 12:45
But isn't passing the result of an implemented interface (= interface implementation) to a method as a parameter the same thing as passing an inner class that implements this interface? – Alex May 08 '14 at 12:55
@AlexanderOrlov The answer to your question simply evidences that there is more than one way to implement an interface in Java (i.e. declare a named class that implements it, through anonymous class and now through a lambda expression). – Edwin Dalorzo May 08 '14 at 14:42

score 15 · Answer 2 · edited May 23 '17 at 12:32

15

See this page for a full version of that example (however, the relevant parts are shown below).

The types are inferred from the SoccerService interface and SoccerResult enum, not shown in your snippet:

enum SoccerResult{
    WON, LOST, DRAW
}

interface SoccerService {
    SoccerResult getSoccerResult(Integer teamA, Integer teamB);
}

The benefit (of lambdas versus standard anonymous classes) is just reduced verbosity:

(x, y) => x + y

versus something like:

new Adder()
{
  public int add(int x, int y)
  {
    return x + y;
  }
}

For the difference between a closure and a lambda, see this question.

edited May 23 '17 at 12:32

Community

1
1

answered Jul 09 '12 at 22:42

DNA

42,007
12
107
146

Broken link "this page". – powder366 Apr 12 '16 at 10:53
@powder366 Now fixed, thanks (the relevant parts of the example were copied into my answer, so you weren't missing much!) – DNA Apr 12 '16 at 11:03

score 9 · Answer 3 · answered Jul 10 '12 at 00:23

Where are teamA and teamB typed? Or aren't they (like some weird form of generics)?

Lambda's use target typing, much like generic method calls (since 1.5) and the diamond [not an] operator (since 1.7). Roughly, where the type the result applied to is stated (or can be inferred) that is used to supply the type of the Single Abstract Method (SAM) base type and hence the method parameter types.

As an example of generic method inference in 1.5:

Set<Team> noTeams = Collections.emptySet();

And diamond operator in 1.7:

Set<Team> aTeams = new HashSet<>();

Team, team, team, team, team, team. I even love saying the word team.

Is a lambda a type of closure, or is it the other way around?

A lambda is a limited form of closure in almost exactly the same way as anonymous inner classes, but with some random differences to catch you out:

The outer this is not hidden by an inner this. This means that the same text in a lambda and an anonymous inner class can mean subtly but completely different things. That should keep Stack Overflow busy with odd questions.

To make up for the lack of inner this, if assigned directly to a local variable, then that value is accessible within the lambda. IIRC (I could check, but wont), in an anonymous inner class the local will be in scope and hide variables in an outer scope but you can't use it. I believe the lack of an instance initialiser makes this much easier to specify.

Local fields that do not happen to be marked final but could be, are treated as if they are final. So not are they in scope, but you can actually read (though not write) them.

What benefits will this give me over a typical anonymous function?

A briefer syntax. That's about it.

Of course the rest of the Java syntax is just as hopelessly bad as ever.

I don't believe this is in the initial implementation, but instead of being implemented as [inner] classes, lambdas can use method handles. The performance of method handles falls somewhat short of earlier predictions. Doing away with classes, should reduce bytecode footprint, possibly runtime footprint and certainly class loading time. There could be an implementation where most anonymous inner classes (not Serializable, trivial static initialiser) didn't go through the poorly conceived class loading mechanism without any particularly noticeable incompatibilities.

(Hope I've got the terminology wrt hiding correct.)

What compiler error is thrown when you try to modify unfinal variables (if I understand your answer right)? — rogerdpack, Apr 26 '13 at 16:56

Java Lambdas and Closures

3 Answers3

Linked