sun.misc.Unsafe是否在JDK9中公开？

Question

我只是尝试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吗？

Answer 1

这是一个很好的解释:

https://adtmag.com/blogs/watersworks/2015/08/java-9-hack.aspx

如何处理Java 9中的sun.misc.Unsafe？一方面说这只是一个糟糕的旧时代,应该被摆脱的可怕的黑客; 另一方面说,它的大量使用是造成Java在基础设施领域崛起的原因,而流行的工具仍然需要它.问题是,双方都是对的....

Reinhold在OpenJDK邮件列表上写道,建议在定义和使用它们的模块中封装不受支持的内部API,包括sun.misc.Unsafe.该提案现在是一个正式的Java Enhancement Proposals(JEP).本周发布的JEP 260("封装大多数内部API")旨在"默认情况下使大多数JDK的内部API无法访问,但是可以访问一些关键的,广泛使用的内部API,直到所有或大多数人都支持替换.功能".

简短的回答:你不应该在你从头开发的任何新应用程序中使用它.

Answer 2

@ paulsm4的解释足以知道是否进一步使用它.

长答案~ JEP 260:封装大多数内部API

他们为什么决定删除/弃用长期使用的API的支持？

用处

在模块化JDK _{JEP 200中},通过利用模块系统_{JEP 261}来限制对作为JDK内部实现细节的非标准,不稳定和不受支持的API的访问,提高了平台的完整性和安全性,因为许多这些内部API定义了特权,安全敏感的操作.从长远来看,这种变化将降低 JDK本身的维护者以及有意或无意使用这些内部API的库和应用程序所承担的成本.

是否计划封装所有内部API？

分类

以上指定的JDK内部API分为两大类: -

• 非关键内部API,它们似乎不是由JDK之外的代码使用,或者仅为了方便而被外部代码使用.

• 关键内部API,提供在JDK本身之外实现(如果不是不可能)的关键功能(例如,sun.misc.Unsafe).

如果某人正在迁移已经使用的代码Unsafe,但最终计划离开的代码怎么办？

sun.misc.Unsafe

它是未在JDK 9中封装的那些关键内部API之一,因为在同时大多数其他API被封装或弃用以在将来的版本中被删除时,JDK 8中不存在受支持的替换.

sun.misc.Unsafe是否在JDK9中公开？

• 用法

  目前要访问关键的内部API,例如Unsafe,需要定义对jdk.unsupported模块的依赖性,该模块是专门为此目的定义的:

  module jdk.unsupported {
      exports sun.misc;
      opens sun.misc;
      ...
  }
  

➜ 尽管它可以回答你的问题,你甚至不会发现这个模块的记录,可能是为了限制消费者使用它,而且显然是避免让它"公开"的标志.

• 移民

  Unsafe该类中许多方法的功能已通过Variable Handles _{JEP 193提供}.