Java 中所有不好的东西都对你有好处

向右看齐 2023-10-12 18:51 4阅读 0赞

我喜欢打破传统叙述的前提，并且在讨论 Java 中一些更具争议的特性和问题时不断地提醒我这一点。这是一个功能，而不是错误…

关于 Java，我最喜欢的事情之一是它倾向于缓慢而谨慎地移动。它不会立即给我们想要的东西。Java 团队了解需求并查看其他实现，然后从中学习。

我会说 Java 的驱动哲学是早起的鸟儿被蛇吞噬。  
检查异常  
Java 中最普遍讨厌的特性之一是检查异常。据我所知，它们是 Java 引入的唯一创新功能。Java 中的大多数其他概念在其他语言中也存在，检查异常是一个被其他语言拒绝的全新概念。它们不是一个“有趣”的功能，我明白为什么人们不喜欢它们。但它们是一个了不起的工具。

检查异常的最大问题是它们不能很好地适应函数语法。对于可空性也是如此（我将在稍后讨论）。这是一个公平的投诉。函数式编程支持被附加到 Java 上，并且在异常处理方面做得很差。Java 编译器可能已经检测到已检查的异常并需要错误回调。这是在 Java 8 中引入这些功能时犯下的错误。例如，如果将这些 API 更好地引入 Java，我们可以编写如下代码：

api.call1()
        .call2(() -> codeThatThrowsACheckedException())
        .errorHandler(ex -> handleError(ex))
        .finalCall();

errorHandler如果缺少回调，编译器可能会强制我们编写回调，这将完美满足已检查异常的精神。这是可能的，因为检查异常是编译器的一个特性，而不是 JVM。编译器可以检测到 lambda 中的已检查异常，并需要一个特别注释的异常处理回调。

为什么没有添加这样的东西？

这可能是因为人们普遍不喜欢检查异常。没有人试图提出替代方案。没有人喜欢它们，因为没有人喜欢强迫您自己整理的恼人功能。我们只想编码，检查异常迫使我们负责，即使我们只想编写一个简单的 hello world …

这在很大程度上是一个错误……我们可以声明 main 抛出异常并创建一个简单的 hello world 而不处理已检查的异常。在像 Spring 这样的大型应用程序框架中，checkedSQLException被包裹在RuntimeException同一个类的版本中。你可能认为我反对，但我不是。这是一个完美的例子，说明我们如何使用检查异常进行事后清理。清理由 Spring 内部执行，此时异常处理逻辑不再重要，可以转换为运行时异常。

我认为对 API 的很多仇恨来自于此异常的错误版本，例如MalformedURLException或编码异常。这些异常通常会因应该永远不会失败的常量输入而抛出。那只是多余的，并且是对语言功能的错误使用。仅当我们可以进行清理时才应抛出已检查的异常。这是一个 API 问题，而不是语言功能的问题。

无效的  
在过去 15 年多的时间里，对 null 的仇恨一直是一种趋势。是的，我知道那句话。我认为人们滥用它。

Null 是当今生活中的一个事实，无论您喜不喜欢。它存在于一切事物中：数据库、协议、格式等。Null 是编程的深层部分，在可预见的未来不会消失。

关于 null 的争论毫无意义。重要的争论是治疗是否比疾病更好，我还不相信。重要的不是 null 是否是一个错误，重要的是我们现在做什么。

公平地说，这与您对函数式编程范例的热爱直接相关。Null 在 FP 中表现不佳，这就是为什么它成为 FP 人员的出气筒。但我们是后退还是前进？

让我们将其分解为三个独立的辩论：

表现

失败

易于编程

表现  
空值很快。超级快。字面意思是免费的。CPU 为我们执行空检查并将异常处理为中断。我们不需要编写代码来处理 null。备选方案的开销可能非常低，有时可以转换为 null 以获得 CPU 性能优势。但这更难调整。

抽象泄漏和空值是我们硬件的工作方式。对于大多数意图和目的，它更好。

有一个警告。我们需要能够将某些对象标记为非空，以实现更好的内存布局（正如 Valhalla 计划做的那样）。这将允许更好的内存布局，并有助于加快代码速度。请注意，我们可以在保持对象语义的同时完成此操作，一个标记就足够了。

我认为 null 需要这一轮。

失败  
人们讨厌 NullPointerException。这让我很困惑。

NullPointerException 是最好的错误之一。这就是快速失败原则。错误通常很容易理解，即使不是这样；它并不遥远。这是一个很容易修复的错误。替代方案可能包括初始化一个我们需要验证的空对象或设置一个虚拟对象来表示 null。

打开一个存在时间足够长的数据库并搜索“undefined”。我敢打赌它有很多条目……这就是非空值的问题。您可能不会立即失败。你会得到更糟糕的东西。在系统中爬行并污染您的数据的隐形错误。

由于 null 非常简单且易于检测，因此有大量工具可以在运行时和开发期间处理它。当人们提到在生产中遇到空指针异常时，我通常会问：有什么替代方案？

如果您可以初始化该值，那您为什么不这样做呢？

Java 有 final 关键字，您可以使用它来保持非空状态值。可变值是未初始化或空值的主要原因。非空语言很可能不会失败。但它的结果会更糟吗？

根据我的经验，存储中损坏的数据要糟糕得多。这个问题是阴险的，隐藏在表面之下。问题的根源没有线索，我们需要设置“陷阱”来追踪它。任何一天给我一个失败禁食。

在我看来，null 有这个手……

易于编程  
需要理解的重要一点是 null 是现代计算的要求。我们的整个生态系统都建立在 null 之上。像 Kotlin 这样的语言完美地证明了这一点，它们有空对象和非空对象。

这意味着我们有重复。每个与对象相关的概念都被表达了两次，我们需要维护 null 和 non-null 之间的语义。这提高了新接触此类语言的开发人员的复杂性，并产生了一些奇怪的语法。

如果复杂性得到回报，这本身就很好。不幸的是，这样的功能只能解决 null 的最琐碎的非问题情况。不支持复杂对象，因为它们包含从外部源检索到的空值。我们为了有限的利益而增加了语言的复杂性。

样板  
这在过去曾经是一个更大的问题，但看看典型的 Java 文件与 TypeScript 或 JavaScript 的区别并没有那么大。仍然，人们挑剔。我在网上认识的一位聪明的工程师称语言中分号的使用为：“懒惰”。

我不明白。我喜欢分号要求，并且总是被对此有疑问的人感到困惑。作为作者，它允许我在忽略行长度的同时格式化我的代码。我可以在任何地方换行，分号是重要的部分。如果有的话，我很想取消在没有花括号的情况下编写条件语句的能力，例如：

if(..) x();
    else y();

这太可怕了。我在我的风格要求中阻止了这些；它们是开始或结束不明的灾难的根源。

Java部队组织起来，这是一件了不起的事情。类必须在特定文件中，包映射到目录。当您的项目很小时，这可能并不重要，但是当您处理庞大的代码库时，这就成了天赐之物。您会立即知道在哪里寻找线索。这是一个强大的工具。然而，它会导致一些冗长和一些深层目录结构。但是 Java 是由构建 1M LoC 项目的人设计的，由于样板，它可以很好地扩展。对于其他一些语言，我们不能这么说。

快速移动  
很多事情在 Java 中并不出色，尤其是在构建更具冒险精神的创业项目时。这就是我对 Manifold 如此兴奋的原因。我认为这是一种用我们想要的所有“酷东西”修补 Java 同时保持我们喜欢的性能、兼容性和稳定性的方法。

这可以让社区更快地前进和试验，而作为平台的 Java 可以走缓慢而稳定的路线。

最后一句话  
传统智慧是有问题的。特别是当它如此片面并提出一个单一维度的论点时，其中特定的语言特征较差。需要做出权衡，我的偏见可能会通过我的话体现出来。

然而，千篇一律的对位法并没有削减它。事实并没有呈现出对他们有利的清晰画面。权衡总是存在的，而 Java 走的是一条独特的钢丝。即使在错误的方向上轻微移动也会产生快速的翻滚效果。然而，尽管多个不同的团体努力将其展示为过时的，但它仍然保持着吸引力。这导致 Python 和 JavaScript 的开发人员将其视为“较新”的语言，这是一种荒谬的看法。

我认为解决方案有两个方面。我们需要宣传 Java 方法对这些解决方案的好处。我们还需要像 Manifold 这样的解决方案来自由探索潜在的方向。没有 JCP 的阻碍。拥有有效的概念证明将使将新想法集成到 Java 中变得更加容易。  
关注我的博客，您将在其中获得提示、技巧和挑战，以保持您的技能敏锐。记得关注我哦！