Java 8 新特性之 接口改进和Lambdas

参考自: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”

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据