Java与Scala中的闭包

　　原文地址：Closures in Java and Scala
　　翻　　译：Eastsun


　　People argue that verbose code is easier to understand. Do you agree when reading these two examples, one method in Java, one in Scala?
　　人们普遍认为，详细的代码更易于理解。但如果你阅读下面两段代码--一个使用Java另一个使用Scala--你是否还这样认为呢？

public List<Item> bought(User user) {
    List<Item> result = new ArrayList();
    for (Item item : currentItems) {
        if (user.bought(item)) {
            result.add(item);
        }
    }
    return result;
}

def bought(user: User) = items.filter(user bought _)

　　If you are familiar with Java, which is more likely then you being familiar with Scala, you may tend to the Java-version. Scala has a different syntax for declaring types and generics, and supports closures, including anonymous parameters (the underscore).
　　如果你熟悉Java，那么很可能你将会了解到Scala。也许你会倾向于使用Java的版本。Scala具有不同的类型声明以及泛型语法，并且支持闭包，以及匿名参数(下划线)。

　　When Closures are introduced in one of the next Java releases, JDK 7 or 8, the example could be rewritten like this:
　　在Java的后续版本中引入闭包后（JDK7或JDK8），上面Java版的代码可以重写为：

public List<Item> bought(User user) {   
    return ListUtils.filter(Item item : items ) {      
        user.bought(item);    
    }
}

　　Or with extension methods:
　　或者使用方法扩展：

public List<Item> bought(User user) { 
    return items.filter(Item item : )  { 
        // <-- note the smily! thats what its all about!
        user.bought(item);
    }
}

　　The interesting differences between Java with closures and Scala is the static typing: Scala inferences that items are all of type Item, so there is no need to specify that information again.

　　带有闭包的Java与Scala一个让人感兴趣的区别是它们的静态类型：Scala的类型推断能力能得到其所有变量的类型，因此不需要再指明这一点。

　　So, while the current Java Closures specification is a great step in the right direction, lead by Neil Gafter, who is quite the right man for the job, it may not be worth to wait for it, if you have the choice. Its not even sure yet that we'll see that spec implemented in JDK7, and even that is at best one and a half year away.
　　因此，即便目前的JAVA闭包规范在Neil Gafter的领导下正朝着正确的方向做出了很大的进步；但我们也未必需要去等待它，如果我们已经有了其他选择。何况JDK7中会不会实现闭包现在还没有确定--即便是，那也至少是一年半以后的事了。

刚刚试验了下java7:
class A{
    static { => int } answer = { => 42 };
    public static void main(String[] args) {
      int i = answer.invoke();
      System.out.println(i);
      int temp=new A().add({int x,int y=>x*x+y*y});
      System.out.println(temp);
    }
     public int add({ int,int=>int } s){
     return s.invoke(3, 4);
     }

}

我说说我对闭包的理解，看看片面不，我理解的闭包是一个处理的输入和输出类型项相同，这样这次的输出就可以作为下次的输入在次处理。
说这个我想到了关于“关系数据库”和“对象数据库”的争论，关系数据库存储的数据，通过应用系统的持久层转化为对象模型是有很大困难的，这其中原因在于“关系”和“对象”的存储方式不同，但是关系模型之所以流行，和sql语句密不可分，sql本身遵循闭包原则，致使一次查询结果可以作为下次查询条件，人们可以指学习少量关键词就能拼装成很复杂的查询语句，闭包是数学名词，有着数学上的天然对称美。
至于java语言的闭包，我不完全理解，不过我相信就算jdk还没有提供，使用者也可以自己撰写自己的闭包类，现在我考虑的是java会不会加入语义级别的闭包。