问题描述
|
不久前，Oracle决定将Closures添加到Java 8是一个好主意。我不知道与第一天就关闭的Scala相比，那里的设计问题是如何解决的。
引用javac.info中的未解决问题：
方法句柄可以用于函数类型吗？
如何使这项工作尚不清楚。一个问题是“方法句柄”可以对类型参数进行验证，但是会干扰函数子类型化。
我们可以摆脱“ throws”类型参数的显式声明吗？
想法是，只要声明的边界是检查的异常类型，就使用析取类型推断。这不是严格的向后兼容，但是不太可能破坏实际的现有代码。但是，由于句法歧义性，我们可能无法摆脱类型参数中的“抛出”。
禁止在老式循环索引变量上使用@Shared
处理诸如Comparator之类的接口，它们定义了多个方法，除一个接口外，所有接口都将由从Object继承的方法实现。
“具有单个方法的接口”的定义应仅计入对象中某个方法无法实现的方法，并且如果实现其中一个可以全部实现，则应将多个方法视为一个方法。主要是，这要求对接口仅具有一个抽象方法的含义进行更精确的说明。
指定从功能类型到接口的映射：名称，参数等。
我们应该完全指定从函数类型到系统生成的接口的精确映射。
类型推断。需要增加类型推断的规则以适应异常类型参数的推断。同样，闭包转换使用的子类型关系也应得到反映。
消除了异常类型参数，以帮助改进异常透明性。
也许使被忽略的异常类型参数意味着界限。这样可以通过添加新的泛型异常参数来改造不具有异常类型参数的现有泛型接口，例如java.util.concurrent.Callable。
函数类型的类文字是如何形成的？
是#void（）。class吗？如果是这样，如果删除了对象类型，它将如何工作？是＃？（？）。class吗？
系统类加载器应动态生成函数类型接口。
与功能类型相对应的接口应由引导类加载器按需生成，以便可以在所有用户代码之间共享。对于原型，我们可以让javac生成这些接口，以便原型生成的代码可以在常规（JDK5-6）VM上运行。
每次对lambda表达式求值都必须产生一个新对象吗？
希望不会。例如，如果lambda没有从封闭范围中捕获任何变量，则可以静态分配它。同样，在其他情况下，如果lambda无法捕获在循环内部声明的任何变量，则可以将其移出内部循环。因此，最好的是，该规范对lambda表达式的结果的引用标识不做任何承诺，因此，此类优化可由编译器完成。
据我了解，2.，6.和7.在Scala中不是问题，因为Scala不会将Checked Exceptions用作Java之类的“影子类型系统”。
其余的呢？
解决方法
1）方法句柄可以用于函数类型吗？
Scala的目标对象是没有方法句柄的JDK 5和6，因此它尚未尝试解决该问题。
2）我们可以摆脱“ throws”类型参数的显式声明吗？
Scala没有检查过的异常。
3）禁止在老式循环索引变量上使用@Shared。
Scala没有循环索引变量。同样，可以通过某种while循环来表达相同的想法。 Scala的语义在这里非常标准。捕获符号绑定，如果符号碰巧映射到可变参考单元格，那么就由您自己决定。
4）处理诸如Comparator之类的接口，这些接口定义了不止一种方法，但所有方法均来自对象
Scala用户倾向于使用函数（或隐式函数）将正确类型的函数强制转换为接口。例如
[implicit] def toComparator[A](f : (A,A) => Int) = new Comparator[A] {
def compare(x : A,y : A) = f(x,y)
}
classOf[A => B] //or,equivalently,classOf[Function1[A,B]]
classOf[ _ => _ ] // or
classOf[Function1[ _,_ ]]
Runnable
(A,A) => Int
List[A]
def runnable(f: () => Unit) = new Runnable {
def run() = f()
}
runnable { () => println(\"Hello\") } // creates a Runnable
runnable
implicit
Runnable
() => Unit
Comparator
(A,A) => Boolean
(A,A) => Int
Ordering
Comparator