我刚刚尝试了JDK9
,发现sun.misc.Unsafe
现在不包含原生方法,而是将它们委托给了一些jdk.internal.misc.Unsafe
,例如:
@ForceInline
public int getInt(Object o, long offset) {
return theInternalUnsafe.getInt(o, offset);
}
字符串
最新的,反过来,实际上看起来像旧的sun.misc.Unsafe
,但现在这些方法被注解了一些注解:
@HotSpotIntrinsicCandidate
public native void putObject(Object o, long offset, Object x);
型
那么,用Unsafe
启动JDK9是否“安全”?现在是不是公开的官方API?
2条答案
按热度按时间ttcibm8c1#
@paulsm4的解释足以让我们知道是否要进一步使用它。
为什么他们决定不再支持一个长期使用的API?
有用性
在 * The Modular JDKJEP 200 * 中,通过利用 * The Module SystemJEP 261 * 限制对 * 非标准、不稳定和不受支持的API(JDK* 的内部实现细节)* 的访问,可以提高平台的完整性和安全性,**因为许多这些内部API都定义了特权、安全敏感的操作。从长远来看,此更改将降低JDK本身以及库和应用程序维护人员承担的成本,无论这些库和应用程序是有意还是无意地使用这些内部API。
是否计划封装所有内部API?
类别
以上指定的JDK内部API分为两大类:
sun.misc.Unsafe
)。如果有人正在迁移已经使用
Unsafe
的代码,但最终计划离开,该怎么办?它是JDK 9中未封装的关键内部API之一,因为JDK 8中不存在受支持的替换,而与此同时,大多数其他API都已封装或已弃用,将在未来的版本中删除。
Sun.Misc.Unsafe在JDK 9中公开了吗?
目前,要访问关键的内部API(如
Unsafe
),需要定义对jdk.unsupported
模块的依赖关系,该依赖关系是专门为此目的定义的:字符串
*迁移
Unsafe
类中的许多方法的功能已通过 * Variable Handles JEP 193* 提供。jrcvhitl2#
这里有一个很好的解释:
https://adtmag.com/blogs/watersworks/2015/08/java-9-hack.aspx
如何处理Java 9中的sun.misc.Unsafe?一方认为这只是一个糟糕的旧时代的可怕黑客,应该摆脱;另一方认为它的大量使用是Java在基础设施领域崛起的原因,流行的工具仍然需要它。问题是,双方都是对的。
Reinhold在OpenJDK邮件列表中提出,将不受支持的内部API(包括sun.misc.Unsafe)封装在定义和使用它们的模块中。该提案现在是正式的Java增强提案(JEP)。(“封装大多数内部API”)旨在“使大多数JDK的内部API默认不可访问,但留下一些关键的,广泛使用的内部API可访问,直到其全部或大部分功能的支持替代品存在。
简短的回答:你不应该在你从头开始开发的任何新应用程序中使用它。