Java 8 Friday：让我们弃用那些旧版库

在Data Geekery ，我们喜欢Java。而且，由于我们真的很喜欢jOOQ的流畅的API和查询DSL ，我们对Java 8将为我们的生态系统带来什么感到非常兴奋。

Java 8星期五

每个星期五，我们都会向您展示一些不错的教程风格的Java 8新功能，这些功能利用了lambda表达式，扩展方法和其他好东西。您可以在GitHub上找到源代码。

在过去的两个星期五，我们一直在复活节休息，但现在我们又回来了另一篇有趣的文章：

让我们弃用那些旧版库

d8938bef47ea2f62ed0543dd9e35a483 除了Lambda和扩展方法外，JDK还通过许多新的库代码得到了增强，例如Streams API等。这意味着我们可以批判性地检查堆栈，并且–令Deprecator医生感到高兴–丢弃了我们不再需要的所有垃圾。

这里有几个，仅举几例：

LINQ风格的库

有很多库试图模拟LINQ（即LINQ-to-Collections部分）。 Oracle认证Streams Developer认证无处不在。

不要误会我的意思。这与LINQ或Streams更好无关。它们几乎相同。但是，既然我们现在在JDK中具有Streams，为什么还要担心LINQ？此外，用于集合查询的SQLesque语法还是有误导作用。兰伯达

这是通过奥秘和讨厌的技巧（例如ThreadLocal在Java中模拟闭包的有趣尝试。考虑以下代码片段（从此处获取）：

// This lets you "close over" the
// System.out.println method
Closure println = closure(); { of(System.out).println(var(String.class));
}// in order to use it like so:
println.apply("one");
println.each("one", "two", "three");

好主意，尽管closure（）之后的分号；在那个不是真正的闭包主体的伪闭包实现块之前……所有这些似乎都很古怪！

现在，我们将编写：

Consumer<String> println = System.out::println;println.accept("one");
Stream.of("one", "two", "three").forEach(println);

这里没有魔术，只有简单的Java 8。

让我们最后一次听到Mario Fusco和Lambdaj的故事。

Linq4j

显然，这仍在积极开发中……为什么？请注意，该路线图中还具有LINQ-to-SQL实现，包括：

解析器支持。修改Java解析器（例如OpenJDK），或编写预处理器。生成包含表达式树的Java代码。

是的，我们也想为jOOQ提供这样的解析器。这将使我们能够将SQL真正嵌入到Java中，类似于SQLJ ，但是类型安全。但是，如果我们拥有Streams API，为什么不立即实现类似Julian Hyde的Linq4j之类的东西，因为他仍在继续工作。但是我们认为他在错误的角落投资。

集合体

这是一个有趣的名称库，它可以执行以下操作：

from(animals).where("name", eq("Lion")).and("age", eq(2)).all();from(animals).where("name", eq("Dog")).or("age", eq(5)).all();

但是，为什么这样写，当您可以写时：

animals.stream().filter(a -> a.name.equals("Lion")&& a.age == 2).collect(toList());animals.stream().filter(a -> a.name.equals("Dog")|| a.age == 5).collect(toList());

让我们为Wagner Andrade听听。然后到垃圾箱

一半的番石榴

番石榴几乎是所有应该放在JDK中的各种逻辑的转储。以com.google.guava.base.Joiner为例。它用于字符串连接：

Joiner joiner = Joiner.on("; ").skipNulls();
. . .
return joiner.join("Harry", null, "Ron", "Hermione");

不用了我们现在可以写：

Stream.of("Harry", null, "Ron", "Hermione").filter(s -> s != null).collect(joining("; "));

还要注意，因为Streams API和lambda表达式使您可以很好地将skipNulls任务与过滤任务分离，所以不再需要skipNulls标志和所有其他其他skipNulls实用程序。

说服了吗没有？

关于什么：

com.google.common.base.Optional > java.util.Optional
com.google.common.base.Predicate > java.util.function.Predicate
com.google.common.base.Supplier > java.util.function.Supplier

然后，还可以将整套的Functional东西扔到垃圾箱中：

https://code.google.com/p/guava-libraries/wiki/FunctionalExplained

当然，一旦确定要在整个应用程序中使用Guava，就不会很快删除其用法。但另一方面，我们希望不久将弃用Guava的某些部分，而希望与Java 8集成。

乔达时间

现在，这很容易，因为流行的JodaTime库已标准化为java.time包。这是个好消息。

让我们听听“ Joda” Stephen Colebourne以及他为JSR-310所做的出色工作。

Apache Commons-io

java.nio软件包通过与Streams API很好地集成（或不集成）的新方法变得更好。任何人都会使用Apache Commons IO的主要原因之一是，在Java 7/8之前读取文件非常繁琐，我的意思是，谁会喜欢这段代码（从这里开始）：

try (RandomAccessFile file = new RandomAccessFile(filePath, "r")) {byte[] bytes = new byte[size];file.read(bytes);return new String(bytes); // encoding?? ouch!
}

超过这个？

List<String> lines = FileUtils.readLines(file);

但是忘记后者。现在，您可以在java.nio.file.Files使用新方法，例如

List<String> lines = Files.readAllLines(path);

不再需要第三方库！

序列化

全部淘汰，因为JEP 154弃用了序列化。嗯，它没有被接受，但是我们可以确定删除了大约10％的旧代码库。

多种并发API和助手

借助JEP 155 ，对并发API进行了多种改进，例如ConcurrentHashMaps（我们之前已经在此进行过博客讨论），以及令人敬畏的LongAdders，您可以在Takipi博客上阅读有关该文章的精彩文章。

最近，我是否没有在Guava上看到整个com.google.common.util.concurrent包？可能不再需要了。

当然，这是愚人节的玩笑……

Base64编码器

这怎么可能要花这么长时间？在2003年，我们有了RFC 3548 ，指定了Base16，Base32和Base64数据编码，实际上是基于1993年的RFC 1521或1996年的RFC 2045中指定的base 64编码，如果我们愿意的话深入研究过去，我相信我们会找到更早的引用，这种引用将文本数据编码为文本形式的简单想法。

现在，在2014年，我们终于将JEP 135作为JavaSE8的一部分，因此（您不会相信）： java.util.Base64 。

所有这些库都丢到垃圾桶了！