java7和java8切换
Java 8很棒。 期。 但是……在我们有机会玩耍并玩弄它之后,就该退出了,避免吃盐。 所有的好东西都是有代价的,在这篇文章中,我将分享Java 8的主要痛点。请确保在升级和释放7之前您已经意识到了这些痛点。
1.并行流实际上会使您减速
Java 8将并行性作为最令人期待的新功能之一带来了希望。 .parallelStream()方法在集合和流上实现此目的。 它将它们分解为子问题,然后在单独的线程上运行以进行处理,它们可以进入不同的核心,然后在完成后组合在一起。 这一切都是在使用fork / join框架进行的 。 听起来不错,它必须加快多核环境中大型数据集的操作,对吗?
不,如果使用不正确,它实际上会使代码运行速度变慢。 慢上大约15% 这个基准,我们跑了,但它可能会更糟糕。 假设我们已经在运行多个线程,并且在其中一些线程中使用了.parallelStream(),从而向池中添加了越来越多的线程。 这很容易变成我们的核心无法处理的事情,并且由于上下文切换的增加而减慢了一切。
基准测试速度较慢,将集合分为不同的组(素数/非素数):
Map> 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大小,提高性能和提高安全性是这个雄心勃勃的项目所具有的更多希望。
那在哪呢 Oracle首席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中采用功能更强大的现代范例对于已经使用lambda的Scala表示认可。 Lambda确实引起了很大的反响,但是还有很多特性,例如特征,懒惰的评估和不可变的特性等,它们会带来很大的不同。
诊断:不要被lambda分散注意力,在Java 8中函数式编程仍然很麻烦。
翻译自: https://www.javacodegeeks.com/2014/07/6-reasons-not-to-switch-to-java-8-just-yet.html
java7和java8切换