【CSDN 编者按】提到 Java，批评声从未中断，无论是“已死”还是“即将衰亡”，总有开发者唱衰 Java。然而与批评不同的是，本文作者是Java的忠实粉丝，他对控诉Java劣迹的特性进行一一反驳。
原文链接：https://debugagent.com/the-reason-java-is-still-popular
声明：本文由 CSDN 翻译，未经允许禁止转载。
作者 | Shai Almog
译者 | 弯月
出品 | CSDN（ID：CSDNnews）
最近，Java 19正式发布。Java仍然是我挚爱的编程语言，但前一段时间有人在帖子中控诉Java的种种“劣迹”（原文链接：https://medium.com/codex/i-finally-gave-up-on-java-5187947bef1b）。
在此，我想对其进行逐一反驳。
Getters and setters
首先，那篇帖子中抱怨了 getter 和 setter。但实际上，在现代 Java 中，getter 和 setter 不是必需的。我们从 Java 14 开始就有记录，在我看来Lombok很好。我们唯一需要 getter/setter 的地方是在一些特定的设置（例如 JPA）中，而且 Lombok 也完美地解决了这个问题。那篇帖子反复诉说 Java 缺乏语法糖特性。但实际上这是有意为之。如果你对最新的语法细节感兴趣，则可以看一看 Kotlin。Java 的发展“缓慢而稳定”，这是一件好事，也是 Java 长寿的主要原因。
语法糖和运算符重载
现代 Java 包括 switch、var、多行字符串等模式，还有一些即将推出的功能，包括字符串模板。字符串模板的支持还需要一段时间，因为 Java 想要“正确地实现”。API 级别有一些此类的支持（而且已经有一段时间了），但性能不是很好。字符串模板的目标是创建一种语法以支持以下写法：
ResultSet rs = DB."SELECT * FROM Person p WHERE p.last_name = {name}";注意，这里的 name 是一个变量，编译器需要动态地检查并从作用域中获取！
DB 可以由开发人员自定义实现，不需要“内置”，因此你可以构建复杂的模板。
话虽如此，我们还是先把 Java 未来的规划放在一边，只看看现在的Java。
近十年来，我们一直不推荐使用 String 的 append，因为使用+的性能更高，而且更易于阅读。
实际上，运算符不能重载是一个巨大的好处。如果看到 a + b，那么我就知道这是一个字符串或一个数字，而不是一些不为人知的方法。这是 Java 最大的优势之一，也是它流行了近 30 年而其他语言却被抛弃的原因之一。Java的语法设计考虑到了大规模的代码阅读。当项目的代码规模高达百万行，甚至是十万行时，你将会面临完全不同的问题。此时，如果你发现模块X中的程序Y错误地重载了某个运算符，那么调试就会非常困难。语法应该尽量简单，最初节省的任何小成本将来都要 10 倍偿还。随着代码越来越复杂，时间越来越久，简单的定义也会发生变化。再加上工具的强大功能可以大规模解析严格的简单代码，由此带来的好处也数不胜数。
检查型异常
检查型异常不是必须的，但这是 Java 最优秀的特性之一。代码发生异常的事情太常见了。作为个人娱乐项目，出现异常也没问题，但如果要构建专业的应用程序，那么就必须处理每个错误。检查型异常可以避免发生意外情况。人们讨厌检查型异常，只是因为他们懒。而 Java 不让你偷懒。对于建立网络连接、数据库连接、打开文件等操作，不处理异常是不可能的。就算我想偷懒，检查型异常也会强迫我在某个地方处理异常。这个特性非常好。
依赖
我对于 Maven 和 Gradle 的意见颇多。但跟其他依赖系统相比，它们还算不错。虽然二者的确存在一些问题，但拿它们跟 cargo 这种年轻的包管理器做比较是不公平的，再说后者几乎没有任何可用的包。Maven 中心库拥有 27TB 的jar 包，每个月有 4960 亿次请求。它依然能正常工作，而且基本上没有宕机时间。其他工具，比如 NPM，也衬托了 maven 的强大之处。如果说 maven 中的依赖是一个问题，那么 NPM 的问题岂不是有 100 倍，而且还无人管理。这些问题会变得越来越复杂，特别是当市场上存在多个版本的 maven 时。但是，maven 和 gradle 这样做的原因之一是工具。许多情况下，IDE 都能解决并自动修复这些问题。
Java 的文化问题
这篇文章（https://alexn.org/blog/2022/09/19/java-cultural-problem/）中提到了关于 Java 的一些文化问题，我同意。Java 开发者倾向于把每个问题都变成更复杂的问题。有时候，这是必要的，毕竟 Java 是个超级庞大的怪物，它的解决方案通常都有过度设计的问题。这肯定要比设计不足要好，但的确要付出一定的代价。
为什么使用注释进行验证
我想起了下面这个例子，看似“正确”，但其实有问题：@Not @Email
String noReplyEmailAddress
作者认为这样不对，应该写成下面这样：
public record EmailAddress(String value) {
public EmailAddress {
// We could've used an Either data type, ofc;
Objects.requireNon(value);
// regexp could be better
if (!value.matches("^[^@\s]+@\S+#34;))
throw new IllegalArgumentException(
String.format("'%s' is not a valid email address", value));
}
}这段代码当然可以这么写，但有几个问题，因此我们需要使用 Bean 验证：
这种写法无法被优化。而Bean验证可以被框架移动到更高的层次，甚至可以由客户端代码进行验证，因为它是声明式的API。这里我们不需要执行构造函数来进行验证；声明式的注释可以向下层移动，无缝地应用到数据库约束上；可以同时应用多个注释；语法更简洁。因此，尽管这里的注释看起来有点奇怪，而且不会强制检查类型，但能极大地提升性能，而且很强大。这种用法背后有很多考量。
总结
本文花了很多篇幅来反驳其他文章，下面我想提出一些自己的看法。Java 已有近 30 年的历史了，很多功能仍然能与 Java 1.0 兼容，这一点就非常了不起！Java 采取保守路线的好处之一就在于，可以“私下里”进行优化，而使用者甚至注意不到。Java 9 完全改变了字符串在内存中的表示方式，从而极大地降低了内存使用，但这个改动对外部没有任何影响。与之类似，Loom 提高了 Java 同步应用的吞吐量，Valhalla 进一步改善了集合的性能，统一了对象和基本类型的触发。Panama 让我们摆脱了 JNI，降低了与原生代码打交道的难度。
如果你不喜欢Java，也许可以试试 Kotlin 或 Scala。JVM 无所不包，其带来的优势普遍适用，而且上面我提到的那些好处能让整个生态系统受益。