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 = shapes.stream() .filter(s -> s.getColor() == BLUE) .findFirst();
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.
