JDK 1.8.0_92 Nashorn JS引擎indexOf行为 [英] JDK 1.8.0_92 Nashorn JS engine indexOf behaviour
问题描述
我正在使用Java8中的"nashorn" javascript引擎在运行时评估某些表达式.我有一个util类，可以使用方法:
I am using "nashorn" javascript engine in java8 to evaluate some expressions during runtime. I have a util class for this with method:
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));
}
为此，我创建了一些单元测试.其中之一是这样的:
for which I created some unit tests. One of them goes like this:
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"的人报告测试失败.我将版本切换到build 92，但对我来说也失败了.实际结果是"-1.0". 另外，我在Chrome控制台中尝试了相同的js代码，并且返回的值与内部版本91相同，返回"-1".
It worked fine for me while I was using java version "1.8.0_91". But someone who used java version "1.8.0_92" reported that the test is failing. I switched my version to build 92 and it failed for me as well. The actual result for it is "-1.0". Also, i tried the same js code in Chrome console and it is returning "-1" as in build 91.
有人知道为什么两个jdk版本之间的结果如此不同吗?这是错误还是有意更改?
Does anyone know why there is such difference in results between the two jdk versions? Is this a bug or it was purposely changed?
推荐答案
Well, if you know the precise version number of the change, you know where to look: the list of 1.8u92 bugfixes lists some fixes regarding Nashorn, the most interesting being JDK-8144020:
删除为内部数字类型的时间
ECMA将double定义为JavaScript中唯一的数字类型.在Nashorn中，我们内部将数字表示为int，long和double.使用long是有问题的，因为它为double提供的53位增加了额外的精度. …
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".
At the first glance, this seems to be an internal change only, but the picture changes, if you realize that your former result stemmed from the fact that previously, eval returned a Long for this code, being formatted to "-1".
现在考虑此错误报告的第一句话:" ECMA将double定义为JavaScript中唯一的数字类型".得出的结论是，返回Long不是指定的结果类型，而是实现工件.
Now consider the first sentence of this bug report: "ECMA defines double as the only number type in JavaScript". This leads to the conclusion that returning a Long was not a specified result type, but an implementation artifact.
因此，很明显，当从内部用法中删除long时，消除了返回Long的可能性，并且引擎现在不再返回Integer，而是返回了Double作为更改的副产品
So apparently, when long was removed from the internal usage, the possibility to return Long was eliminated and the engine now doesn’t return Integer instead, but Double, as a byproduct of the change.
这说明了为什么还有其他脚本，例如"var str = 'abcd'; str.indexOf('x');"仍会产生无小数位的输出.后一个脚本的评估结果为Integer并仍然有效.由于输出类型的更改是删除内部long用法的副产品，而不是有意更改所有非Double数值结果的动作，因此内部使用int的位置不会受到影响.
This explains, why there are other scripts like "var str = 'abcd'; str.indexOf('x');" which still produce an output without fractional digits. The latter script evaluated to Integer and still does. Since the change of the output type was a byproduct of removing internal long usage, not an intentional action to change all non-Double numeric results, places internally using int were not affected.
在将结果与Chrome引擎进行比较时，您必须考虑到您只是在比较格式化的输出，而数字到字符串的转换不是脚本的一部分.因此结果是不确定的.浏览器可以自由显示与整数值匹配的所有数字值，而没有小数位数.
When comparing the result with Chrome’s engine, you have to consider that you are only comparing formatted output, with the number to string conversion not being part of the script. So the outcome is unspecified. The browser may take the freedom to present all numeric values matching an integer value without fractional digits.
这篇关于JDK 1.8.0_92 Nashorn JS引擎indexOf行为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
