The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Java 9 几周前发布 。请查看发布说明，其中包含许多有趣的功能。然而，我认为不是所有的东西都像 Oracle 和 Java 专家们所描述的那样。我在 Java 世界中看到了三种趋势，它们分别是好的、坏的和丑陋的。让我们从好的那一面开始。
第一个趋势是编译Java、打包JAR文件和运行字节码的平台明显改进。随着每个新的Java版本发布，它肯定变得更好。以下是Java 9做出的改进列表，无疑非常有用：
“JEP 238: Multi-release JARs” translated to Chinese without technical terms and proper nouns would be: “JEP 238: 多版本JAR文件”
JEP 158: 统一记录日志
这个平台显然变得更加成熟。这是一个好的趋势。
第二个趋势是自从 Java 6 以来我观察到的，它显示出 JDK（Java开发工具包）会随着每个新版本的发布而变得更庞大。JDK本质上是由 Oracle 设计、开发和维护的一组类和接口。在 Java 9 中，除其他功能外，他们新增和扩展了以下内容：
当然，一些功能必须在JDK本身中实现，例如Unicode支持（JEP 267），特定于平台的桌面功能（JEP 272），自旋等待提示（JEP 285），紧凑字符串（JEP 254）以及进程API（JEP 102）。它们的实现取决于底层平台，并且必须与JVM一起提供。
但是，HTTP 2.0客户端和JAX-RS，JPA，JAX-WS，JDBC等其他东西一起出现在JDK中，我认为它们应该尽可能远离Oracle。它们并不特定于平台，可以由开源社区以更好的方式作为独立包进行设计。将它们聚合在一个庞大的品牌下是一个错误，我认为。
我认为大公司只会扼杀软件市场，而不是让它变得更好，因为它们面临的是财务和政治动机。这正是JDK正在发生的事情。由于Oracle的垄断地位，它在增长方面缺乏灵活性和动态性。换句话说，我们被迫接受Oracle及其大公司朋友们认为正确的东西。
因此，让JDK变得更庞大是一个不好的趋势。相反，我认为Oracle只会从让它更小，将不特定于平台的所有内容委托给开源社区，以某种方式支持程序员，并促进市场上的开放和有效的标准化过程中受益。
Java是由James Gosling在1995年在Sun Microsystems开发的面向对象语言。关于它是面向对象的说法存在许多争议，我也不确定Java是否比过程化更面向对象。然而，它在官方上被定义为面向对象。
Java从C/C++继承了许多过程化特性，包括静态方法、NULL、实现继承等。它不是一个完美的面向对象语言，也不打算成为一个完美的面向对象语言，我理解的是这样。关键的想法是创建出一种可以“编写一次，随处运行”的东西。然而，语言本身也很重要，而不仅仅是JVM。它简单而性感。
Java 5在2004年迈出了一大步，通过添加泛型、for-each循环、可变参数和静态导入来改进了语言。然而，也引入了注解和枚举，这帮助了语言从面向对象范式转向了完全不同的过程式范式。
Java 7在2011年添加了try-with-resource，这是一个很好的举措，与面向对象范式一致。
Java 8在2014年添加了lambda表达式，这是一个很棒的特性，但与面向对象无关。Lambda和Streams API将Java转变为一种混合了面向对象、过程式和函数式范式的语言。还在接口中添加了默认方法，将类型转化为代码库。类型成为了代码库！这甚至比实现继承更糟糕，如果你问我。
现在，Java 9对接口进行了下一个“改进”，允许它们拥有私有方法。类型中的私有静态方法！你能相信吗？下一步会是什么呢？我猜是Java 10中的属性。
此外，让我们看看JDK中一些核心类所做的改变，以了解这门语言的发展方向。这里只举两个例子。
集合的工厂方法（JEP 269）。而不是引入新的构造方法，让我们可以这样做：
…in Java 9 they created more static factory methods and made us do this:
List<Integer> list = List.of(1, 2, 3);
“少点构造函数，多点静态方法！”这似乎是那些引入这个JEP的人的哲学。毫无疑问，这完全违背了面向对象编程的精神。对象必须由构造函数创建，而不是静态方法，不管Joshua Bloch说了什么。静态方法使我们看不到new操作符的使用时刻，这就是为什么代码可维护性较差的原因——我们根本不知道实例化的是哪个类，其构造函数的真实参数是什么。
顺便说一句，通过Cactoos，你可以以正确的方式实现：
This is OOP.
InputStream中的新方法。在已经过度臃肿的类InputStream中新增了三个方法：transferTo()，readNBytes()和readAllBytes()。现在，当我们想要将输入流复制到输出流时，我们应该这样做：
这是年轻的OOP程序员经常犯的最典型的错误之一：他们使接口变得庞大，仅仅是因为需要更多的功能。我猜想“接口隔离原则”是著名的SOLID原则的一部分，而且已经存在多年了。Oracle你怎么了？下一步是什么呢？在Java 10中，我们还会有saveToFile()和printToConsole()吗？那emailToAFriend()呢？
以下是使用commons-io中的IOUtils实用类完成相同操作的方法：
它不是完美的，但是更好。最面向对象的方式是使用对象，而不是实用类和静态方法。这就是在Cactoos中的工作方式。
This is OOP.
在我看来，Java变得越来越丑陋，而且这是一个趋势。这意味着是时候退出了吗？不！无论你有多丑陋，我们始终会爱你，Java！
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-18 at 05:17
