Continuing with our exploration of JSR-335 lets look at some of the enhancements to the collections API as part of the Project Lambda effort. A new feature in the language and not supported by the existing API is just not what the programmers would want. And this is what Brian Goetz and his team working on JSR-335 realized. It was not an easy task of enhancing the existing API without breaking uncountable lines of code. That was a challenge which they took up and managed to get around this by introducing the concept of defender methods.

To outline the major changes in collection API:

• Support for internal iteration by providing methods like forEach, filter, map and others which are added to the Iterable interface with default implementations (Defender methods).
• Explicit parallel APIs for greater parallelism support. These can be combined with Fork/Join to divide the tasks
• Greater stress on immutability and avoiding in-place mutation which was done in the conventional for-each loops

All of these are possible by giving the API/method power to decide its iteration. And the caller would pass in a block of code which would be applied on each of the element or elements decided by the API/method being invoked. That’s pretty much of the theory, lets see it in action on a List of integers from 1 to 10.

List<Integer> counts = new ArrayList<Integer>();
for(int i=1;i <= 10; i++){
  counts.add(i);
}

Iterating through the elements in the list:

//Using external iterators
System.out.println("Using external iterator");
for(Integer i : counts){
  System.out.print(i+" ");
}
System.out.println();

versus

//Using internal iterators
System.out.println("Using internal iterator");
//Passing a code block to forEach method
counts.forEach(i -> {System.out.print(i*2+" ");});
System.out.println();

Very concise right? Digging into forEach method introduced in Iterable interface, it is implemented as:

void forEach(Block<? super T> block) default {
  Iterables.forEach(this, block);
}

if you are confused about the use of “default” keyword, then please read about it here. Iterables is a new class to be introduced in Java 8 and the forEach method in Iterables expects an collection/something which can be iterated and the block of code to apply on the each element iterated, the implementation is:

public static <T> Iterable<T> 
   forEach(final Iterable<? extends T> iterable,
           final Block<? super T> block) {
  Objects.requireNonNull(iterable);
  Objects.requireNonNull(block);
  for (T each : iterable) {
    block.apply(each);
  }

  return (Iterable<T>) iterable;
}

Looks like forEach method does nothing different from the older for-each loop, that’s how forEach ought to work. If you want to maintain immutability you can use a different method which I will write a little later. But for now, forEach iterates through the iterable and applies the block to each of the element. Going into the Block and apply method would be out of scope of this article, lets look at it in a different article.

Lets explore a bit further and print all the even elements of the list.
Using external iteration ( for-each loop) we would have

for ( Integer i : counts){
  if ( i % 2 == 0 ){
    System.out.print(i+" ");
  }
}

and using the new APIs:

//filter evaluates the block
//and returns a new iterable.
counts.filter(i -> i%2 == 0)
      .forEach(i-> {System.out.print(i+" ");});

the filter method doesn’t create a new collection instead it creates a new Iterable. The difference it makes is that there is no intermediate collection created after filter is invoked.

Another example before we close- lets multiply all the odd elements by 2 and create a new list.
Using the for-each loop, this can be done as:

List<Integer> newCounts = new ArrayList<Integer>();
for(Integer i : counts){
  if ( i % 2 != 0 ){
      newCounts.add(i*2);
  }
}
for(Integer i : newCounts){
System.out.print(i+" ");
}

and the same using new API:

List<Integer> newCountsNew = new ArrayList<Integer>();
counts.filter(i -> i % 2 != 0)
      .map(i -> i*2)
      .into(newCountsNew);
newCountsNew.forEach(i -> {System.out.print(i+" ");});

Apart from the other benefits mentioned at the beginning the above code which uses new APIs is more readable than the one which uses for-each.

If you want to read more about the state of the APIs with respect to the lambda expressions, please do so here.
The examples used above can be found here as well.

Mike Duigou announced here that the Iteration 1 of Lambda Libraries is complete which includes support for defender methods, enhancement of the collection apis among other changes.

Before proceeding further its good to read about Functional Interfaces and Defender Methods to some extent.

Lets dive into an example, consider sorting of Person objects where each Person would have firstName, lastName, dateOfBirth, placeOfBirth

class Person {

  public Person(String fName,
                String lName,
                Date dob,
                String place)
  {
    firstName = fName;
    lastName = lName;
    dateOfBirth = dob;
    placeOfBirth = place;
  }

  @Override
  public String toString(){
    return firstName+" "+lastName;

  }
  String firstName;
  String lastName;
  Date dateOfBirth;
  String placeOfBirth;
}

Lets see how we can sort this with and without using lambda expressions

public class LambdaBasicDemo {

  public static void main(String[] args) {
    List<Person> people = createPeople();

    // Sorting pre Lambda Expression era
    //Sorting by firstName
    Collections.sort(people,new Comparator<Person>() {
      @Override
      public int compare(Person o1, Person o2) {
        return o1.firstName.compareTo(o2.firstName);
      }
    });
    System.out.println("Firstname sort: "+people);

    //Sorting using Lambda expressions and updated collection API
    //Sorting by lastName
    people.sort((o1,o2) -> {
      return o1.lastName.compareTo(o2.lastName);
    });
    System.out.println("Lastname sort:" +people);

  }

  static List<Person> createPeople(){
    Calendar calendar = Calendar.getInstance();
    calendar.set(1900, Calendar.JANUARY,01,12,00);
    List<Person> people = new ArrayList<>();
    Person person = new Person("Raju","Sarkar",calendar.getTime(),"Delhi");
    people.add(person);

    calendar.set(1950,Calendar.JUNE,30,12,30);
    person = new Person("Anant","Patil", calendar.getTime(),"Pune");
    people.add(person);

    calendar.set(1950,Calendar.DECEMBER,30,12,30);
    person = new Person("Danny","Great", calendar.getTime(),"London");
    people.add(person);

    return people;
  }
}

The output would be:

Firstname sort: [Anant Patil, Danny Great, Raju Sarkar]
Lastname sort:[Danny Great, Anant Patil, Raju Sarkar]

You all are aware of how the collections are sorted using the Collection API and Comparator so I am not going into that. There’s an interesting syntax which uses a dash(-) and an greater than symbol(>) [dash-rocket], lets look into a bit of detail about this syntax:

//Sorting using Lambda expressions and updated collection API
//Sorting by lastName
people.sort((o1,o2) -> {
  return o1.lastName.compareTo(o2.lastName);
});

There obvious difference between the verbosity of the code for sorting by creating anonymous inner class and by using Lambda expressions. The Lambda expression consists of lambda parameters and Lambda body. A Lambda expression is represented as () -> {} where () contains the lambda parameters and the {} contains the lambda body. A lambda expression can be void returning or value returning i.e can return nothing or return result of some expression.

In the above example, we are constructing a lambda expression for the functional interface Comparator with a functional descriptor (T o1, T o2) -> int.

Note: Something interesting to note here is that with Java 8 the Comparator interface has 2 more methods

Comparator<T> reverse() default {
  return Collections.reverseOrder(this);
}
Comparator<T> compose(Comparator<? super T> other) default {
  return Comparators.compose(this, other);
}

We would like to keep this confusion aside for time being and I will get back on this and explain as to why and how the defender methods are not considered. If someone if aware of the reason, please add them as comments.

Digging deeper into the lambda expression, the (o1, o2) indicates the lambda parameters. The type information for o1 and o2 are inferred from the context in which it is being used, and in our case they are of type Person. The {return o1.lastName.compareTo(o2.lastName);} is the lambda body.

Advantages of using Lambda expressions over Anonymous inner class approach:

• Lambda expressions are lighter on code than the anonymous inner classes.
• An advantage of using Lambda expressions is the resolution of this and super when used within the Lambda expression. In case of anonymous inner class approach the this and super are resolved to the anonymous inner class. And this is not at all useful because there’s nothing that one would want from the anonymous inner class. But in case of lambda expressions these resolve to the enclosing class.
• Permissibility of use of effectively final variables in lambda expressions, where as only final variables can be used in local inner classes

Interestingly, compiling LambdaBasicDemo.java gives 3 class files (apart from Person.class): LambdaBasicDemo.class, LambdaBasicDemo$1.class, LambdaBasicDemo$2.class.

• LambdaBasicDemo.class corresponds to the public class LambdaBasicDemo.
• LambdaBasicDemo$1.class corresponds to the anonymous inner class for Comparator
• and LambdaBasicDemo$2.class corresponds to the lambda expression. So under the hood, the compiler wraps this lambda expression with a new class and then instantiates the same.

That’s pretty much it for a sneak peak. Stay tuned for lot more as I continue to explore the feature.

public interface Runnable {
    public abstract void run();
}

public interface Callable<V> {
    V call() throws Exception;
}

public interface Executor {
    void execute(Runnable command);
}

Functional Interfaces can also have abstract methods which are inherited from Super interfaces and those should be override equivalent (read more about override equivalent methods here). For example:

interface I1{
  void method1(List<Number> n);
}
interface I2{
  void method1(List n);
}
interface I3 extends I1, I2{} // Valid Functional Interface.
interface I4{
  int method1(List n);
}
interface I5 extends I2,I4{} //Not a functional interface

The bottom line is that functional interfaces are those that have single abstract methods (apart from the inherited public methods from Object class). The single method might not be the only method, but can be inherited from multiple interfaces but they signatures are equivalent to each other (See Override equivalent) such that those multiple methods actually represent/act as a single method.

Along with the functional interfaces, there’s a concept called functional descriptors associated. Functional descriptor of an Interface is the method type of the single abstract method of the interface. Here the method type of a method includes: argument types, return type and the throws clause.
In our above examples the functional descriptors are

//For Runnable
() -> void
//For Executor
(Runnable) -> void
//For Interface I3
(List<String>) -> void

These concepts are used while constructing lambda expressions and using them. Just to give a brief: all these functional interfaces can be represented by using Lambda expressions, the compiler in turn infers the context in which the lambda expression is used and uses the corresponding Functional Interface.

In wrote a bit about Virtual extension methods here and here. I thought of going over this implementation in the JDK, so that it will give us an idea of how these can be applied.

As I told earlier, the main intention of adding the virtual extension methods was to provide an option to extend the existing interfaces (by adding new methods) without breaking the existing usages. Consequently the main contender for this is the Collection interface in java.util package. All the collection classes in Java implement this interface. Few methods were added to the Collection interface to provide support for the new collections API.

Lets consider the retainAll method as defined below (copied as is from the source distributed with the JDK):

/**
 * Retains all of the elements of this collection which 
 * match the provided predicate.
 *
 * @param filter a predicate which returns {@code true} 
 * for elements to beretained.
 * @return {@code true} if any elements were retained.
 */
// XXX potential source incompatibility with retainAll(null)
// now being ambiguous
boolean retainAll(Predicate<? super E> filter) default {
    return CollectionHelpers.retainAll(this, filter);
}

New CollectionHelpers class is introduced which contains the implementation of various methods used as virtual extension methods. Also notice that the method in the Collection interface doesn’t have any code/implementation details, instead they refer to methods from another class (CollectionHelpers in this case).

The CollectionHelpers.retainApp is defined as (From the source for CollectionHelpers):

public static <E> boolean retainAll(Collection<E> collection, 
                                    Predicate<? super E> filter ) {
  boolean retained = false;
  Iterator<E> each = collection.iterator();
  while(each.hasNext()) {
    if(!filter.test(each.next())) {
      each.remove();
    } else {
      retained = true;
    }
   }
  return retained;
}

There are numerous such examples in the JDK 8, and one can explore different options from the source for the Java APIs.

There is a list of method resolution approach for virtual extension methods explained here. One of the interesting ones is when a class implements multiple interfaces and say 2 of the interfaces have same method signature but different implementations.
But before that, lets look at a case where the class implements an interface, say I1 and I1 in turn extends another interface I2 and both I1 and I2 have a method with exact same signature. How is the method invocation using the instance of the implementing class handled?
For this lets look at the following example:

public class DefenderMethodsResolution{
  public static void main(String[] args){
    MySuperClass obj = new MySuperClass();
    System.out.println(obj.findProduct(4,5));
  }
}
class MySuperClass implements SpecialMathOperator{
  
}

interface SpecialMathOperator extends MathOperator{
  public int findProduct(int a, int b) default{
    return MathOperatorHelper.findProductUsingSum(a,b);
  }
}
interface MathOperator{
  public int findProduct(int a, int b) default{
    return MathOperatorHelper.findProduct(a,b);
  }
}
class MathOperatorHelper{
  public static int findProduct(int a, int b){
    System.out.println("Finding product by multiplying");
    return a*b;
  }
  
  public static int findProductUsingSum(int a, int b){
    int product = 0;
    System.out.println("Finding product by iterative sum");
    for (int i=0;i < b; i++){
      product += a;
    }
    return product;
  }
}

The output for the above is:

javac DefenderMethodsResolution.java 
java DefenderMethodsResolution 
Finding product by iterative sum
20

It clearly shows that in this case the method resolution is handled by neglecting the super Interface and considering the more specific sub Interface provided sub interface is overriding (I dont know the exact term to use here) the method.

When one thinks of Interfaces having code, then the first thing that comes to the mind is “Deadly Diamond of Death“. Lets see how this is tackled by the compiler. Lets go ahead and slightly edit the code to remove the extends from the SpecialMathOperator interface and make MySuperClass implement both the interfaces. [I know this is not the very best examples, but I think good enough to explain the concept?]

public class DefenderMethodsResolution{
  public static void main(String[] args){
    MySuperClass obj = new MySuperClass();
    System.out.println(obj.findProduct(4,5));
  }
}
class MySuperClass implements SpecialMathOperator,MathOperator{
  
}

interface SpecialMathOperator {
  public int findProduct(int a, int b) default{
    return MathOperatorHelper.findProductUsingSum(a,b);
  }
}
interface MathOperator{
  public int findProduct(int a, int b) default{
    return MathOperatorHelper.findProduct(a,b);
  }
}
class MathOperatorHelper{
  public static int findProduct(int a, int b){
    System.out.println("Finding product by multiplying");
    return a*b;
  }
  
  public static int findProductUsingSum(int a, int b){
    int product = 0;
    System.out.println("Finding product by iterative sum");
    for (int i=0;i < b; i++){
      product += a;
    }
    return product;
  }
}

Trying to compile the above code we would get:

$javac DefenderMethodsResolution.java 

javaDefenderMethodsResolution.java:4: error: 
reference to findProduct is ambiguous, 
both method findProduct(int,int) in MathOperator 
and method findProduct(int,int) in SpecialMathOperator match
    System.out.println(obj.findProduct(4,5));
                          ^
DefenderMethodsResolution.java:7: error: 
class MySuperClass inherits unrelated defaults for findProduct(int,int)
from types SpecialMathOperator and MathOperator
class MySuperClass implements SpecialMathOperator,MathOperator{
^
2 errors

So the compiler doesn’t allow the compilation of such code thereby eliminating the Deadly Diamond of Death problem.

The team which handles JSR-335 thought of a way to add default implementation to the interfaces, which gives an option for the implementor to override the method or to leave it as is. This way new APIs can be added to the Collection class without breaking the existing code and yet provide the full support of the closures to the existing code. One can read in depth about Virtual Extension Methods here.

Lets see an example of a virtual extension method:

interface TestInterface{
  public void testMe();
  
  public void aDefaulter() default{
    System.out.println("Default from interface");
  }
}

Using the “default” keyword we can add new methods to the existing interface and allowing the implementing classes to use this default implementation if they don’t override. Something like:

public class DefenderMethods{
  public static void main(String[] args){
    InterfaceImplementer imp = new InterfaceImplementer();
    imp.testMe();
    imp.aDefaulter();
  }
}
class InterfaceImplementer implements TestInterface{
  public void testMe(){
    System.out.println("Hello World!");
  }
}

The output for above program would be:

~/javaP/java8$ javac DefenderMethods.java 
~/javaP/java8$ java DefenderMethods 
Hello World!
Default from interface

Moving further, we can override the aDefaulter method in its implementing class, something like

class InterfaceImplementer implements TestInterface{
  public void testMe(){
    System.out.println("Hello World!");
  }
  
  public void aDefaulter(){
    System.out.println("Defautler overridden from class");
  }
}

for which the output will be:

~/javaP/java8$ javac DefenderMethods.java 
~/javaP/java8$ java DefenderMethods 
Hello World!
Defautler overridden from class

The bytecode generated for the DefenderMethods class still uses invokevirtual opcode for invoking the default method, which indicates its treated like any other usual interface method in its invocation.

There’s lot more to this concept like overriding rules, method invocation rules which I would like to cover in subsequent posts. And also sample code from the JDK 8 which uses this feature.

Note: The Project Lambda (JSR-335) to be added in Java 8 is evolving and the sample here is how one can use Lambdas with the current Java8 build downloaded from here. I will try to update the sample if there are any changes in the API in future.

I thought it will be good to get a peak of how Lambda Expressions can be used with JavaFX or for that matter any Single Abstract Method (SAM) types.

Lets build a sample with just one toggle button and change the text of the toggle as and when it is selected/un-selected.

The code with the current Java -7 version would be:

import javafx.application.Application;
import javafx.beans.property.SimpleStringProperty;
import javafx.beans.property.StringProperty;
import javafx.event.ActionEvent;
import javafx.event.EventHandler;
import javafx.scene.Scene;
import javafx.scene.control.ButtonBase;
import javafx.scene.control.ToggleButton;
import javafx.scene.control.ToggleButtonBuilder;
import javafx.scene.layout.BorderPane;
import javafx.stage.Stage;

public class LambdasWithJavaFx extends Application {
  public static void main(String[] args){
    Application.launch(args);
  }
  @Override
  public void start(Stage stage) throws Exception {
    BorderPane root = new BorderPane();
    ToggleButton button = new ToggleButton("Click");

    final StringProperty btnText = button.textProperty();
    button.setOnAction(new EventHandler<ActionEvent>() {
      @Override
      public void handle(ActionEvent actionEvent) {
        ToggleButton source = (ToggleButton) actionEvent.getSource();
        if (source.isSelected()) {
          btnText.set("Clicked!");
        } else {
          btnText.set("Click!");
        }
      }
    });
  
    root.setCenter(button);

    Scene scene = new Scene(root);
    stage.setScene(scene);
    stage.setWidth(200);
    stage.setHeight(200);
    stage.show();
  }
}

The main focus would be on the EventHandler set for the ToggleButton, henceforth I would just show that part of the above code.

Lets see how we can use the Lambda expression to update above code.

button.setOnAction((ActionEvent event)-> {
  ToggleButton source = (ToggleButton) event.getSource();
  if (source.isSelected()) {
    btnText.set("Clicked!");
  } else {
    btnText.set("Click!");
  }
});

The only method in the EventHandler class is the handle(Event event) method and in the above example we just write the body and the parameter declaration for the method and remove all the unnecessary instantiation code.

We can remove the type declaration for the event, as the compiler will infer the type from the context. The context here is the Action event and hence the EventHandler expects a ActionEvent and thereby the event reference is inferred to be of ActionEvent type.

button.setOnAction((event)-> {
  ToggleButton source = (ToggleButton) event.getSource();
  if (source.isSelected()) {
    btnText.set("Clicked!");
  } else {
    btnText.set("Click!");
  }
});

This is just a peek at the Lambda expressions to be introduced in Project Lambda (JSR-335). I would take some time to dive a bit into detail of Lambda expressions.