Project Lambda: To Multicore and Beyond

The presentation “Project Lambda: To Multicore and Beyond” (Session 27400 and not to be confused with Brian Goetz’s presentation of the same name) was given in the Hilton San Francisco Grand Ballroom B in the early afternoon on Monday at JavaOne 2011. Even with Grand Ballroom A closed off, this is an extremely large venue for a non-keynote session and there is a large camera (with camera operator) poised to film the presentation. This can probably be construed to mean that the conference organizers anticipated huge interest in coverage of Java SE 8 (JSR 337) and Project Lambda. Alex Buckley (Specification Lead for Java Language and Virtual Machine) and Daniel Smith (Project Lambda Specification Lead) were the presenters and their abstract for this presentation is shown next.
This session covers the primary new language features for Java SE 8 – lambda expressions, method references, and extension methods – and explores how existing as well as future libraries will be able to take advantage of them to make client code simultaneously more performant and less error-prone.

A functional interface is “an interface with one method.” A lambda expression is “a way to create an implementation of a functional interface.” Lambda expression allows “meat” of functionality to be simply and concisely expressed, especially when compared to the bloat of an anonymous class. Several slides included code examples showing how we’d do it today versus the more succinct representation supported by lambda expressions.
Lambda expressions “can refer to any effectively final variables in the enclosing scope.” This means that the final keyword is not required, but rather than it needed to be treated as final (reference not assigned) in the method to be referenced by lambda expression. Some more rules of lambda expressions were announced: the this pointer references enclosing object rather than lambda expression. There is “no need for parameter types in a lambda expression” because they are “inferred based on the functional interface’s method signature” (no dynamic typing necessary). Method references support the “reuse” of “a method as a lambda expression.”
Buckley talked about external iteration as the current predominate approach in Java libraries. In this idiom, the “client determines iteration” and is “not thread-safe.” He talked about disadvantages of introduction of a parallel for loop for solving this issue, but extracted some concepts from the parallel for approach: a “filter” and a “reducer.” Buckley introduced the idea that “internal iteration facilitates parallel idioms” because it does not need to be performed serially and is thread-safe.
One of the issues Java 8 faces is the need to retrofit libraries to use lambda expressions, but they already have defined interfaces heavily used in the libraries and collections. One approach that might be used to deal with this issue is the use of static extension methods in Java similar to those available in C#. There are numerous advantages to this approach, but there are also some major disadvantages such as not being able to use reflection. The decision was made to revisit the “rule” that one “can’t add an operation to an interface.” Based on thism the subsequent decision was made to add virtual extension methods which provide default implementation in the interface that is used only when the receiver class does not override the method with a default implementation.
The slide titled “Are you adding multiple inheritance to Java?!” stated that “Java always had multiple inheritance of types” and “now has multiple inheritance of behavior,” but still does not support “multiple inheritance of state, which causes most problems.” The slide added that “multiple inheritance of behavior is fairly benign” and is really a problem only when compilation occurs in multiple steps. It was emphasized in this presentation that extension methods are a language feature and a virtual machine feature (“everything else about inheritance and invocation is a VM feature!”). As part of this, a bullet stated, “invokeinterface will disambiguate multiple behaviors if necessary.” The non-Java JVM languages can “share the wealth” of extension methods and there was a slide providing three examples of this.
Daniel Smith took over the presentation with the topic of parallel libraries. He showed a slide “Behold the New Iterable” which showed an Iterable interface with methods such as isEmpty(), forEach, filter, map, reduce, and into. He also showed a slide on a Parallelterable interface available from Iterable via extension method parallel().
Smith provided references to JSR 335, JSR 166, and Project Lambda as part of his slide on community contributions. He also cited four additional sessions at JavaOne 2011 regarding lambda expressions and closely related topics. Smith ended with a quote from Brian Goetz on Project Lambda: …we believe the best thing we can do for Java developers is to give them a gentle push towards a more functional style of programming. We’re not going to turn Java into Haskell, nor even into Scala. But the direction is clear.  
Conclusion
Smith’s examples made it clear that lambda expressions will provide tremendous benefits to Java developers in their daily tasks. He showed the types of loops we’ve all had to write many hundreds or thousands of times and the cleaner, more concise syntax that lambda expressions make possible. This presentation has made it clear that, with the introduction of lambda expressions, Java will gain many of the benefits enjoyed by dynamically typed languages in terms of fluency and conciseness.
Related Whitepaper:

Bulletproof Java Code: A Practical Strategy for Developing Functional, Reliable, and Secure Java Code

Use Java? If you do, you know that Java software can be used to drive application logic of Web services or Web applications. Perhaps you use it for desktop applications? Or, embedded devices? Whatever your use of Java code, functional errors are the enemy!

To combat this enemy, your team might already perform functional testing. Even so, you're taking significant risks if you have not yet implemented a comprehensive team-wide quality management strategy. Such a strategy alleviates reliability, security, and performance problems to ensure that your code is free of functionality errors.Read this article to learn about this simple four-step strategy that is proven to make Java code more reliable, more secure, and easier to maintain.

Get it Now!  

Leave a Reply


six − = 1



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

15,153 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books
Get tutored by the Geeks! JCG Academy is a fact... Join Now
Hello. Add your message here.