Java 仍然受欢迎的原因

现在是发布此内容的好时机，就在 Java 19 发布时。是的，另一个“我的语言更好”的帖子。不，我不想写它。但有时人们的糟糕投射会占上风。在这种情况下，该帖子以评论的形式开始，我最终决定将其转换为帖子。这篇文章加强了这一点，它主要是抱怨 Quarkus（如果我可以补充的话，有点不公平）。

第一篇文章大多是胡说八道和过时的点击诱饵。我将将其总结为以下声明：

吸气器/塞特
缺少专门针对集合和任何内容的操作员重载[]+
已检查的异常
依赖项管理
第二篇文章的抱怨更多地与 Jakarta EE 和 JVM 中的通用程序员美学有关。具体来说，就是使用注释进行验证和类似声明。这是一篇消息更丰富的文章，但有几个缺陷，我将在最后解决。

Getter 和 Setter
getter 和 setter 对于现代 Java 来说不是必需的。我们从 Java 14 开始就已经录制了，尽管有一些相反的说法，但龙目岛仍然很好。我们需要 getter/setter 的唯一一点是在非常特定的设置中（例如 JPA），Lombok 再次完美地解决了这个问题。

这篇文章对 Java 中缺乏语法糖特性进行了长篇大论。这是故意的。如果您对最新的语法细微差别感兴趣，可以查看 Kotlin。Java 是关于“缓慢而稳定”的。这是一件好事，也是 Java 长寿的主要原因。
语法 Sugar 和 Operator 重载
现代 Java 包括 switch、var、多行字符串等中的模式。一些即将推出的功能包括字符串模板。字符串模板支持需要一段时间，因为 Java 想要“做对”。在 API 级别对此有一些支持（并且已经有一段时间了）。这不是性能。字符串模板的目标是创建一个激进的可重写语法，该语法允许如下内容：

ResultSet rs = DB."SELECT * FROM Person p WHERE p.last_name = \{name}";

更新：自这篇文章发布以来，开发人员错误地认为上述代码是SQL注入漏洞。事实并非如此。这看起来像字符串替换，但它是使用该语法生成参数化 SQL 调用的代码。

请注意，这是一个变量，编译器将动态检查并从范围中获取！name

DB可以由开发人员自定义实现，不需要“内置”，因此您可以就地构建复杂的模板。

但是，让我们谈谈我们今天拥有的Java，而不是6个月后出现的Java。十多年来，一直不建议使用 append。使用性能最高且更易于阅读的。关于集合，and 之间的区别实际上是四个字符。这些角色很重要。我们可以很容易地覆盖它。我们也可以理解语义上的差异。Java 数组非常快，在许多情况下本机速度很快。收藏不可能那么快，我们可以在这里立即看到这一点，这一事实非常有价值。String+get()[]

操作员不能超载这一事实是一个巨大的好处。如果我看到，我知道这是一个字符串或一个数字，而不是某种隐藏的方法。这是 Java 最大的优势之一，也是它流行了近 30 年而其他语言被抛在一边的原因之一。Java 的语法是为大规模阅读而设计的。当你的项目有 1M 行代码甚至 100k 时，问题就会发生变化。在这一点上，发现模块 Y 中的程序员 X 在调试问题时错误地覆盖了运算符是很困难的。在这一点上，语法应该很简单，您最初节省的任何小额成本都将以 10 倍的利息支付。简单翻转即代码的定义变得更加复杂和陈旧。除此之外，工具还可以大规模解析严格的简单代码，这成为一个更大的好处。a + b
已检查的异常
已检查的异常是可选的。但它们是 Java 中最好的特性之一。如此多的代码意外失败。当你把构建东西作为一种爱好时，它可能没问题。当您想要构建专业应用程序时，您需要处理每一个错误。已检查的异常可帮助您避免这种无稽之谈。由于懒惰，人们讨厌检查过的异常。Java 可以保护您免受自己的伤害。

我应该不会建立网络连接、数据库连接、打开文件等，也不需要处理潜在的错误。我可以下注它，但随后检查的异常迫使我继续在某个地方下注它。这是一个了不起的功能。

依赖
我在使用 Maven 和 Gradle 时遇到很多问题。但是，当你将它与几乎所有其他具有一定基础的依赖系统进行比较时，它们做得很好。他们有问题，但你不能把它们与像货物这样几乎没有包裹的年轻东西相提并论。Maven central 非常庞大，拥有 27 TB 的 jar 和 4960 亿个请求。它完美地滴答作响，几乎没有停机时间。

NPM 等其他工具完美地展示了 maven 的优势。如果 maven 中的依赖项是一个问题，那么 NPM 就会有 100 倍的问题，并且没有监督。随着这些事情的发展，就会变得复杂起来。尤其是市场上有多个版本的 maven。但是，maven 和 Gradle 为他们准备的一件事是工具。在许多情况下，IDE 有助于解决问题并找到开箱即用的修复方法。

爪哇的文化问题
第二篇文章更有趣，在某种程度上，我同意。Java 开发人员倾向于将每个问题都变成更复杂的问题。在某些情况下，这是必要的，Java 是 800 磅重的编程平台大猩猩，其解决方案经常被过度设计。这往往比动力不足要好，但它确实需要付出代价。
为什么要使用注释进行验证
这篇文章确实提出了一个有趣的例子，对于不经意的观察者来说，这似乎是“正确的事情”，但存在问题。

@NotNull @Email
String noReplyEmailAddress

作者声称这很糟糕，应该实现自定义类型，例如：

public record EmailAddress(String value) {
  public EmailAddress {
    // We could've used an Either data type, ofc;
    Objects.requireNonNull(value);
    // regexp could be better
    if (!value.matches("^[^@\\s]+@\\S+$")) 
      throw new IllegalArgumentException(
        String.format("'%s' is not a valid email address", value));
  }
}

这在 Java 中是完全可能的，因为上面的代码是有效的 Java 代码。但它有几个问题，这就是我们进行 bean 验证的原因。

这无法优化 - 框架可以将 Bean 验证移动到验证链的上游。它甚至可以在客户端代码中无缝验证，因为它是一个声明式 API。在这里，我们需要实际执行构造函数来执行验证。
声明性注释可以沿着链向下移动，以无缝应用数据库约束等。
我们可以一次应用多个注释
语法更简洁
因此，批注可能会感觉很奇怪，并且不会强制键入。这是真的。但它们提高了性能和功率。它们的使用背后有很多想法和常识。我明白作者的观点，我也不是 IoC 的忠实粉丝，但在这种特定情况下，他是不正确的。

最后
这篇文章在防守上花费了太多时间。是时候换档了。Java 已经存在了近 30 年，并且仍然主要与 Java 1.0 兼容。这太棒了，无与伦比！

其保守方法的力量之一是它可以在你们中的任何一个人都不会注意到发生了什么的情况下进行惊人的“幕后”优化。Java 9 完全取代了字符串在内存中无缝表示的方式，并显著减少了 RAM 的使用。同样，Loom 将提高 Java 同步应用程序的吞吐量。Valhalla 将进一步提高集合性能并统一对象/基元的鸿沟。巴拿马最终将摆脱我们的 JNI，并使与本地代码集成的过程更加愉快。

好消息是 JVM 是一个大帐篷。如果您不是 Java 的粉丝，Kotlin 或 Scala 可能适合您的口味。JVM的好处是普遍适用的，我在这里提到的大多数特性将使我们的整个联合生态系统受益。