仍不切换到Java 8的6个理由

Java 8很棒。 期。 但是……在我们有机会玩耍并玩弄它之后，就该退出了，避免吃盐。 所有的好东西都是有代价的，在这篇文章中，我将分享Java 8的主要痛点。请确保在升级和放弃7之前您已经意识到了这些痛点。

1.并行流实际上会使您减速

Java 8将并行性作为最令人期待的新功能之一带来了希望。 .parallelStream（）方法在集合和流上实现此功能。 它将它们分解为子问题，然后在单独的线程上运行以进行处理，这些子问题可以进入不同的核心，然后在完成后组合在一起。 这一切都是在使用fork / join框架进行的 。 听起来不错，它必须加快多核环境中大型数据集的操作，对吗？

不，如果使用不正确，它实际上会使您的代码运行缓慢。 慢上大约15％ 这个基准，我们跑了，但它可能会更糟糕。 假设我们已经在运行多个线程，并且在其中一些线程中使用了.parallelStream（），从而向池中添加了越来越多的线程。 这很容易变成我们的核心无法处理的事情，并且由于增加了上下文切换而减慢了一切。

基准测试速度较慢，将集合分为不同的组（素数/非素数）：

Map<Boolean, List<Integer>> groupByPrimary = numbers
.parallelStream().collect(Collectors.groupingBy(s -> Utility.isPrime(s)));

同样，由于其他原因，速度也会变慢。 考虑到这一点，假设我们有多个任务要完成，由于某种原因，其中一个要比其他任务花费更长的时间。 使用.parallelStream（）分解它实际上可能会延迟完成较快的任务以及整个过程。 请查看Lukas Krecan的这篇文章，以获取更多示例和代码示例。

诊断：并行性及其所有优点也带来了其他类型的问题需要考虑。 当已经在多线程环境中执行操作时，请记住这一点，并使自己熟悉幕后发生的事情。

2. Lambda表达式的反面

Lambdas。 哦，lambdas。 如果没有您，我们几乎可以做所有我们已经可以做的事情，但是您却增加了很多宽限期，并且摆脱了样板代码，因此很容易坠入爱河。 假设我是早上起来 ，想遍历一队世界杯球队并确定他们的身长（有趣的事实：总数达到254）：

List lengths = new ArrayList();

for (String countries : Arrays.asList(args)) {
    lengths.add(check(country));
}

现在，让我们通过一个很好的lambda来实现功能：

Stream lengths = countries.stream().map(countries -> check(country));

宝贝！ 太好了 尽管……虽然通常被视为是一件好事，但在Java中添加诸如lambdas之类的新元素会使它进一步偏离其原始规范。 字节码完全为OO，并且在游戏中带有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 在此处通过代码示例对此进行了解释。

诊断：仅需注意这一点，痕迹可能会不时带来痛苦，但不会使我们远离它们。

3.默认方法会分散注意力

默认方法启用接口本身中功能的默认实现。 这无疑是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));
    }
}

就是这样，问题解决了。 还是？ 默认方法混淆了接口和实现的分离。 在错误的手中，仿佛类型层次结构不会自己纠结，现在我们需要驯服这种新生物。 在Oleg Shelajev在RebelLabs上的帖子中了解有关此内容的更多信息。

诊断：当您拿着锤子时，所有东西都看起来像钉子，请牢记坚持其原始用例，当重构引入新的抽象类时，现有接口的演变毫无意义。

继续进行一些遗失，仍在我们身边或尚未完全存在的事情：

4.为什么您是

Jigsaw项目的目标是使Java模块化并将JRE分解为可互操作的组件。 首先，其背后的动机来自对更好，更快，更强大的 Java嵌入式的渴望。 我试图避免提及“物联网”，但是我在那说了。 减小JAR大小，提高性能和提高安全性是这个雄心勃勃的项目所具有的更多希望。

那在哪呢 甲骨文首席Java架构师Mark Reinhold表示，拼图刚进入了第二阶段 ，已经通过了探索阶段，现在正在将其转换为生产质量设计和实现。 该项目最初计划在Java 8中完成，然后推迟到Java 9，有望成为其旗舰新功能之一。

诊断：如果这是您要等待的主要内容，则Java 9将于2016年推出。与此同时，仔细研究一下，甚至可能会涉及到Jigsaw-dev邮件列表。

5.仍然存在的问题

检查异常

没有人喜欢样板代码，这就是lambda如此受欢迎的原因之一。 考虑样板异常，无论逻辑上是否需要捕获或与检查异常相关 ，您仍然需要捕获它。 即使这是永远不会发生的事情，例如永远不会触发的异常：

try {
    httpConn.setRequestMethod("GET");
} catch (ProtocolException pe) { /* Why don’t you call me anymore? */ }

原语

它们仍然在这里，正确使用它们很痛苦 。 将Java与纯粹的面向对象的语言区别开来的一件事是，批评说Java的删除对其性能没有重大影响 。 只是说，所有新的JVM语言都没有它们。

操作员超载

Java的父亲James Gosling在一次采访中曾说过：“我忽略了运算符重载，这是一个非常个人的选择，因为我看到太多的人在C ++中滥用它”。 有点道理，但是对此有很多不同意见。 其他JVM语言确实提供了此功能，但另一方面，它可能会导致代码如下所示：

javascriptEntryPoints <<= (sourceDirectory in Compile)(base =>
    ((base / "assets" ** "*.js") --- (base / "assets" ** "_*")).get
)

来自Scala Play框架的实际代码行，嗯，我现在有点头晕。

诊断：这些是否是真正的问题？ 我们都有自己的怪癖，这些都是Java的怪癖。 在将来的版本中可能会发生意外的情况，并且会有所变化，但是向后兼容性以及其他方面的兼容性使它们始终与我们保持联系。

6.函数式编程–还不完全

尽管以前很尴尬，但以前使用Java可以进行函数式编程。 Java 8借助lambda对此进行了改进。 这是最受欢迎的，但没有以前描述的那么大。 绝对比Java 7更优雅，但仍需要向后弯曲才能真正发挥作用。

关于此问题的最激烈的评论之一来自Pierre-yves Saumont，他在一系列文章中仔细研究了函数式编程范例与在Java中实现它们之间的区别。

那么Java还是Scala？ Java中采用功能更强大的现代范例对Scala表示认可，因为Scala一直在使用lambda。 Lambda确实引起了很大的反响，但是还有很多特性，例如特征，懒惰的评估和不可变的特性等，它们会产生很大的影响。

诊断：不要被lambda分散注意力，在Java 8中函数式编程仍然很麻烦。

翻译自: https://www.javacodegeeks.com/2014/07/6-reasons-not-to-switch-to-java-8-just-yet.html