java - Nashorn 不再使用 BigDecimal

Question

我们从 Oracle JDK 8u77 升级到 8u92，突然之间以前可以工作的脚本不再工作了。一个最小的复制器是:

Map<String, Object> attributes = Collections.singletonMap("GROSSREIMBAMOUNT", BigDecimal.ZERO);
String script = "GROSSREIMBAMOUNT.toFixed(2)";

ScriptEngineManager mgr = new ScriptEngineManager();
ScriptEngine jsEngine = mgr.getEngineByName("JavaScript");

for (Entry<String, Object> entry : attributes.entrySet()) {
  jsEngine.put(entry.getKey(), entry.getValue());
}

System.out.println(jsEngine.eval(script));

之前我们得到

0.00

但现在我们得到了。

TypeError: GROSSREIMBAMOUNT.toFixed is not a function

typeof 现在返回 object，它以前返回 number。

我的问题是这种行为是故意的还是错误？我首先虽然这是一个错误，但是 JDK-8010732似乎另有建议。

Answer 1

Nashorn 的初始版本将所有数字 Java 原语和 java.lang.Number 的所有子类都视为 JavaScript 数字。但是，JavaScript 数字被定义为 double ，这意味着不映射到 double 的数字类型(例如 long 或 java.lang.BigDecimals)在转换为 JavaScript 数字时将遭受精度损失。

如您所见，我们在 8u77 和 8u92 之间修复了此问题。无法干净地映射到 double 的 java.lang.Number 实例在 Nashorn 中不再被视为 JavaScript 数字。

您有两种选择来解决这个问题。一种是将这些数字视为 Java 对象并使用 Java 类提供的方法。这通常是更好的选择，因为编写 Java 类是为了处理手头的数字类型。另一种选择是显式转换为 JavaScript 数字。这通常是通过调用不带“new”关键字的全局 Number() 构造函数来完成的，或者只需在一元“+”运算符前面加上。但请注意，这种转换可能会在您不注意的情况下导致精度损失，因此第一个选项可能是更安全的路径。