JDK-8150219 : ReferenceError in 1.8.0_72
  • Type: Bug
  • Component: core-libs
  • Sub-Component: javax.script
  • Affected Version: 8u72,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2016-02-18
  • Updated: 2016-10-13
  • Resolved: 2016-06-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u112Fixed 9 b124Fixed
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.8.0_72"
Java(TM) SE Runtime Environment (build 1.8.0_72-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.72-b15, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Darwin crab.lan 15.3.0 Darwin Kernel Version 15.3.0: Thu Dec 10 18:40:58 PST 2015; root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64

A DESCRIPTION OF THE PROBLEM :
We've observed a change in behaviour between 1.8.0_71 and 1.8.0_72, where we now see a ReferenceError.

Reproduction code is available.

REGRESSION.  Last worked in version 8u71

ADDITIONAL REGRESSION INFORMATION: 
See https://github.com/makuk66/eval-script-repro, which runs code first with _71 which works, and then with _72, which doesn't.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Clone https://github.com/makuk66/eval-script-repro
Edit run.sh to point to set the JAVA_HOME to point at your copies
Execute ./run.sh
Observe the output is per the README, demonstrating success for _71 and then failure for _72.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I expected _72 to behave in the same way as _71
ACTUAL -
_72 gets a ReferenceError

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "main" javax.script.ScriptException: ReferenceError: "logger" is not defined in <eval> at line number 1
    at jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException(NashornScriptEngine.java:467)
    at jdk.nashorn.api.scripting.NashornScriptEngine.invokeImpl(NashornScriptEngine.java:389)
    at jdk.nashorn.api.scripting.NashornScriptEngine.invokeMethod(NashornScriptEngine.java:199)
    at EvalScript.runTest(EvalScript.java:24)
    at EvalScript.main(EvalScript.java:12)
Caused by: <eval>:1 ReferenceError: "logger" is not defined
    at jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:57)
    at jdk.nashorn.internal.runtime.ECMAErrors.referenceError(ECMAErrors.java:319)
    at jdk.nashorn.internal.runtime.ECMAErrors.referenceError(ECMAErrors.java:291)
    at jdk.nashorn.internal.objects.Global.__noSuchProperty__(Global.java:1428)
    at jdk.nashorn.internal.scripts.Script$Recompilation$1$15A$\^eval\_.L:1(<eval>:1)
    at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:625)
    at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494)
    at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
    at jdk.nashorn.internal.objects.NativeFunction.call(NativeFunction.java:192)
    at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:616)
    at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494)
    at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
    at jdk.nashorn.api.scripting.ScriptObjectMirror.callMember(ScriptObjectMirror.java:199)
    at jdk.nashorn.api.scripting.NashornScriptEngine.invokeImpl(NashornScriptEngine.java:383)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
See https://github.com/makuk66/eval-script-repro/blob/master/EvalScript.java
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
I can change the sample code per https://github.com/makuk66/eval-script-repro/blob/master/EvalScript.java#L19 to make it work.


Comments
This is caused by JDK-8138616 because the initial ScriptContext is no longer permanently associated with the Nashorn Global. The problem is that in the eval call with the ScriptContext argument a new Nashorn global is created. However, it is not permanently associated with the ScriptContext, so in the invokeMethod call we fall back to the engine's default context. I wonder if we shouldn't restore Global.initscontext (as its removal was not required to fix JDK-8138616). Another solution might be to set the Global.scontext thread-local when a Global is created for a ScriptContext on demand.
02-03-2016

Attached test case executed on : JDK 8u71 - Pass JDK 8u72 - Fail JDK 8u76 - Fail JDK 9ea b103 -Fail
19-02-2016