参考自:http://www.techempower.com/blog/2013/03/26/everything-about-java-8/
测试环境
$ java -version
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b106)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b48, mixed mode)
IntelliJ IDEA 12.1.4
接口改进
以前Java的接口里只能声明方法和定义常量,现在可以在接口里定义静态方法和默认方法。
定义静态方法
定义静态(static)方法带来的好处就是可以减少创建工具类的需求了。比如 java.util.Collection
接口定义了一个集合,对于此接口实例操作的很多通用方法都是通过工具类 java.util.Collections
来提供的,现在可以在接口里定义静态方法,我们就可以把工具类里的静态方法直接移到接口类里,不需要独立创建工具类了。
下面是Java8里添加到接口 java.util.Comparator
的一个静态方法:
public static <T extends Comparable<? super T>> Comparator<T> naturalOrder() {
return (Comparator<T>) Comparators.NaturalOrderComparator.INSTANCE;
}
定义默认方法
另一个改进是,可以在不破坏现有接口实现的前提下添加默认(default)方法。比如 java.lang.Iterable
接口现在拥有一个默认的 forEach
方法:
public default void forEach(Consumer<? super T> action) {
Objects.requireNonNull(action);
for (T t : this) {
action.accept(t);
}
}
默认方法不能覆盖 equals, hashCode, toString
方法
一个接口不能提供Object
类里的任何方法的默认实现。这意味着不能在接口里提供 equals, hashCode, toString
方法的默认实现。
关于这个,Brian Goetz 给出了四个理由,具体见: response to “Allow default methods to override Object’s methods”。
这里列出一个具有足够说服力的理由:
It would become more difficult to reason about when a default method is invoked. Right now it’s simple: if a class implements a method, that always wins over a default implementation. Since all instances of interfaces are Objects, all instances of interfaces have non-default implementations of equals/hashCode/toString already. Therefore, a default version of these on an interface is always useless, and it may as well not compile.
大意是:由于所有接口的实例都是Objects,那么所有实例都已有 equals/hashCode/toString
这些方法的非默认实现。因此,接口上这些方法的默认版本是没有用的,可能不会被编译。
函数接口
函数接口是Java8引入的一个核心概念。如果一个接口只定义了一个抽象方法,它就是函数接口。例如java.lang.Runnable
就是一个函数接口,因为它只定义了一个抽象方法: public void run()
。
默认方法不是抽象的,所以一个函数接口可以定义任意多的默认方法。
新引入的注解 @FunctionalInterface
用来表明接口准备成为函数接口,但不管有没有这个注解,编译器都认为只有一个抽象方法的接口是函数接口。
Lambdas
函数接口一个极具价值的属性是可以在lambdas里实例化。下面是lambdas的一些实例:
(param1 ParamType1, param2 ParamTeyp2, ... ) -> { statements; } // lambdas 完整形式
(int x, int y) -> { return x + y; } // 完整输入参数类型,具有返回语句的语句块
(x, y) -> x + y // 自动类型推导参数类型,语句块只有一条 return 语句时可以省略大括号和return关键字,
x -> x * x // 只有一个输入参数,可以省略入参列表的小括号。
() -> x // 如果没有入参,小括号不能省略。
x -> { System.out.println(x); } // 没有返回语句,语句块的大括号不能省略。
方法引用
静态方法引用: String::valueOf
。
非静态方法引用: Object::toString
。
构造函数引用: ArrayList::new
。
捕获方法引用: x::toString
。
方法引用等价的lambda表达式:
String::valueOf x -> String.valueOf(x)
Object::toString x -> x.toString()
x::toString () -> x.toString() // 这个好像不行
ArrayList::new () -> new ArrayList<>()
当然,在Java里可以重载方法。类可以有很多有同样名字但不同参数的方法,构造函数也一样。用哪个方法取决于它是用于哪个函数接口的。
一个lambda与一个函数接口有相同的“形状”时被认为是兼容的。这里的“形状”是指:输入输出的类型和声明的受检查异常。
举例
List<String> strList = new ArrayList<>();
strList.add("no");
strList.add("hello");
strList.add("world");
long count = strList
.stream()
.filter((String str) -> { return str != null; }) // 完整的lambda表达式
.filter(str -> { return str.length() > 0; }) // 参数类型自动推导;只有一个输入参数,省略小括号
.filter(str -> str.length() > 3) // 语句块只是返回一个表达式的值,省略return语句直接返回表达式的值;省略语句块的花括号。
.map(String::length) // 用方法代替lambda表达式
.count();
System.out.println("\n\ncount:" + count);
Runnable r = () -> { System.out.println("Running!"); };
Comparator<String> c = (a, b) -> Integer.compare(a.length(), b.length());
捕获与非捕获lambdas
如果lambda表达式访问一个定义在lambda体之外的非静态变量或对象,则说Lambda表达式是“捕获的”。在下面的例子里,return返回的lambda捕获了变量 x
:
int x = 5;
return y -> x + y;
为了让这个lambda声明是合法的,它捕获的变量必须是“effectively final”。这样,它们必须标记为 final
或 赋值(被lambda捕获)之后就不能再修改。
一个lambda捕获与否对性能有影响。一个非捕获的lambda一般比一个捕获的更高效。虽然这没有在任何规范里定义,你不能依赖于程序员的正确性。一个非捕获的lambda只需要计算一次。然后,它将返回一个完全相同的实例。捕获的lambda在每次遇到时都需要进行计算,当前的动作与实例化匿名内部类非常类似。
举例
private static int count = 0;
public static void main(String[] args) {
// basic ();
testCapture();
}
public static void testCapture() {
Runnable run = capture();
count++;
Runnable run2 = capture();
new Thread(run).start();
new Thread(run2).start();
}
public static Runnable capture() {
int x = 5;
Runnable r = () -> { System.out.println("x is:" + x); System.out.println("count is:" + count); };
// 在这里给x赋值也会报错 Variable used in lambda expression should be effectively final
return r;
}
执行后的输出是:
x is:5
count is:1
x is:5
count is:1
对于x的值都没有问题,但count的值就要注意了。进入testCapture()
方法的时候,count的值是0,第一次捕获的时候也是0,然后进行加1,再次进行捕获,然后用两个线程计算捕获的值,得到的值是1和1,而不是0和1,因为,lambda捕获只是捕获了变量的引用,而不是变量的值。
lambdas 不能做的
有些约束是lambdas不提供的,为了简单和由于时间约束。
非final变量捕获
如果一个变量被赋予新值,它就不能用在lambda里。“final”关键字不是必须的,但变量必须是“effectively final”(如前所述)。下面的代码将报编译错误:
int count = 0;
List<String> strings = Arrays.asList("a", "b", "c");
strings.forEach(s -> {
count++; // error: can't modify the value of count
});
注意,如果count是个非局部变量,它将是可以修改的。
异常透明
如果lambda代码体会抛出受检查的异常,函数接口必须声明它会抛出的受检查异常。异常不会传播到包含方法。下面的代码不能编译:
void appendAll(Iterable<String> values, Appendable out)
throws IOException { // doesn't help with the error
values.forEach(s -> {
out.append(s); // error: can't throw IOException here
// Consumer.accept(T) doesn't allow it
});
}
简单说就是lambda的代码块不能抛出受检查异常。
流程控制(break,early return)
在上面的forEach例子里,传统的“continue”可以是通过lambda体内的“return;”语句来达到。然而,没有方法来中断loop循环或从lambda内返回一个结果到包含方法。举例:
import java.util.Arrays;
public class Lambdas2 {
public static void main(String[] args) {
Arrays.asList(args).forEach(s -> {
if (s.length() > 3) {
return; // 这个return语句并不能终止loop循环。
}
});
}
}
上面的代码生成的字节码是这样的:
$ javap -c Lambdas2.class
Compiled from "Lambdas2.java"
public class Lambdas2 {
public Lambdas2();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: aload_0
1: invokestatic #2 // Method java/util/Arrays.asList:([Ljava/lang/Object;)Ljava/util/List;
4: invokedynamic #3, 0 // InvokeDynamic #0:accept:()Ljava/util/function/Consumer;
9: invokeinterface #4, 2 // InterfaceMethod java/util/List.forEach:(Ljava/util/function/Consumer;)V
14: return
}
结合前面 java.lang.Iterable
接口的forEach
方法实现可知,目前的lambda应该是编译成一个对象的,然后再对每个元素调用此对象的accept
方法,也就是说lambda代码块被编译成Consumer的accept方法的代码,所以不能在lambda代码块里控制forEach
的loop流程。
为什么抽象类不能用lambda实例化?
一个抽象类,即使它只有一个抽象方法,也不能用lambda实例化。
大多数反对这个的争论是这会增加阅读lambda的困难。以这种方式实例化一个抽象类会导致执行额外的隐藏代码:抽象类构造器里的代码。
另一个理由是这抛弃了优化lambda的可能。在将来,lambda可能将不再实例化为对象。允许用户以lambda的形式声明抽象类将阻止这类优化。
更多解释见:response to “Allow lambdas to implement abstract classes”
欢迎关注我的微信公众号: coderbee笔记,可以更及时回复你的讨论。