我在java8中使用“nashorn”javascript引擎来评估运行时的一些表达式.我有一个用于此方法的util类：

    public static String evaluateJavaScriptExpression(String expression) throws ScriptException {
    if (expression == null) {
        return null;
    }
    ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
    ScriptEngine javaScriptEngine = scriptEngineManager.getEngineByName(JAVASCRIPT_ENGINE);
    return String.valueOf(javaScriptEngine.eval(expression));
}

我为此创建了一些单元测试.其中一个是这样的：

    String expression = "var arr = [1, 3, 2, 5, 4]; arr.indexOf(0);";
    assertEquals("-1", ExpressionEvaluatorUtil.evaluateJavaScriptExpression(expression));

当我使用java版本“1.8.0_91”时,它对我来说很好.但是使用java版“1.8.0_92”的人报告说测试失败了.我将我的版本改为92版,但对我来说也失败了.它的实际结果是“-1.0”.
此外,我在Chrome控制台中尝试了相同的js代码,它在构建91中返回“-1”.

有谁知道为什么两个jdk版本之间的结果有这样的差异？这是一个错误还是故意改变了？

解决方法:

好吧,如果你知道更改的确切版本号,你知道在哪里看：the list of 1.8u92 bugfixes列出了一些关于Nashorn的修复,最有趣的是JDK-8144020：

Remove long as an internal numeric type

ECMA defines double as the only number type in JavaScript. In Nashorn, we internally represent numbers as int, long and double. Use of long is problematic because it adds extra precision to the 53 bits provided by double. …

乍一看,这似乎只是一个内部变化,但如果你意识到你以前的结果源于之前的事实,eval为此代码返回了一个Long,格式为“-1”.

现在考虑这个错误报告的第一句话：“ECMA将double定义为JavaScript中唯一的数字类型”.这导致得出结论,返回Long不是指定的结果类型,而是实现工件.

显然,当从内部使用中删除很长时间后,返回Long的可能性被消除,引擎现在不会返回Integer,而是Double,作为变化的副产品.

这解释了为什么还有其他脚本,如“var str =’abcd’; str.indexOf(‘x’);”仍然产生没有小数位的输出.后一个脚本评估为Integer,但仍然如此.由于输出类型的更改是删除内部长使用的副产品,而不是有意更改所有非Double数字结果的操作,因此内部使用int的位置不受影响.

将结果与Chrome引擎进行比较时,您必须考虑只是比较格式化输出,而字符串转换的数字不是脚本的一部分.所以结果没有具体说明.浏览器可以*地呈现匹配整数值而没有小数位的所有数值.