unsafe java_放弃Java的Unsafe达到“务实的妥协”

unsafe java

关于删除Java 9中的Unsafe类的持续辩论最终达到了某种友好的结果，Oracle的Mark Reinhold建议将大多数JDK的内部API封装在定义和使用它们的模块中。

Reinhold的消息是通过OpenJDK邮件列表广播的，他建议封装大多数JDK的内部API（包括sun.misc.Unsafe ）会默认使它们无法被JDK外部的代码访问。

这种更改将改善平台的完整性，因为许多内部API定义了特权，对安全敏感的操作。 从长远来看，它也将减少JDK本身的维护者以及使用这些非标准，不稳定且不受支持的内部API的库和应用程序的维护者所承担的成本，这些库和应用程序的有意（或无意）都将使用它们。

承认许多流行的库都使用sun.misc.Unsafe来调用实际上在JDK之外无法执行的方法，因此Reinhold的主张得到了同意，这使Oracle不仅承认这一问题，而且还听取了社区的意见关于解决方案。

像Christoph Engelbert，Martijn Verburg和Richard Warburton这样的Java杰出人物都表示了对该计划的认可，而Warburton 很高兴听到这种“务实的妥协”正在被采纳。

还请参见： Hazelcast关于不安全的问题–“最大的问题是，它已经存在了很长时间”

Reinhold的主张还强调了用户在将来采用Java 9时应如何对待诸如Unsafe之类的关键API：

• 如果它在JDK 8中具有受支持的替代品，那么我们将其封装在JDK 9中；
• 如果它在JDK 8中没有受支持的替代品，那么我们将不将其封装在JDK 9中，以使外部代码仍然可以访问它。
• 如果它在JDK 9中具有受支持的替代品，那么我们将在JDK 9中弃用它，并将其封装在JDK 10中，甚至可能将其删除。

Warburton高兴地看到，当前正在使用不受支持的内部API的现有项目不会受到影响。 在JEP 260中提供了JDK 9仍可访问的建议的关键内部API的列表。 应该注意的是，清单本身不会提议任何内部API的替代品； 该工作将由单独的JEP和适当的JSR负责。

为了向清单中的内容提出建议，Reinhold要求它们在现实世界中得到用例的支持，并“对开发人员和最终用户的影响进行估算”。 Engelbert目前正在将自己的用例列表与差距分析放在一起，该差距分析主要围绕sun.misc.Unsafe进行。

他还建议，sun.reflect.ReflectionFactory，由Objenesis使用，可能是另一个类添加到关键的内部API议程。

翻译自: https://jaxenter.com/ditching-of-javas-unsafe-reaches-pragmatic-compromise-119377.html

unsafe java