Java 8是极好的。不过我们在尝完鲜了之后，也开始对它持怀疑的态度。所有好的东西都是有代价的，在这篇
文章中，我会分享Java 8的主要的几个难点。在你放弃Java 7升级到8之前，你最好确保自己知道这些。
并行流会影响性能
Java 8的所承诺的并行处理是最受期待的新特性之一。集合以及流上的.parallelStream()方法就是实现这点的。它将问题分解成子问题，然后分别运行在不同的线程上，它们可能会被分配到不同的CPU核上，当完成之后再组合起来。这些全都是在底层通过fork/join框架来实现的。好的，听起来很酷吧，在多核环境下的大数据集上，这么做肯定能提升操作速度的，对吧？
不，如果你用的不对的话，这么做可能会让你的代码变得更慢。在我们运行的基准
测试上大概是慢了15%左右，而且还有可能会更糟。假设我们已经是运行在多核环境中了，我们又使用了.parallelStream()，将更多的线程加入了线程池中。这很可能会超出我们的核数的处理能力，并且由于上下文切换，会导致性能出现下降。
下面是我们的一个性能变差的基准测试，它是要将一个集合分到不同的组里（素数或者非素数）：
Map<Boolean, List<Integer>> groupByPrimary = numbers
.parallelStream().collect(Collectors.groupingBy(s -> Utility.isPrime(s)));
还有别的原因可能会让它变得更慢。考虑下这种情况，假设我们有多个任务要完成，其中一个可能花费的时间比其它的更长。将它用.parallelStream() 进行分解可能会导致更快的那些任务完成的时间往后推迟。看下Lukas Krecan的这篇文章，里面有更多的一些例子以及代码。
诊断：并行处理带来好处的同时也带来了许多额外的问题。当你已经是处于一个多核环境中了，你要时刻牢记这点，并要弄清楚事情表面下所隐藏的本质。
Lambda表达式的负作用
Lambda。喔，Lambda。尽管没有你，我们也什么都可以做，但是你让我们变得更优雅，减少了许多样板代码，因此大家都很容易会喜欢上你。假设一下早上我起床了想要遍历世界杯的一组球队，然后计算出它们的长度：
List lengths = new ArrayList();
for (String countries : Arrays.asList(args)) {
lengths.add(check(country));
}
如果有了Lambda我们就可以使用函数式了：
Stream lengths = countries.stream().map(countries -> check(country));
这太牛了。尽管很多时候它都是件好事，不过把Lambda这样的新元素增加到Java中使得它有点偏离了最初的设计规范。字节码是完全面向对象的，但同时这个游戏里又带上了lambda，实际的代码和运行时之间的差别变得越来越大了。可以读下Tal Weiss的这篇文章，了解更多关于lambda表达式的一些阴暗面。
最后，这意味着你所写的和你所调试的完全是两个不同的东西。栈信息会变得越来越大，这使得你调试代码变得更加费劲了。
将空串增加到列表里，原先只是这么简单的一个栈信息：
at LmbdaMain.check(LmbdaMain.java:19)
at LmbdaMain.main(LmbdaMain.java:34)
现在变成了：
at LmbdaMain.check(LmbdaMain.java:19) at LmbdaMain.lambda$0(LmbdaMain.java:37) at LmbdaMain$$Lambda$1/821270929.apply(Unknown Source) at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) at java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:512) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:502) at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.util.stream.LongPipeline.reduce(LongPipeline.java:438) at java.util.stream.LongPipeline.sum(LongPipeline.java:396) at java.util.stream.ReferencePipeline.count(ReferencePipeline.java:526) at LmbdaMain.main(LmbdaMain.java:39) |
lambda表达式引起的另一个问题就是重载：由于lambda的参数必须得强制转化成某个类型才能进行方法调用，而它们可以转化成好几个类型，这可能会导致调用发生歧义。Lukas Eder通过代码示例说明了这点。
诊断：记住这点，栈跟踪信息可能会成为一种痛苦，不过这并不会阻挡我们使用lambda的脚步。
默认方法使人困惑
默认方法使得接口方法的默认实现成为了可能。这的确是Java 8带来的一个非常酷的新特性，但是它多少影响了我们之前所习惯的做事的方式。那为什么还要引入它呢？什么时候不应该使用它？
默认方法背后最大的动机应该就是如果我们需要给现有的一个接口增加方法的话，我们可以不用重写接口的实现。这使得它可以兼容老的版本。比如说，下面是从Oracle官方的一个Java教程中拿过来的一段代码，它是要给一个指定的时区添加某个功能：
public interface TimeClient { // ... static public ZoneId getZoneId (String zoneString) { try { return ZoneId.of(zoneString); } catch (DateTimeException e) { System.err.println("Invalid time zone: " + zoneString + "; using default time zone instead."); return ZoneId.systemDefault(); } } default public ZonedDateTime getZonedDateTime(String zoneString) { return ZonedDateTime.of(getLocalDateTime(), getZoneId(zoneString)); } } |
问题解决了。是吗？但默认方法将接口及实现弄得有点混淆。类型结构自己是不会纠缠到一起的，所以现在我们得好好驯服下这个新生物了。可以读下RebelLabs的Oleg Shelajev的这篇文章。
诊断：当你抡起锤子的时候看谁都像颗钉子，记住了，要坚持原始的用例，将一个现有的接口重构成一个新的抽象类是不会有什么用处的。
下面讲的这些，要么是漏掉的，要么是该删除却仍在的，或者是还没有完全实现的：
为什么是Jigsaw
Jigsaw项目的目标是使得Java可以模块化，并将JRE分解成能互相协作的不同组件。项目的初衷是希望Java可以更好，更快，更强地进行嵌入。我已经尽量避免提起“物联网”了，但刚才实际已经说到了。减少JAR包的大小，提升性能，提高安全性，这些也是这个项目的一些愿景。
那么它怎么样了？Jigsaw目前已经通过了探索性的阶段，进入了第二阶段了，目前将致力于设计及实现能达到上线质量的产品，Oracle的首席架构师Mark Reinhold如是说。这个项目原本是计划随着Java8发布的，后来被推迟到了Java 9，这也是9中倍受期待的新特性之一。
遗留的问题
受检查异常
大家都不喜欢模板代码，这也是为什么lambda会如此流行的原因之一。想像一下异常的样板代码吧，不管你是不是需要捕获或者处理这些受检查异常，你都得去捕获它。尽管是根本不可能发生 的事情，就像下面这个一样，它压根儿就不会发生 ：
try {
httpConn.setRequestMethod("GET");
}?catch (ProtocolException pe) { /* Why don’t you call me anymore? */ }
基础类型
它们还在这里，要想正确地使用它们简直是种痛苦。正是它使得Java无法成为一门纯粹的面向对象的编程语言，并且其实上移除它们对性能也没有太大的影响。新的JVM语言里也都没有基础类型。
操作符重载
Java之父James Gosling曾在一次采访中说道：“我没有采用操作符重载这完全是我个人的喜好，因为我看过太多人在C++中滥用它了”。这也有一定的道理，不过也有不少反对的声音。别的JVM语言也提供了这一特性，但另一方面，它可能会导致下面这样的代码：
javascriptEntryPoints <<= (sourceDirectory in Compile)(base =>
((base / "assets" ** "*.js") --- (base / "assets" ** "_*")).get
)
这是Scala的Play框架中的一行真实的代码，我已经有点崩溃了。
诊断：这些真的算是问题吗？我们都有自己的怪癖，这些也算是Java的吧。未来的版本可能会有惊喜，这些也可能会变，但是向后兼容的问题也在那里等着我们了。
函数式编程
Java之前也可以进行函数式编程，虽然说有点勉强。Java 8通过lambda以及别的一些东西改进了这一状态。这确实是最受欢迎的特性，不过并没有之前传说中的那么大的变化。它是比Java 7要优雅多了，不过要想成为真正的函数式语言还有很长的路要走。
关于这个问题最激烈的评论应该是来自Pierre-yves Saumont 的这一系列的文章了，他详细比较了函数式编程的范式和Java的实现方式之间的区别。
那么该用Scala还是Java？Java采用了更现代的函数式范式也算是对Scala的一种认可，后者提供lambda也有一段时间了。lambda确实是独领风骚，但是还有许多别的特性比如说trait，惰性求值，不可变性等，它们也是Scala不同于Java之处。
诊断： 不要被lambda分心了，Java 8算不算函数式编程仍在争论当中。