本文转自开源中国:http://www.oschina.net/translate/everything-about-java-8
这篇文章是对Java 8中即将到来的改进做一个面向开发者的综合性的总结,JDK的这一特性将会在2013年9月份发布。
在写这篇文章的时候,Java 8的开发工作仍然在紧张有序的进行中,语言特新和API仍然有可能改变,我会尽我最大的努力保持这份文档跟得到Java 8的改动。
Java 8的预览版,也就是 “Project Lambda”,现在可以从java.net下载到。
我使用了IntelliJ的预览版做我的IDE,在我看来他是目前支持java 8特性最好的一个IDE,你可以从这里下载到.
由于我没有找到Oracle发布的Java 8的官方文档,所以目前Java 8的文档还只有本地版本,等Oracle公开文档的时候,我将会重新链接到官方文档。
接口改善
现在接口里已经完全可以定义静态方法了. 举一个比较普遍的例子就是在java类库中, 对于一些接口如Foo, 都会有一个有静态方法的工具类Foos 来生成或者配合Foo对象实例来使用. 既然静态方法可以存在于接口当中, 那么大多数情况下 Foos工具类完全可以使用接口中的公共方法来代理 (或者将Foos置成package-private).
除此之外更重要的就是, Java 8中接口可以定义默认的方法了.举个例子,一个for-each循环的方法就可以加入到java.lang.Iterable中:
public default void forEach(Consumer<? super T> action) {
Objects.requireNonNull(action); for (T t : this) {
action.accept(t);
}
}
在过去,java类库的接口中添加方法基本上是不可能的. 在接口中添加方法意味着破坏了实现了这个接口的代码. 但是现在, 只要能够提供一个正确明智的默认的方法的实现, java类库的维护者就可以在接口中添加方法.
Java 8中, 大量的默认方法已经被添加到核心的JDK接口中了. 稍候我会详细介绍它们.
为什么不能用默认方法来重载equals,hashCode和toString?
接口不能提供对Object类的任何方法的默认实现。特别是,这意味着从接口里不能提供对equals,hashCode或toString的默认实现。
这刚看起来挺奇怪的,但考虑到一些接口实际上是在文档里定义他们的equals行为的。List接口就是一个例子了。因此,为什么不允许这样呢?
Brian Goetz在这个问题上的冗长的回复里给出了4个原因。我这里只说其中一个,因为那个已经足够说服我了:
它会变得更困难来推导什么时候该调用默认的方法。现在它变得很简单了:如果一个类实现了一个方法,那总是优先于默认的实现的。一旦所有接口的实例都是Object的子类,所有接口实例都已经有对equals/hashCode/toString的非默认实现。因此,一个在接口上这些的默认版本都是没用的,它也不会被编译。
要看更多的话,看下由Brian Goetz写的解释: 对“允许默认方法来重载Object的方法”的回复
函数式接口
Java 8 引入的一个核心概念是函数式接口。如果一个接口定义个唯一一个抽象方法,那么这个接口就成为函数式接口。比如,java.lang.Runnable就是一个函数式接口,因为它只顶一个一个抽象方法:
public abstract void run();
留意到“abstract”修饰词在这里是隐含的,因为这个方法缺少方法体。为了表示一个函数式接口,并非想这段代码一样一定需要“abstract”关键字。
默认方法不是abstract的,所以一个函数式接口里可以定义任意多的默认方法,这取决于你。
同时,引入了一个新的Annotation:@FunctionalInterface。可以把他它放在一个接口前,表示这个接口是一个函数式接口。加上它的接口不会被编译,除非你设法把它变成一个函数式接口。它有点像@Override,都是声明了一种使用意图,避免你把它用错。
Lambdas
一个函数式接口非常有价值的属性就是他们能够用lambdas来实例化。这里有一些lambdas的例子:
左边是指定类型的逗号分割的输入列表,右边是带有return的代码块:
(int x, int y) -> { return x + y; }
左边是推导类型的逗号分割的输入列表,右边是返回值:
(x, y) -> x + y
左边是推导类型的单一参数,右边是一个返回值:
x -> x * x
左边没有输入 (官方名称: "burger arrow"),在右边返回一个值:
() -> x
左边是推导类型的单一参数,右边是没返回值的代码块(返回void):
x -> { System.out.println(x); }
静态方法引用:
String::valueOf
非静态方法引用:
Object::toString
继承的函数引用:
x::toString
构造函数引用:
ArrayList::new
你可以想出一些函数引用格式作为其他lambda格式的简写。
方法引用 | 等价的lambda表达式 | |
---|---|---|
String::valueOf | x -> String.valueOf(x) | |
Object::toString | x -> x.toString() | |
x::toString | () -> x.toString() | |
ArrayList::new | () -> new ArrayList<>() |
当然,在Java里方法能被重载。类可以有多个同名但不同参数的方法。这同样对构造方法有效。ArrayList::new能够指向它的3个构造方法中任何一个。决定使用哪个方法是根据在使用的函数式接口。
一个lambda和给定的函数式接口在“外型”匹配的时候兼容。通过“外型”,我指向输入、输出的类型和声明检查异常。
给出两个具体有效的例子:
Comparator<String> c = (a, b) -> Integer.compare(a.length(),
b.length());
一个Comparator<String>的compare方法需要输入两个阐述,然后返回一个int。这和lambda右侧的一致,因此这个任务是有效的。
Runnable r = () -> { System.out.println("Running!"); }
一个Runnable的run方法不需要参数也不会返回值。这和lambda右侧一致,所以任务有效。
在抽象方法的签名里的受检查异常(如果存在)也很重要。如果函数式接口在它的签名里声明了异常,lambda只能抛出受检查异常。
捕获和非捕获的Lambda表达式
当Lambda表达式访问一个定义在Lambda表达式体外的非静态变量或者对象时,这个Lambda表达式称为“捕获的”。比如,下面这个lambda表达式捕捉了变量x:
int x = 5; return y -> x + y;
为了保证这个lambda表达式声明是正确的,被它捕获的变量必须是“有效final”的。所以要么它们需要用final修饰符号标记,要么保证它们在赋值后不能被改变。
Lambda表达式是否是捕获的和性能悄然相关。一个非不捕获的lambda通常比捕获的更高效,虽然这一点没有书面的规范说明(据我所知),而且也不能为了程序的正确性指望它做什么,非捕获的lambda只需要计算一次. 然后每次使用到它都会返回一个唯一的实例。而捕获的lambda表达式每次使用时都需要重新计算一次,而且从目前实现来看,它很像实例化一个匿名内部类的实例。
lambdas不做的事
你应该记住,有一些lambdas不提供的特性。为了Java 8它们被考虑到了,但是没有被包括进去,由于简化以及时间限制的原因。
Non-final* 变量捕获 - 如果一个变量被赋予新的数值,它将不能被用于lambda之中。"final"关键字不是必需的,但变量必须是“有效final”的(前面讨论过)。这个代码不会被编译:
int count = 0;
List<String> strings = Arrays.asList("a", "b", "c");
strings.forEach(s -> {
count++; // error: can't modify the value of 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 });
}
有绕过这个的办法,你能定义自己的功能性接口,扩展Consumer的同时通过像RuntimeException之类抛出 IOException。我试图用代码写出来,但发现它令人困惑是否值得。
控制流程 (break, early return) -在上面的 forEach例子中,传统的继续方式有可能通过在lambda之内放置 "return;"来实现。但是,没有办法中断循环或者从lambda中通过包含方法的结果返回一个数值。例如:
final String secret = "foo"; boolean containsSecret(Iterable<String> values) {
values.forEach(s -> { if (secret.equals(s)) {
??? // want to end the loop and return true, but can't }
});
}
进一步阅读关于这些问题的资料,看看这篇Brian Goetz写的说明:
在 Block<T>中响应“已验证例外”
为什么抽象类不能通过利用lambda实例化
抽象类,哪怕只声明了一个抽象方法,也不能使用lambda来实例化。
下面有两个类 Ordering 和 CacheLoader的例子,都带有一个抽象方法,摘自于Guava 库。那岂不是很高兴能够声明它们的实例,像这样使用lambda表达式?
CacheLoader<String, String> loader = (key) -> ...;
这样做引发的最常见的争论就是会增加阅读lambda的难度。以这种方式实例化一段抽象类将导致隐藏代码的执行:抽象类的构造方法。
另一个原因是,它抛出了lambda表达式可能的优化。在未来,它可能是这种情况,lambda表达式都不会计算到对象实例。放任用户用lambda来声明抽象类将妨碍像这样的优化。
此外,有一个简单地解决方法。事实上,上述两个摘自Guava 库的实例类已经证明了这种方法。增加工厂方法将lambda转换成实例。
Ordering<String> order = Ordering.from((a, b) -> ...);
CacheLoader<String, String> loader = CacheLoader.from((key) -> ...);
要深入阅读,请参
看由 Brian Goetz所做的说明:
response to "Allow lambdas to implement abstract classes"
。
java.util.function
作为Comparator 和Runnable早期的证明,在JDK中已经定义的接口恰巧作为函数接口而与lambdas表达式兼容。同样方式可以在你自己的代码中定义任何函数接口或第三方库。
但有特定形式的函数接口,且广泛的,通用的,在之前的JD卡中并不存在。大量的接口被添加到新的java.util.function 包中。下面是其中的一些:
- Function<T, R> -T作为输入,返回的R作为输出
- Predicate<T> -T作为输入,返回的boolean值作为输出
- Consumer<T> - T作为输入,执行某种动作但没有返回值
- Supplier<T> - 没有任何输入,返回T
- BinaryOperator<T> -两个T作为输入,返回一个T作为输出,对于“reduce”操作很有用
这些最原始的特征同样存在。他们以int,long和double的方式提供。例如:
- IntConsumer -以int作为输入,执行某种动作,没有返回值
这里存在性能上的一些原因,主要释在输入或输出的时候避免装箱和拆箱操作。
java.util.stream
包汇总: java.util.stream
新的java.util.stream包提供了“支持在流上的函数式风格的值操作”(引用javadoc)的工具。可能活动一个流的最常见方法是从一个collection获取:
Stream<T> stream = collection.stream();
一个流就像一个地带器。这些值“流过”(模拟水流)然后他们离开。一个流可以只被遍历一次,然后被丢弃。流也可以无限使用。
流能够是 串行的 或者 并行的。 它们可以使用其中一种方式开始,然后切换到另外的一种方式,使用stream.sequential()或stream.parallel()来达到这种切换。串行流在一个线程上连续操作。而并行流就可能一次出现在多个线程上。
所以,你想用一个流来干什么?这里是在javadoc包里给出的例子:
int sumOfWeights = blocks.stream().filter(b -> b.getColor() == RED)
.mapToInt(b -> b.getWeight())
.sum();
注意:上面的代码使用了一个原始的流,以及一个只能用在原始流上的sum()方法。下面马上就会有更多关于原始流的细节。
流提供了流畅的API,可以进行数据转换和对结果执行某些操作。流操作既可以是“中间的”也可以是“末端的”。
- 中间的 -中间的操作保持流打开状态,并允许后续的操作。上面例子中的filter和map方法就是中间的操作。这些操作的返回数据类型是流;它们返回当前的流以便串联更多的操作。
- 末端的 - 末端的操作必须是对流的最终操作。当一个末端操作被调用,流被“消耗”并且不再可用。上面例子中的sum方法就是一个末端的操作。
通常,处理一个流涉及了这些步骤:
- 从某个源头获得一个流。
- 执行一个或更多的中间的操作。
- 执行一个末端的操作。
有几个更普通的关于流操作的特性需要考虑:
- 有状态的 - 有状态的操作给流增加了一些新的属性,比如元素的唯一性,或者元素的最大数量,或者保证元素以排序的方式被处理。这些典型的要比无状态的中间操作代价大。
- 短路 - 短路操作潜在的允许对流的操作尽早停止,而不去检查所有的元素。这是对无限流的一个特殊设计的属性;如果对流的操作没有短路,那么代码可能永远也不会终止。
对每个Sttream方法这里有一些简短的,一般的描述。查阅javadoc获取更详尽的解释。下面给出了每个操作的重载形式的链接。
中间的操作:
- filter 1 - 排除所有与断言不匹配的元素。
- map 1 2 3 4 - 通过Function对元素执行一对一的转换。
- flatMap 1 2 3 4 5 - 通过FlatMapper将每个元素转变为无或更多的元素。
- peek 1 - 对每个遇到的元素执行一些操作。主要对调试很有用。
- distinct 1 - 根据.equals行为排除所有重复的元素。这是一个有状态的操作。
- sorted 1 2 - 确保流中的元素在后续的操作中,按照比较器(Comparator)决定的顺序访问。这是一个有状态的操作。
- limit 1 - 保证后续的操作所能看到的最大数量的元素。这是一个有状态的短路的操作。
- substream 1 2 - 确保后续的操作只能看到一个范围的(根据index)元素。像不能用于流的String.substring一样。也有两种形式,一种有一个开始索引,一种有一个结束索引。二者都是有状态的操作,有一个结束索引的形式也是一个短路的操作。
末端的操作:
- forEach 1 - 对流中的每个元素执行一些操作。
- toArray 1 2 - 将流中的元素倾倒入一个数组。
- reduce 1 2 3 - 通过一个二进制操作将流中的元素合并到一起。
- collect 1 2 - 将流中的元素倾倒入某些容器,例如一个Collection或Map.
- min 1 - 根据一个比较器找到流中元素的最小值。
- max 1 -根据一个比较器找到流中元素的最大值。
- count 1 - 计算流中元素的数量。
- anyMatch 1 - 判断流中是否至少有一个元素匹配断言。这是一个短路的操作。
- allMatch 1 - 判断流中是否每一个元素都匹配断言。这是一个短路的操作。
- noneMatch 1 - 判断流中是否没有一个元素匹配断言。这是一个短路的操作。
- findFirst 1 - 查找流中的第一个元素。这是一个短路的操作。
- findAny 1 - 查找流中的任意元素,可能对某些流要比findFirst代价低。这是一个短路的操作。
有针对int,long和double的专业原始的Stream版本:
可以在众多函数中,通过专业原始的map和flatMap函数,在一个stream对象与一个原始stream对象之间来回转换。给几个虚设例子:
List<String> strings = Arrays.asList("a", "b", "c");
strings.stream() //
Stream<String> .mapToInt(String::length) // IntStream .longs() //
LongStream .mapToDouble(x -> x / 10.0) // DoubleStream .boxed() //
Stream<Double> .mapToLong(x -> 1L) // LongStream .mapToObj(x -> "") //
Stream<String> ...
原始的stream也为获得关于stream的基础数据统计提供方法,那些stream是指作为数据结构的。你可以发现count, sum, min, max, 以及元素平均值全部是来自于一个终端的操作。
原始类型的剩余部分没有原始版本,因为这需要一个不可接受的JDK数量的膨胀。IntStream, LongStream, 和 DoubleStream被认为非常有用应当被包含进去,其他的数字型原始stream可以由这三个通过扩展的原始转换来表示。
在flatMap操作中使用的 FlatMapper 接口是具有一个抽象方法的功能性接口:void flattenInto(T element, Consumer<U> sink);
在一个flatMap操作的上下文中,stream为你提供element和 sink,然后你定义该用element 和 sink做什么。element是指在stream中的当前元素,
而sink代表当flatMap操作结束之后在stream中应该显示些什么。例如:
Set<Color> colors = ...;
List<Person> people = ...;
Stream<Color> stream = people.stream().flatMap(
(Person person, Consumer<Color> sink) -> { // Map each person to the colors they like. for (Color color : colors) { if (person.likesColor(color)) {
sink.accept(color);
}
}
});
注意上面lambda中的参数类型是指定的。在大多数其它上下文中,你可以不需要指定类型,但这里由于FlatMapper的自然特性,编译器需要你帮助判定类型。如果你在使用flatMap又迷惑于它为什么不编译,可能是因为你没有指定类型。
最令人感到困惑,复杂而且有用的终端stream操作之一是collect。它引入了一个称为Collector的新的非功能性接口。这个接口有些难理解,但幸运的是有一个Collectors工具类可用来产生所有类型的有用的Collectors。例如:
List<String> strings = values.stream()
.filter(...)
.map(...)
.collect(Collectors.toList());
如果你想将你的stream元素放进一个Collection,Map或String,那么Collectors可能具有你需要的。在javadoc中浏览那个类绝对是值得的。
泛型接口改进
这是一个以前不能做到的,对编译器判定泛型能力的努力改进。在以前版本的Java中有许多情形编译器不能给某个方法计算出泛型,当方法处于嵌套的或串联方法调用这样的上下文的时候,即使有时候对程序员来说它看起来“很明显”。那些情况需要程序员明确的指定一个“类型见证”(type witness)。它是一种通用的特性,但吃惊的是很少有Java程序员知道(我这么说是基于私下的交流并且阅读了一些StackOverflow的问题)。它看起来像这样:
// In Java 7: foo(Utility.<Type>bar());
Utility.<Type>foo().bar();
如果没有类型见证,编译器可能会将<Object>替代为泛型,而且如果需要的是一个更具体的类型,代码将编译失败。
Java 8 极大的改进了这个状况。在更多的案例中,它可以基于上下文计算出更多的特定的泛型类型。// In Java 8: foo(Utility.bar());
Utility.foo().bar();
这项工作仍在发展中,所以我不确定建议中列出的例子有多少能真正包含进Java 8。希望是它们全部。
java.time
包概要: java.time
在Java8中新的 date/timeAPI存在于 java.time包中。如果你熟悉Joda Time,它将很容易掌握。事实上,我认为如此好的设计,以至于从未听说过 Joda Time的人也能很容易的掌握。
几乎在API中的任何东西都是永恒的,包括值类型和格式化 。对于Date域或者处理或处理本地线程日期格式化不必太过担心。
与传统的date/timeAPI的交叉是最小的。有一个清晰的分段:
新API对于像月份和每周的天数,喜欢枚举类型更胜过整形常量。
那么,那是什么呢?包级别的javadocs 对额外类型的做出了非常好的阐述。我将对一些值得注意的部分做一些简短的纲要。
非常有用的值类型:
- Instant - 与java.util.Date相似
- ZonedDateTime, ZoneId -时区很重要的时候使用
- OffsetDateTime, OffsetTime, ZoneOffset -对UTC的偏移处理
- Duration, Period - 但如果你想找到两个日期之间的时间量,你可能会寻找ChronoUnit代替(见下文)
其他有用的类型:
- DateTimeFormatter - 将日期类型转换成字符串类型
- ChronoUnit - 计算出两点之间的时间量,例如ChronoUnit.DAYS.between(t1, t2)
- TemporalAdjuster - 例如date.with(TemporalAdjuster.firstDayOfMonth())
大多数情况下,新的值类型由JDBC提供支持。有一小部分异常,如ZonedDateTime在SQL中没有对应的(类型)。
集合API附件
实际上接口能够定义默认方法允许了JDK作者加入大量的附件到集合API接口中。默认实现在核心接口里提供,而其他更有效或更好的重载实现被加入到可适用的具体类中。
这里是新方法的列表:
- Iterable.forEach(Consumer)
- Iterator.forEach(Consumer)
- Collection.removeAll(Predicate)
- Collection.spliterator()
- Collection.stream()
- Collection.parallelStream()
- List.sort(Comparator)
- Map.forEach(BiConsumer)
- Map.replaceAll(BiFunction)
- Map.putIfAbsent(K, V)
- Map.remove(Object, Object)
- Map.replace(K, V, V)
- Map.replace(K, V)
- Map.computeIfAbsent(K, Function)
- Map.computeIfPresent(K, BiFunction)
- Map.compute(K, BiFunction)
- Map.merge(K, V, BiFunction)
- Map.getOrDefault(Object, V)
同样, Iterator.remove() 现在有一个默认的, 会抛出异常的实现,使得它稍微容易地去定义不可修改的迭代器。
Collection.stream()和Collection.parallelStream()是流API的主要门户。有其他方法去生成流,但这些在以后会更为长用。
List.sort(Comparator)的附件有点怪异。以前排序一个ArrayList的方法是:
1
|
Collections.sort(list, comparator);
|
这代码是你在Java7里唯一可选的,非常低效。它会复制list到一个数组里,排序这个数组,然后使用ListIterator来把数组插入到新list的新位置上。
List.sort(比较器)的默认实现仍然会做这个,但是具体的实现类可以自由的优化。例如,ArrayList.sort在ArrayList内部数组上调用了Arrays.sort。CopyOnWriteArrayList做了同样的事情。
从这些新方法中获得的不仅仅是性能。它们也具有更多的令人满意的语义。例如, 对Collections.synchronizedList()排序是一个使用了list.sort的原子操作。你可以使用list.forEach对它的所有元素进行迭代,使之成为原子操作。
Map.computeIfAbsent使得操作类似多重映射的结构变得容易了:
// Index strings by length:
Map<Integer, List<String>> map = new HashMap<>(); for (String s : strings) {
map.computeIfAbsent(s.length(),
key -> new ArrayList<String>())
.add(s);
} // Although in this case the stream API may be a better choice:
Map<Integer, List<String>> map = strings.stream()
.collect(Collectors.groupingBy(String::length));
增加并发API
- ForkJoinPool.commonPool()
- ConcurrentHashMap(v8)
- 下面的形式有并行,顺序,对象,整型,长整型和double型。
有太多的链接可以点击,因此参看ConcurrentHashMap javadocs文档以获得更多信息。
- ConcurrentHashMap.reduce...
- ConcurrentHashMap.search...
- ConcurrentHashMap.forEach...
- ConcurrentHashMap.newKeySet()
- ConcurrentHashMap.newKeySet(int)
- CompletableFuture
- StampedLock
- LongAdder
- LongAccumulator
- DoubleAdder
- DoubleAccumulator
- CountedCompleter
- Executors.newWorkStealingPool()
- Executors.newWorkStealingPool(int)
- 下面的形式有AtomicReference, AtomicInteger, AtomicLong, 和每一个原子数组的版本。
- AtomicReference.getAndUpdate(UnaryOperator)
- AtomicReference.updateAndGet(UnaryOperator)
- AtomicReference.getAndAccumulate(V, UnaryOperator)
- AtomicReference.accumulateAndGet(V, UnaryOperator)
ConcurrentHashMap.newKeySet()提供了一个并发的java.util.Set实现。它基本上是Collections.newSetFromMap(new ConcurrentHashMap<T, Boolean>())的另一种方式的重写。
StampedLock是一种新型锁的实现,很可能在大多数场景都可以替代ReentrantReadWriteLock。当作为一个简单的读写锁的时候,它比RRWL的性能要好。它也为“读优化”提供了API,通过它你获得了一个功能有点弱,但代价很小的读操作锁的版本,执行读操作,然后检查锁是否被一个写操作设定为无效。在Heinz Kabutz汇总的一系列幻灯片中,有更多关于这个类及其性能的细节(在这个系列幻灯片大约一半的地方开始的):"移相器和StampedLock演示"
CompletableFuture<T>是Future接口的一个非常棒的实现,它提供了无数执行(和串接)异步任务的方法。它特别依赖功能性的接口;lambdas是值得增加这个类的一个重要原因。如果你正在使用Guava的 Future工具,例如Futures,ListenableFuture, 和 SettableFuture,那么你可能会希望校验CompletableFuture能否作为潜在的替代选择。
IO/NIO API的新增内容
- BufferedReader.lines()
- Files.list(Path)
- Files.walk(Path, int, FileVisitOption...)
- Files.walk(Path, FileVisitOption...)
- Files.find(Path, int, BiPredicate, FileVisitOption...)
- Files.lines(Path, Charset)
- DirectoryStream.entries()
简单的说,这些API用于从文件和InputStreams获取java.util.stream.Stream对象。不过它们与直接从常规的collection得到的流有些不同,它们引入了两个概念:
- UncheckedIOException - 当有IO错误时抛出这个异常,不过由于Iterator/Stream的签名中不允许有IOException,所以它只能借助于unchecked异常。
- CloseableStream - 可以(并且应该)定义在 try-with-resources 语句里面的流。
反射和annotation的改动
- 类型annotation (JSR 308)
- AnnotatedType
- Repeatable
- Method.getAnnotatedReturnType()
- Field.getAnnotationsByType(Class)
- Field.getAnnotatedType()
- Constructor.getAnnotatedReturnType()
- Parameter - 支持 parameter.getName(),等等。
Annotation允许在更多的地方被使用,例如List<@Nullable String>。受此影响最大的可能是那些静态分析工具,如Sonar和FindBugs。
JSR 308的网站解释了增加这些改动的动机,介绍的不错: "类型Annotation (JSR 308) 和 Checker框架"
Nashorn JavaScript 引擎
提案的摘要: JEP 174: Nashorn JavaScript 引擎
我对Nashorn没什么经验,因而我对上面提案所描述的所知甚少。简单的说,它是 Rhino 的接替者。Rhino 显得有些老了,并且有点慢,开发者决定最好还是从头做一个。
其他新增,涉及java.lang,java.util,和java.sql
- ThreadLocal.withInitial(Supplier)
- String.join(CharSequence, Charsequence...)
- String.join(CharSequence, Iterable)
- 下面的方法适用于所有数字的原语类型,并且作为这些类型的包装(wrapper)类的三个方法。hashCode方法除外,它们的作用是作为BinaryOperatorin的reduce操作的参数。关于这些方法还有很多的链接,更多的内容,参考Integer, Long, Double, Float, Byte, Short, 和 Character 的javadoc。
- Primitive.min(primitive, primitive);
- Primitive.max(primitive, primitive);
- Primitive.sum(primitive, primitive);
- Primitive.hashCode(primitive)
- 同样,下面新增的 Boolean 的方法可用于BinaryOperator<Boolean>:
- Optional
- OptionalInt
- OptionalLong
- OptionalDouble
- Base64
- StringJoiner
- Spliterator
- Spliterators
- Comparator.reverseOrder()
- Comparator.thenComparing(Comparator)
- Comparator.thenComparing(Function, Comparator)
- Comparator.thenComparing(Function)
- Comparator.thenComparing(ToIntFunction)
- Comparator.thenComparing(ToLongFunction)
- Comparator.thenComparing(ToDoubleFunction)
- Comparators
- 下面的方法适用于数组,支持T[], int[], long[], double[]。关于这些方法有很多链接,更多信息参考 Arrays 的javadoc。
- Arrays.spliterator(array)
- Arrays.spliterator(array, int, int)
- Arrays.stream(array)
- Arrays.stream(array, int, int);
- Arrays.parallelStream(array)
- Arrays.parallelStream(array, int, int);
- Arrays.setAll(array, IntFunction)
- Arrays.parallelSetAll(array, IntFunction)
- Math.toIntExact(long)
- Math.addExact(int, int)
- Math.subtractExact(int, int)
- Math.multiplyExact(int, int)
- Math.floorDiv(int, int)
- Math.floorMod(int, int)
- Math.addExact(long, long)
- Math.subtractExact(long, long)
- Math.multiplyExact(long, long)
- Math.floorDiv(long, long)
- Math.floorMod(long, long)
- Integer.toUnsignedLong(int)
- Integer.toUnsignedString(int)
- Integer.toUnsignedString(int, int)
- Integer.parseUnsignedInt(String)
- Integer.parseUnsignedInt(String, int)
- Integer.compareUnsigned(int, int)
- Long.toUnsignedString(long, int)
- Long.toUnsignedString(long)
- Long.parseUnsignedLong(String, int)
- Long.parseUnsignedLong(String)
- Long.compareUnsigned(long, long)
- Long.divideUnsigned(long, long)
- Long.remainderUnsigned(long, long)
- BigInteger.longValueExact()
- BigInteger.intValueExact()
- BigInteger.shortValueExact()
- BigInteger.byteValueExact()
- Objects.isNull(Object) - 可用作谓词,例如stream.anyMatch(Objects::isNull)
- Objects.nonNull(Object) - 可用作谓词,stream.filter(Objects::nonNull)
- Random.ints()
- Random.longs()
- Random.doubles()
- Random.gaussians()
- BitSet.stream()
- IntSummaryStatistics
- LongSummaryStatistics
- DoubleSummaryStatistics
- Logger的杂项新增
- Locale的杂项新增
- ResultSet的杂项新增
这里可以介绍的太多了,只能挑一些最需要注意的项目。
ThreadLocal.withInitial(Supplier<T>) 可以在定义thread-local变量时更好的进行初始化。之前你初始化变量时是这样的:
ThreadLocal<List<String>> strings = new ThreadLocal<List<String>>() { @Override protected List<String> initialValue() { return new ArrayList<>();
}
};
现在则是这样:
ThreadLocal<List<String>> strings =
ThreadLocal.withInital(ArrayList::new);
stream的API的返回值有一个可选的<T>,就像min/max, findFirst/Any, 以及reduce的某些形式。这样做是因为stream中可能没有任何元素,但是它要提供一个一致的API,既可以处理“一些结果”,也可以处理“没有结果”。你可以提供默认值,抛异常,或者只在有结果的时候执行一些动作。
它与Guava's Optional类非常非常的相似。它一点都不像是在Scala里的操作,也不会试图成为之一,有相似的地方纯属巧合。