JDK-8046013 : TypeError: Cannot apply "with" to non script object
  • Type: Bug
  • Component: core-libs
  • Sub-Component: jdk.nashorn
  • Affected Version: 8u40
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2014-06-05
  • Updated: 2015-03-05
  • Resolved: 2014-08-18
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
8u40Fixed 9 b22Fixed
Related Reports
Relates :  
Relates :  
Description
Using "with" may fail in situations where it is not really expected. See the attached sample file which demonstrates a failure on JDK8b132.
Comments
Issue JDK-8047764 has been fixed in revision c1f651636d9c and now it is enough to $ hg clone http://hg.netbeans.org/html4j/ $ cd html4j $ hg up -C release-1.0 $ mvn clean install -DskipTests $ cd boot-script $ JAVA_HOME=/jdk9/build/linux-x86_64-normal-server-release/images/j2sdk-image/ mvn clean install javax.script.ScriptException: ReferenceError: "style" is not defined in <eval> at line number 2933 at column number 20 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:929) at jdk.nashorn.internal.scripts.Script$Recompilation$907$2209A$\=nashorn\!mozilla_compat.value-1$__noSuchProperty__(nashorn:mozilla_compat.js:67) at jdk.nashorn.internal.scripts.Script$Recompilation$2045$86$\^function\_.L:1$css(<function>:2) at jdk.nashorn.internal.scripts.Script$Recompilation$2044$175261AAAAA$\^eval\_.L:50$L:52$L:73$update-1(<eval>:3696) Tests run: 100, Failures: 2, Errors: 0, Skipped: 0 However I am not longer sure the "style" problem is related to this "with" problem. More likely it will be incompatibility in mozilla emulation or simulation of env.js - e.g. JDK-8006183. Should I report new bug?
23-09-2014

I am sorry for making things so complicated. The way to overcome the ClassCastException (until JDK-8047764 is fixed) is to comment out toString() method in the env.nashorn.1.2-debug.js emulation: --- Base (BASE) +++ Locally Modified (Based On LOCAL) @@ -23867,9 +23867,6 @@ get window(){ return this; }, - toString : function(){ - return '[Window]'; - }, /** * getComputedStyle
20-08-2014

When I run tests as directed, I see ClassCastException mentioned in JDK-8047764. How do I get this? javax.script.ScriptException: Error: Unable to parse bindings. Message: ReferenceError: "style" is not defined; Bindings value: css: style in <eval> at line number 1941 at column number 16 at jdk.nashorn.internal.objects.NativeError.initException(NativeError.java:137) at jdk.nashorn.internal.objects.NativeError.<init>(NativeError.java:102) at jdk.nashorn.internal.objects.NativeError.<init>(NativeError.java:106) at jdk.nashorn.internal.objects.NativeError.<init>(NativeError.java:110) at jdk.nashorn.internal.objects.NativeError.constructor(NativeError.java:129) at jdk.nashorn.internal.scripts.Script$Recompilation$1585$\^eval\_.L:5$L:7$L:21$L:1903$parseBindingsString(<eval>:1941)
20-08-2014

To verify the fix, please run "ant clean test" on nashorn repo. In the commit message there are two tests added to verify the fix. You can check that ant clean test passes along with the tests added - these are tests were abstracted/derived from the test provided in the bug reported. If you're facing other issues in your program, please create a new bug with a test case. We have fixed a number of (different) issues with "with" statement. The new issue you're facing may or may not be related.
18-08-2014

That said, I'm cloning html4j project and following your steps. If any of us find specific issues, we can file new bug(s) and track those. Thanks.
18-08-2014

I have a feeling I can't verify the fix. While it is true, there has been some changes, it seems to me that the general problem remains. May I ask for deeper evaluation of it? To reproduce: I have JDK9 with nashorn repository at revision 7404f40a22e1, when I use that JDK to my project like this: $ hg clone http://hg.netbeans.org/html4j/ $ cd html4j $ mvn clean install -DskipTests $ cd boot-scripts $ JAVA_HOME=/jdk9/build/linux-x86_64-normal-server-release/images/j2sdk-image/ mvn clean install There are still failures: Tests run: 84, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 71.825 sec <<< FAILURE! paintTheGridOnClick(net.java.html.boot.script.ko4j.KOCase) Time elapsed: 1.597 sec <<< FAILURE! javax.script.ScriptException: Error: Unable to parse bindings. Message: ReferenceError: "style" is not defined; Bindings value: css: style in <eval> at line number 1941 at column number 16 at jdk.nashorn.internal.objects.NativeError.initException(NativeError.java:137) at jdk.nashorn.internal.objects.NativeError.<init>(NativeError.java:102) at jdk.nashorn.internal.objects.NativeError.<init>(NativeError.java:106) at jdk.nashorn.internal.objects.NativeError.<init>(NativeError.java:110) at jdk.nashorn.internal.objects.NativeError.constructor(NativeError.java:129) at jdk.nashorn.internal.scripts.Script$Recompilation$1585$\^eval\_.L:5$L:7$L:21$L:1903$parseBindingsString(<eval>:1941) Can you please take a look and verify these are not related to the "with" problem (I know that "parse bindings" is done with "with", so I assume they are). Thanks.
15-08-2014

I tried to verify the fix today, but I have problems to find a working nashorn. The fix 33e826f0e742 is added on top of JDK-8047764 which completely breaks my project. I tried to backport the fix to older release of JDK8 (096dc407d310), but I must have done something wrong, as it does not seem to work. It would help to have a fix of this issue without the JDK-8047764 regression.
14-07-2014

Fixing 'with' to accept any ScriptObjectMirror (to avoid any possible 'surprise' further)
27-06-2014

I have to admit I never dreamed of passing ScriptObjectMirror objects between two different engines. It is nice that it works, but imho it is not the primary usecase. I'd rather be able to use objects emitted by a single ScriptEngine with the same engine without any fear of forgetting wrapping/unwrapping them. I suggest not to use symmetry as a reason for keeping status quo. Symmetry is nice, but it is not the core reason why we write software systems (chapter 13 of ISBN-10: 1430209739: "Extreme Advice Considered Harmful" even has a section called "An API has to be Symmetrical"), so this is nothing new. I always believed symmetry is for artists, while we are engineers. Personally I would be OK with fix that does unwrapping for own ScriptObjectMirror object only and would leave the rest (e.g. "make with(...) work with any ScriptObjectMirror") for a future enhancement.
26-06-2014

Test and one line fix to make "with" work with ScriptObjectMirror. But I am still working on it.
20-06-2014

That patch would work provided the ScriptObjectMirror passed was created from the current global as home global (in which the with statement is also evaluated). Say, if you have a ScriptObjectMirror created with another global (from another script engine instance perhaps or from script evaluated with another global as ENGINE_SCOPE bindings), then unwrap won't give us a ScriptObject. (please check ScriptObjectMirror.unwrap -- it unwraps only when home global matches given global or else returns script object mirror "as is"). public static Object unwrap(final Object obj, final Object homeGlobal) { if (obj instanceof ScriptObjectMirror) { final ScriptObjectMirror mirror = (ScriptObjectMirror)obj; return (mirror.global == homeGlobal)? mirror.sobj : obj; } return obj; } So, the patch won't work if ScriptObjectMirror is out of some other global. But, if you see in other APIs where ScriptObjectMirrors are allowed along with ScriptObjects, *any* ScriptObjectMirror works -- because those APIs use ScriptObjectMirror's interface -- without even unwrapping. For eg. Object.getPrototypeOf works for any ScriptObject or ScriptObjectMirror. So is "for..in/for..each" statements. These two use APIs exposed on ScriptObjectMirror. Now, to do what "with" statement expects from "expression" object out of (any) ScriptObjectMirror is .. hard (because of dependencies on ScriptObject in WithObject class). Unless we do that, we would break the symmetry. i.e., we'd have to say, with statement would work on ScriptObjects expressions and ScriptObjectMirrors provided mirror is out of the current global scope - which in my opinion is very hacky solution.
20-06-2014

That comment about treating ScriptObjectMirror as though script object is guarded "wherever possible". Not in the with case. While we can unwrap in the case of current global matches the home global of ScriptObjectMirror, that is not ScriptObjectMirrors are handled elsewhere -- any ScriptObjectMirror works elsewhere (not just mirrors that belong to current global).
20-06-2014

In contrary to JDK-8046009, I believe the "with problem" has solution and also should be fixed. An illustrative quote from the documentation page https://wiki.openjdk.java.net/display/Nashorn/Nashorn+jsr223+engine+notes follows: "Wherever possible, nashorn engine tries to treat instances of ScriptObjectMirror and JSObject as though they are 'normal' script objects" I believe it is possible to make the "with statement" work with ScriptObjectMirror. I will investigate if I can prepare a patch. Meanwhile reopening to get an early review comment.
20-06-2014

Comment in JDK-8046009. User should not expect to assign script objects in Java collections, arrays "as is" resulting in "mixing" of ScriptObjectMirrors and ScriptObjects.
09-06-2014