There were a number of criticisms of the initial syntax proposed, but the problems ran deeper than pure syntax (which after all, was just a strawman). One of the key issues was that Java has no direct support for function types; and that introduced holes in Java's type system (an array of functions would permit exceptions to leak). Whether these problems were insurmountable or not (or more likely, within the given time-frame for JDK 7's increasingly delayed release), the current state-of-the-lambda has no mention of function types at all.

Instead, we have an adaptation to make it easier to write inner classes. These classes are referred to as SAM classes, or Single Abstract Method classes. This represents a significant subset of abstract classes and interfaces in the Java language that just have a single abstract method; for example, Runnable's run() method, Comparator's compare() method, and so on. (Abstract classes which have a single abstract method are also permitted such as Eclipse's org.eclipse.core.runtime.jobs.Job.)

The current work-in-progress spec suggests that the following would therefore be equivalent:

Again, the syntax is at the proposal stage so may change in the future, but the idea is that the lambda project will permit inner classes to be written more succinctly than using the new anonymous class approach. Otherwise, the lambdas remain the same expressiveness as inner classes; you can capture state from the local heap (though whether that heap remains mutable post capture is still a hotly debated topic). However, some changes to the language (like being able to capture effectively final variables), and having type and method/exception inference makes it much more concise than the equivalent anonymous class.

One reason for following this approach is to permit existing classes (primarily the java.util collections classes) without having to be modified. Had the function type approach been used, then it would have been necessary to retro-fit the collections classes to take lambdas as well, or forgo their inclusion (and therefore usage) in JDK 7. Whilst other libraries would have been able to be flexible, the monolithic Java libraries aren't so mutable and this may be a reason why a different approach was chosen.

It may also be possible to use method references to substitute for a SAMbda as well. For example, we could have:

The # references are method handles, which are similar to java.lang.reflect.Method. However, unlike Method, they are resolved at compile-time (rather than run-time) and the JVM's JIT will have sufficient smarts to be able to in-line the method references automatically. There are also other optimisations that this permits, such as creating a single class to represent delegated method handles for a given SAM type, rather than creating a new anonymous class at the point of use.

Finally, there are contentious issues as well. The initial draft of the current spec prohibited the use of break and continue, but that was subsequently clarified to prevent breaking out of a SAMBda into the enclosing scope. The other key change is that return is implied, and is not allowed in the body of the lambda itself; though a substitute keyword yield (not to be confused with Thread.yield()) has exactly the same semantics as a return would in an inner class. Ostensibly this is to permit a lambda to trigger a return from a method in which it is called later (a so-called 'long return'). There may be a change in the syntax in the future to permit return to be used unadorned in a lambda, and require a subsequent new keyword (or keyword combination, like long return). Other similarities will include this to refer to the enclosing SAM instance, and Outer.this to refer to an instance of the enclosing class.

The changes to the lambda proposal to be a drop-in replacement for SAMs is less ambitious than the project's original proposal, but has the advantage of being easier to implement and not requiring any changes to the existing collections classes in order to be immediately useful. (Changes to the collections classes would have been necessary if function types were added in any case.) It may also be possible to create function references in the future using the same lambda-like syntax, but targeted for a future JDK release.

This post has been updated to reflect the fact that the break/continue has been resolved, and to include the type inference for formal parameters and exception types.

I must say I’m very relieved. I’m not a language designer by any stretch of the imagination but I was seriously concerned by some of the problems in the previous Lambada specification; This looks much more pragmatic, and whilst it may be less than some had hoped for, is probably the best outcome at this time.

In the discussion we missed a project called Lambdaj which provides these features and the java community can concentrate on that project. I believe this project has got a nice base on the closure syntax which should be pluggable into the core platform.

All “magic” is done in AnonymousClassCreator. It creates objects for all fields in given object if there type is known. It uses convention: a method in given class is used that has the same name as field. Here there is method ‘myComperator’ and field ‘myComperator’. So it creates object that implement 'Comparator' that will be using method ‘myComperator’ from given class.More info can be found here .

It is only idea to establish link between method and field, creating something like pointer. How it would been implemented, it depends how strict it should be. I use reflection and name matching becouse it was easier to make proof. But it could be more fragile, or less flexible. For example using: Annotation for matching, and reflection could be replace something like Lombok .

With lambdaj you cannot do exactly the same, but only because it works with a dynamic proxy mechanism that doesn't allow to proxy final classes (like String). However if you want to sort the list of Object based on their String representation you can write something like:

sort(list, on(Object.class).toString());

or, for example, if you want to sort a list of cars based on the age of their owners you could write:

Lambdaj is more readable. It is only a kind of tool to make "closure" in java. Lambdaj is more mature, but it has fixed vocabulary. In that way (where methods are treated as objects) you have to create your own set of operations, which could be more adequate for given domain. It is an experiment how it could be done (example).

If there is no support for defining a method to take a arbitary matching function signature then the whole proposal is floored as at the root of its demand was for dealing with frameworks such as fork-join where this is exactly what you want

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

By subscribing to this email, we may send you content based on your previous topic interests. See our privacy notice for details.

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.