Lukas Eder 写了一篇 文章 ，讲述了拟议中的 sun.misc.Unsafe 下降带来的痛苦。如果您还没有听说 Oracle 将删除 Java 9 中的内部 sun.misc.Unsafe 类，那么请阅读 Lukas 的文章并按照他提供的一些链接自行决定。
sun.misc.Unsafe 是大多数 Java 实现中可用的类，提供一些其他方式不可用的“不安全”功能。这些功能不是规范的一部分，不保证可用。它们只是碰巧在那里，并且可以通过一些讨厌的反射 hack 获得。换句话说：你不应该使用它，但你可以。有一些 Java 工具可以帮助保护您免于使用该接口，但不会过度使用。
其他语言，如 Perl，甚至没有那种级别的保护。在那种语言中，没有“私有”、“受保护”或其他访问修饰符。在模块中创建的任何东西都在那里。您可以在方法前使用下划线来表示它是私有的，但这更像是礼貌的“请”而不是严厉的“你不应该”。那里的哲学说你不会来我的卧室，不是因为我拿着机枪站在那里，而是因为去那里不好。
sun.misc.Unsafe misery 告诉我们的是它不起作用。很抱歉，但您 似乎 需要手里拿着一把枪，以防止图书馆用户入侵您的卧室。这也是 Lukas 的建议：将所有库内部代码放入一个包中，并将所有包设为私有。
但也有其他方法。如果您查看 Jira 和 Confluence 以及您可以编写的扩展，您会发现一种不同的方法。通过自然评估，Jira 从小规模开始，设计师可能从未梦想过如此庞大的开发人员社区为他们的软件编写通用扩展。他们根本就没有定义 API。有 jar 文件，其中的类和扩展可以或多或少地自由调用任何类的任何方法。结果：每个扩展都必须针对软件的每个版本进行测试，当你有一个扩展与 Jira 的一个版本一起工作时，它可能无法与下一个（次要升级的）版本一起工作。 Atlassian 花了很长的时间来定义一个稳定且“正式”可用于扩展模块的 API。他们是否将其他所有东西都放在一个包裹中？我不这么认为。相反，他们倾听客户的意见，他们有开发者论坛，他们确实授权员工倾听这些渠道并了解需求，他们的 API 提供用户所需的功能。
这是更具吸引力的方法。如果您提供图书馆用户需要的功能，他们就不会费心去卧室了。
如果您不提供这些功能，他们就会进来。您无法阻止他们这样做，就像您无法阻止青少年发生性行为一样。如果您确实提供了他们需要的东西，他们将不会使用非 API 类的禁止调用。
这实际上是 Sun 和后来的 ORACLE 未能正确完成的（恕我直言）。他们没有提供这些功能，“不安全”就在那里。他们多次警告我们不要使用那个，但他们没有告诉我们应该使用什么。现在一切都在接缝处分崩离析。会有什么后果？
我认为最有可能的情况如下：
- Java 9 将在没有 unsafe 的情况下问世。
- 由于许多库使用“不安全”包实现，因此行业对 Java 9 的接受将会延迟。企业标准 Java 版本长时间保持为 8（或某些企业为 7 或 6）。
- Java 可能会出现市场损失的迹象，这将促使 Oracle 给出一些解决方案。
- 将有一些由 Oracle 开发的 API 提供当前不安全特性集的有限特性集（最常用的特性）。
- 库将在几个月内使用新 API 进行修改。
- 企业将跳至支持新 API 的版本。
我不希望改变的是甲骨文对客户的态度。
我们将在……两到三年内看到它的准确度如何？
