java.lang.Double实现中的不一致性(OracleJDK1.8)？

Question

我查看了java.lang.Double类的实现。NaN的值是0x7ff8000000000000L的指定值。public static final double NaN字段被设置为0.0d / 0.0，如果JVM确实以这种方式实现它，则应该将其计算为0x7ff8000000000000L。

1. 为什么选择这个值(0x7ff8000000000000L)？这个值有什么特别之处(例如它的位掩码)？
2. 为什么字段被隐式地设置为该值，并依赖于0.0d / 0.0操作的底层实现，而静态方法public static long doubleToLongBits(double value)将值显式地设置为0x7ff8000000000000L作为NaN参数？隐式设置它不是安全得多，因为0.0d / 0.0的结果在很大程度上取决于JVM的实现，理论上可以更改(很可能永远不会)？

POSITIVE_INFINITY和NEGATIVE_INFINITY也是如此。字段被隐式设置为它们的值，但是有些方法使用显式指定的值。这背后有什么原因吗？

谢谢你帮助我每天学到新东西:-)。

Answer 1

public static final double NaN字段被设置为0.0d / 0.0，如果JVM确实以这种方式实现它，则应该将其计算为0x7ff8000000000000L。

否:它导致NaN，按语言规范计算

零除以零在NaN中的结果

0x7ff8000000000000L是long，而不是double，因此不能直接用作字段初始化器。

Double.NaN确实声明它的值“等价于Double.longBitsToDouble(0x7ff8000000000000L)返回的值”。但是，0.0d / 0.0优先用于初始化字段，因为它是一个编译时常量值，而方法调用则不是。

(0.0无耻的插头)

为什么选择这个值(0x7ff8000000000000L)？

正如JLS 4.2.3节中所指出的

IEEE754允许为其每种单一和双浮点格式提供多个不同的NaN值.当生成新的NaN时，每个硬件体系结构都会返回特定的NaN位模式，而程序员也可以创建具有不同位模式的NaN来编码，例如回顾性诊断信息。 在大多数情况下，Java平台将给定类型的NaN值视为折叠成单个规范值，因此该规范通常将任意NaN作为规范值引用。

Double.longBitsToDouble方法必须返回一个值，因此这是他们选择返回的值。