Alexander Schunk's Blog

Java Closures: programming in closures?

Why closures?

If i get things right the closures project aims to pack multiple statements into one logical program unit. For instance the following line would be a logical programming unit:

{
 int x = 3;
 int y = 4;
 int s => x + y;
}

So in this case you have two ints that you add together and this code works as one logic programming unit. I dont see between this code and this code:

int x = 4;
int y = 3;
int sum = x+y;
System.out.println("x + y " + sum);

And - if someone wants to use a more procedureal way - he can put this into a method as follows:

public int add(int x, int y){
return x+y;
}

However the closures project also offers a closures syntax for methods. Does this mean Java is making a shift to a more procedural programming philosphy? May be i am too far on the surface but i dont see the big benefit of closures right now but may be there is one i did not capture yet.

Comments

• And what about visibility of closures? Are they local or static i.g.:

  static {
  int a = 4;
  int b = 3;
  int s = 4 -3;

  }

  So in this case this would be a static closures statement. But i would prefer using closures in the main() method.
  

  Posted by: alexanderschunk on October 31, 2007 at 10:23 AM

• May be i am too far on the surface but i dont see the big benefit of closures right now but may be there is one i did not capture yet.
  One huge benefit of closures is it's value in providing code-level inversion of control. For example, consider the "each" pattern. Where you have three following cases of iteration:
  for(Iterator i=set.iterator();i.hasNext();) {
  Object v = i.next(); // Do something with v
  }
  for(int i=0;i<list.size();i++) {
  Object v = list.get(i); // Do something with v
  }
  for(int i=0;i<array.length;i++) {
  Object v = array[i]; // Do something with v
  }

  For the above, you are required to know something about the internals of the above "collections". JDK had to fix these cases by creating the "foreach" syntax. However, with closures no such syntax is required, since you can make an "Each" interface - where it is up to each type of list to iterate in whatever way it wants. From a user's point of view, it would be something like this:
  list.each { Object v|
  // Do something with v
  }

  Since the closure is passed into the "each" method, it removes the user from having to know anything about the style of collection - they only need to know that each closure will be executed once for each element (given the value, 'v'). You can make it even more general, but allowing flexible parameters, for example, a Map:
  map.each{ Object k, Object v|
  // Do something with key k and value v
  }

  Posted by: arikthered on October 31, 2007 at 01:48 PM

• So with closures it would be possible to write new Collection classes without making a difference of Iterators or Enumerations?
  This would really be an improvement because you dont need to worry wheather to use an iterator or enumeration and just need to call the .lis{} method.
  This would help implementing really abstract types as black bloxes you can use without worrying about their implementation. Cool.

  Posted by: alexanderschunk on October 31, 2007 at 02:45 PM

• Does this also work with Generics or is this just for concrete types?

  Posted by: alexanderschunk on October 31, 2007 at 02:50 PM

• The code on this page is not related to Java closures, as far as I can see. Java's closures proposal is a step towards functional programming rather than procedural programming. Functional programming is where you can pass a function to a method, which we're all already familiar with, think of Comparable and Runnable.

  Posted by: ricky_clarkson on October 31, 2007 at 07:07 PM

• I meant Comparator, not Comparable. Sorry.

  Posted by: ricky_clarkson on October 31, 2007 at 07:07 PM

This work is licensed under a Creative Commons License.