The Java faithful gathered at JavaOne yesterday to hear about the future implementation of lambdas in the language. Also known as closures, this range of new capabilities for Java will have far-reaching implications for parallel applications.

Alex Buckley, specification lead for the Java language and virtual machine, spoke at length about the many ideas and solutions proposed to bring closures and better parallelization to Java. “Multicore hardware is now the default,” he said. “No one is surprised the new Amazon Kindle tablet is dual-core. To exploit this, Java needs to help people write software that parallelizes gracefully.

“The core of evolving the platform there needs to be better libraries. We believe this is where the work should occur because there are a lot of domain-specific concerns. As the Java language continues to grow in versions 7, 8 and 9, the features applicable to all libraries will benefit parallel libraries as much as everything else.”

Buckley said that many of the needed changes will take place in the Java Collections Library.

Daniel Smith, specification lead for Project Lambda, said that the inclusion of lambdas in Java will be accompanied by new capabilities in the core libraries of the language. “Now that we have extension methods in the language, we’re free to add a lot of extra functionality on top. We can have iterator methods,” he said.

Smith then introduced the map, reduce, filter and into functions, which can be used to iteratively run functionality across a set of data. “We’ve gotten to the declarative style, and we leave it to the libraries to perform the iteration for you,” he said. “The Collections know how to iterate themselves. That’s all we needed for things like filter and map. We haven’t needed to change the Collections implementation.

“The best practice for parallelizing some collection is to break it into pieces and perform some operation on these pieces and combine them up when done. That’s what fork/join gives us in OpenJDK 7. That’s an important enhancement we can use.”

Prerequisites for lambdas
Buckley said there are four main language evolutions that need to take place for lambdas to be viable in Java. The first is the need for functional interfaces, which Buckley described as “an interface with one method. We are defining this construct as a functional interface to remind ourselves that all these interfaces really express a function.”

The second is the addition of lambda expressions. Buckley said that “a lambda expression is a way to create an implementation of a functional interface, rather than writing methods. Instead of writing boilerplate code, a lambda lets you write down the meat of the work, often in one line.”

Third, Java will need improved type inference. Said Buckley: “If you’re passing a lambda to something that knows it’s expecting a character or string, you don’t need to write out the lambda types of the expression. Parameter types in the lambda expression are inferred based on the functional interfaces method signature.”

Finally, Java will need method references, which will allow developers to reuse an existing method as a lambda expression. The whole goal here, said Buckley, is “more typing with less typing.”

That proposed new type inference was a contentious issue, he said. “Are you adding multiple inheritances to Java? Java’s always had multiple inheritance types; now we’re proposing inheritance of behavior. We’re not proposing any multiple inheritance of state, which causes the most problems. Multiple inheritance of behavior is fairly benign. Some multiple inheritance can be detected at compile time and resolved automatically or manually.”

But this raised the question of how multiple inheritances will be resolved. The rules of the game are relatively straightforward, however, said Buckley. “Invokeinterface prefers declaration in class to declaration in interface, and invokeinterface will go and look at the super interfaces.”

Buckley also said that work to fully implement lambdas and type-inference conflict resolution in a complete and powerful way may take years, due to inherent limitations of the JVM itself. He said that work to get around the 32-bit limit of the VM, and that fixing these inherent flaws would be fodder for releases beyond Java SE 8.

But one result of these changes will be that languages running on top of the JVM will benefit from their capabilities. “Non-Java languages can pay as much attention or as little attention to it as they want,” said Buckley. “A non-Java language can continue to call Java methods through invokeinterface, and the other language doesn’t need to know if they are extension methods or how they are resolved. Scala is likely to benefit from this.”

Lambdas are to be included in the release of OpenJDK 8 and Java SE 8.