State of the Lambda

| by Alex Blewitt Follow 4 Followers on Nov 21, 2012. Estimated reading time: 3 minutes |

With next year's Java 8 less than twelve months away, Brian Goetz has published an updated State of the Lambda, covering the improvements to the Java Collections API. With one of the most anticipated features of Java 8 being the introduction of lambda expressions, key support for these in the Java collections API is key to ensure wide use of the libraries. If you're not familiar with the lambda syntax, see the previous State of the Lambda post and InfoQ's prior coverage for details about the language syntax.

Since it isn't practical to replace the entire Collections library, it is necessary to extend it with support for lambdas. The plan is to utilise internal iteration (that is, passing a lambda to a forEach() on the collection) as opposed to the external implementation used today (such as Iterator and Enumeration). A new interface, Stream, will be added to support a (potentially lazy) sequence of values, along with methods such as stream() to convert a collection into a (lazy) stream.

Streams differ from general Collections in that they don't have storage (so can be infinite or read on demand), are functionally processed in nature, and can be lazily generated. For example, we can create a Stream that represents prime numbers, with each new element producing the next prime number in the sequence.

The Stream interface will also provide a number of functional processing methods, including forEach(), filter(), fold(), anyMatch() map(), and flatMap(). The interface may be constructed in a way appropriate to the specific type of collection used, or it may be implemented in a generic way for other classes to participate in. The laziness means that a stream can be consumed, filtered and mapped along wtih an operation such as findFirst(). This can be chained and then terminate as soon as the first match is found, rather than having to iterate over the entire collection. One such example in the state of the collections is:

Optional<Shape> firstBlue =
  .filter(s -> s.getColor() == BLUE)

The java.util.function package will have a starter set of functional interfaces like Predicate, Function, UnaryOperator and BinaryOperator, with the idea that developers will be able to add their own functional interface types as well. The functional package also introduces a new type, Optional, which provides a mechanism for representing potentially null values. This wrapper class holds either a single instance of a type, or represents the value null but in an object safe way. Not everyone is happy with this design, as an elongated mail thread discussed last month. Other languages, like Scala and Haskell, provide a more functional view of Optional as a monad; but as Brian Goetz said, "Sorry if people are upset that we're not turning Java into Scala or Haskell, but we're not." as well as saying "it is very easy for a vocal minority to masquerade as the voice of the community". Whilst some strongly typed and/or niche languages go much further in functional design, most of the millions of Java developers won't be familiar with functional programming, and providing the biggest benefit for the biggest number of developers is Oracle's key goal.

Adding streams and functions to the Java language also allows for operations to be parallelised. Given a logical stream of data, the results can be partitioned into different levels of chunks and then handed off to a parallel processing architecture like the fork/join framework. The current proposal introduces a Spliterator, which can be used to split a larger chunk of data into a smaller set of chunks suitable for processing in parallel. By exposing a generic way of splitting a data structure up into smaller units, it allows the data structure to provide efficient partitioning of the data whilst allowing the fork/join framework to operation a generic set of data.

Finally, it seems that lambda love is leaking out into the EL (Expression Language) part of Java EE. Previously, there were LINQ like constructs for performing data processing, but with the upcoming lambda support it has been decided that EL should adopt some of the lambda syntax so that it is more broadly compatible with the Java language. This will push the design of the EL project to the end of this year, with a final release in the first quarter of 2013.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Similar to IEnumerable in .NET? by Roopesh Shenoy

Is this stream similar to IEnumerable in .NET? Or is there any difference?

"it is very easy for a vocal minority to masquerade as the voice of the ... by Serge Bureau

Sorry M Goetz,

I am not so sure that you are not yourself the minority.
I think the majority is unhappy about the mess Java is becoming.

In fact it seems to be the time where change should stop and only improve libraries and let other languages make a much better use of the JVM.

Java has totally lost it's coherence, it is trying to be everything and ends up not being much.

It is painful to see.

Re: by Ronald Miura

The majority don't care enough to even have an opinion, they will just complain when something change.

The ones that care are the minority, the ones that want Java to become a fully functional language is a tiny minority within the minority, and the ones that really understand what that means and still want it, you probably could count in one hand.

And about letting other languages make better use of the JVM, what is preventing that to happen? If you want to use Mirah, Gosu, Fantom, or some other obscure language, just go and use it! New Java features won't hinder the progress of any of them, and if anything, could even make easier to build new languages on top of the JVM (just like the new invokedynamic bytecode did).

What minority are you part of? Or are you with the majority?

Re: by Leandro A

I'm really happy seeing the direction they are taking java the language, I think they are keeping up with the ideas the original designers of the language had back the day.

Re: Please explain ? by Serge Bureau

Generics is a mess and represents 50% of the pitfalls that java books wants you to avoid.
And generic verbosity is a joke.
Because of this, collections are inconsistent.
Array is not part of collections ?
EJB, even if improved are not the way to go.
The use of null is bad.
The forced exception are a pain.

Sorry but it is only getting worse
Where do you see an improvement ???

Re: Why do you see so many language popping by Serge Bureau

Maybe it is because, Java is not anymore considered adequate.

Keep your head in the sand

Re: Please explain ? by Leandro A

Generics is a mess if you use it for things not intended, it's mainly a feature to make collections usage easier.
Checked exceptions have useful applications like validation and help make expressive APIs.
The language is not getting features that make it unreadable or cryptic like C# got and that's a good thing.
Everything is being added to the point of being useful without changing everything else in the language, we don't need the most complex and feature-rich Generics system in the world, we don't need the most feature-rich functional language in the world.
We just need something useful and moderate.

Re: Why do you see so many language popping by Ronald Miura

No, because the majority doesn't really care, they just want the job done.

And again, what is preventing you using the language of your choice? Not Java lambdas, I guess.

Re: Why do you see so many language popping by Luke deGruchy

It's easy to be an armchair quarterback when you're not the one who has to make the hard decisions involved in maintaining a 17 year old language and runtime for which your employer has made backward compatibility guarantees to your clients.

1) Generics: Type erasure was critical to maintaining backward compatibility, otherwise, there would be massive costs involved in recompiling all code, including libraries, to use reified generics. As for generics verbosity, how do you suggest supporting extends, super and wildcard functionality, keeping in mind backward compatibility must be maintained? If I have to port a List that contains Map that can be either String,String or String,Date, I want the option of changing List to List<Map><String,?>> to make the code more readable and maintain backward compatibility. Again, generics as they are in Java right now are infinitely preferable to raw types (which causes infinitely more problems than generics).
2) Arrays: An original language feature that Oracle can't get rid of due to backward compatibility commitments. Also, and this is unfortunate, arrays are far more efficient than Collections, so for low-level high performance work you still need to use them.
3) Null is bad, but pretty much all languages 17 years ago also supported null. Still, Goetz is introducing the concept of Optional to the main libraries and to his Collections library enhancements, so he's acknowledging that null was a mistake. Good for him!
4) What does EJB have to do with the Java language enhancements? Non sequitur!
5) Have to agree with you on checked exceptions, but getting rid of them would also break backward compatibility.

Re: by Peter Veentjer

I guess that most developers are not purist and are happy with new language constructs/library improvements that can make their life easier.

And although Scala certainly has a lot of momentum, on the JVM, Java is still the dominating language.

Re:That is why so many projects are late by Serge Bureau

And so many never completes. Inertia is a powerful concept.

Re: Similar to IEnumerable in .NET? by Faisal Waris

it seems so.

Having a lazy sequence is very useful in functional programming.

Unfortunately, once you have programmed in a better language (F# in my case) its hard to go back to something like java or even C#, no matter what the enhancements.

Java and C# have too much ceremony and programming in them feels like busy work.

I wonder... by Dmitry Tsygankov

I wonder if they are planning to add lambdas to COBOL as well. Or PL/SQL.

Re: Similar to IEnumerable in .NET? by Roopesh Shenoy

I hear you! I've been trying out F# in bits and pieces but haven't really worked on a full-fledged project yet - most of my current work just keeps me tied to C# because of rest of the team's skillset. I am hopeful though that my next project will be full-on F# and I'm really looking forward to that!

too little too late by Ivo Houbrechts

Successfully using groovy in the past 5 years, its hard to understand the buzz about these 'new' language constructs.
Groovy 2.0 has even become an option for the static type addicts.

Re: Similar to IEnumerable in .NET? by Faisal Waris

Here is a very simple and apt comparison.

Moq is a nice Mocking framework in C# but it took 17000 lines of code.

Foq is an equivalent framework for F# by Phillip Trelford and only requires 300 Loc to deliver much of what Moq does (but not everything).

The situation is worse with Java which is less expressive than current C#. This lack of expressive leads to massive OO frameworks such as Spring and Hibernate that essentially make you bow in submission to their will.

I don't think you can Band-Aid your way out of this by tacking functional language features to Java.

Re: Similar to IEnumerable in .NET? by Luke deGruchy

Some thoughts:

1) Java's not going away. It's better to make a genuine attempt to improve it that simple give up on making things better for your clients who are stuck using Java no matter what. The improvements in Java 8 are welcome and will make Java far more useful and Java developers far more productive (especially for multi-threading work) than with Java 7. Band-aid is a poor analogy in this case.
2) How does Clojure compare to F# in terms of functionality? Is Clojure Java's F#? It's a sincere question since I haven't used either.
3) You can't build up tooling (re: IDE support, debugging, etc) for alternative languages/runtimes overnight. Look how long it took to get decent IDE support for Scala. This is another reason Java's not going away any time soon.

Re: Similar to IEnumerable in .NET? by Luke deGruchy

I had another thought.

What's the history behind Sun's decision not to implement closures in Java 1.0 and then 1.1 (where anonymous inner classes were introduced) ? I'm surprised that this didn't happen despite James Gosling heavily promoting the inclusion of closures (and he was obviously right).

Imagine how much better Java would be today if that happened.

Re: Similar to IEnumerable in .NET? by Jeffrey Zhao

Yes and No.

Yes since it's the "starting point" of the functional primitives. No since 1) Iterable/Iterator is Java's IEnumerable/IEnumerator. I don't know why Java creates another interface for functional features, and 2) .NET's functional primitives are exposed as Extension Methods which has much more flexibility than Stream interface - just imagine we're going to add another functional API for Stream on even other types. Do you know PLINQ and Rx in .NET? That all built on the extension features in C# and can be used just as LINQ.

Re: Similar to IEnumerable in .NET? by Faisal Waris

When I switched to F# (from C#), C# already had all of the functional features that Java is getting now. F# could do everything that C# could but was more concise, consistent and expressive.

Lambdas, closures, meta-programming, type inference, etc. were all naturally part of the language not something tacked on. F# even had the async monad which C# 5.0 is getting now.

F# can use all of the new and existing .Net libraries and can co-exist with C# nicely. This is essential for transitioning to a new language today (respective of the platform).

The direct analog of F# is Scala, on the JVM. Both are statically typed hybrid Functional-OO languages. Clojure is a derivative of LISP while F# traces its roots to ML – two different approaches to functional programming.

It’s good that Java is getting functional programming features. Clearly these are essential for today’s needs. However would it not be better to use a language where such features were part of the language from the start and not something tacked on? I hope Java programmers realize, as I did, that it’s time to expand their horizon to new JVM languages.

I understand that tooling is very important. Microsoft fully supports F# in Visual Studio 2010+. I hope that Oracle comes to the same realization and decides that it can officially support multiple languages for the JVM, too.

If Java had functional features from inception, it would have been a very different story. Much of the frustration with Java can be traced to lack of such features, especially in light of C#’s progress. Most of what is being added to Java today is in reaction to that but it’s too late.

Re: by Knox Liam

Brians comments are spot on

Java is the top language because of its pragmatic evolution based and complete guarantee
on compatibility

Re: Similar to IEnumerable in .NET? by Knox Liam

Closures were considered from the outset but time and probably design constraints meant they were left out.

I am glad they were. If rushed through they could of equally of been a bad thing. Look for example at some of the early APIs Date etc. and how the world still pays a hard price for haste. Java won the language war from the outset by solving big problems like platform neutrality, memory management and scalability, and as luck had it at a great time(internet)
That it had interfaces gave enough power to developers. It won as much from the gunk it dis guarded in language evolution than what it added

Watch Brian talk on the implementation decisions on lambda, makes you understand the care for detail and compatibility reasoning going fwd.

What is the use of Option? by Stilgar Naib

I always thought that the use of Option in languages like Scala is to force you to handle the null case via pattern matching and similar constructs. You just cannot miss the null check. Java will not enforce the null check so what is the use of the Option instead of null?

Do not worry, the will fix it in Java11 by Serge Bureau


But a version every 3 years, it will take forever.
Anyway, Java is not consistant since a while.

binary compatibility ? by Serge Bureau

The actual Java mess is according to them due to binary compatibility.

Then they should have broke it a while ago, instead they broke the language.

Those who still defend it obviously have not looked around

Re: What is the use of Option? by Luke deGruchy

To make it explicit that you're returning either 1 or 0 results in an expressive way?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

26 Discuss