sun.misc.Unsafe苦难告诉我们什么

最新推荐文章于 2023-06-27 18:51:43 发布

dnc8371

最新推荐文章于 2023-06-27 18:51:43 发布

阅读量143

点赞数

文章标签： java python 编程语言 spring vue ViewUI

Oracle将删除Java 9中的内部sun.misc.Unsafe类。尽管大多数人可能对这种变化漠不关心，但其他一些人（主要是图书馆开发人员）并非如此。博客圈中最近有几篇文章描绘了这种变化所暗含的含义：

维护公共API非常困难，尤其是当该API与JDK一样流行时。根本没有（几乎）没有办法阻止人们用脚射击自己。 Oracle（和以前的Sun）始终将sun.*软件包声明为内部软件包，不要使用它们。从名为“为什么开发人员不应编写调用'sun'软件包的程序”页面引用：

sun。*软件包不是受支持的公共接口的一部分。

不能保证直接调用sun。*软件包的Java程序可以在所有与Java兼容的平台上运行。实际上，即使在同一平台上的将来版本中，也无法保证此类程序可以正常工作。

此免责声明只是许多类似免责声明和警告中的一种。凡前进并采用Unsafe这样做......“ 不安全 “。

我们从中学到什么？

解决这一苦难的具体解决方案正在讨论中，并且仍在公开中。一个好主意是在删除Unsafe 之前提供正式的公共替换，以允许有问题的库的迁移路径。

但是，所有这些还有一个更重要的信息。消息是：

当您只有一把锤子时，每个问题都像拇指一样

转换为这种情况：锤子是Unsafe并且考虑到锤子非常糟糕，但是唯一的选择是，库开发人员可能只是没有太多选择。他们不是真正的罪魁祸首。实际上，他们在世界上最稳定，向后兼容的软件环境（= Java）中赌博，他们的表现非常出色，超过了10年。在类似情况下，您会做出其他选择吗？或者，让我提出不同的要求。当时押注AWT或Swing是更安全的选择吗？

如果某人可以以某种方式使用某些东西，那么无论他们将如何用脚射击自己，都会如此。当前编写库/ API并真正阻止用户访问内部组件的唯一方法是将所有内容放在单个程序包中，并将所有程序包设为私有。从一开始，这就是我们一直在jOOQ中所做的事情，因为我们知道jOOQ的内部结构非常微妙，并且随时可能变化。

有关此原理的更多详细信息，另请阅读：

但是，对于开发这些内部组件的人员来说，此解决方案具有严重的缺点。这是一个几乎没有结构的软件包的地狱。这使发展相当困难。

那么，哪种Java更好呢？

Java总是缺乏足够的可视性：

public
protected
default （包专用）
private

应该有第五种可见性，其行为类似于public但是阻止从模块“外部”进行访问。从某种意义上说，这介于现有的public和default公开性之间。我们称其为假设的module可见性。

实际上，我们不仅应该能够在类或成员上声明这种可见性，而且还应该能够在高层管理模块的相互依赖性，就像Ceylon语言允许我们做的那样：

module org.hibernate "3.0.0.beta" {
    import ceylon.collection "1.0.0";
    import java.base "7";
    shared import java.jdbc "7";
}

这与OSGi的捆绑软件系统非常相似，在OSGi的捆绑软件系统中，可以导入/导出捆绑软件，尽管上述模块语法比配置OSGi简单得多。

复杂的模块系统将走得更远。它不仅可以匹配OSGi的功能，还可以匹配Maven的功能。由于可以基于Java语言模块声明依赖关系，因此我们可能不再需要基于XML的Maven描述符，因为它们可以从简单的模块语法（或Gradle或ant / ivy）生成。

有了所有这些，就可以将诸如sun.misc.Unsafe类的类声明为module -仅对少数JDK module可见-而不是整个世界。我敢肯定，滥用反思来掌握这些内部因素的人数将减少50％。

结论

我确实希望在将来的Java中，可以将此Ceylon语言功能（以及Fantom语言功能btw ）合并到Java语言中。可以在此博客文章中看到有关Java 9 / Jigsaw的模块化封装的完整概述： http : //blog.codefx.org/java/dev/features-project-jigsaw-java-9/#Encapsulation

在那之前，如果您是API设计人员，请务必知道所有免责声明均无效。您的客户将使用和滥用您的内部API。从您发布它们开始的第一天起，它们就成为您普通公共API的一部分。这不是您用户的错。事情就是这样的。