From marcus.lagergren at oracle.com Tue Apr 1 09:19:44 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Tue, 01 Apr 2014 09:19:44 +0000 Subject: hg: nashorn/jdk9/nashorn: 8038799: Guard and unbox boxed primitives types on setting them in Properties to avoid megamorphisism Message-ID: <201404010919.s319JjSq019519@aojmv0008> Changeset: 899b6f171676 Author: lagergren Date: 2014-04-01 11:19 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/899b6f171676 8038799: Guard and unbox boxed primitives types on setting them in Properties to avoid megamorphisism Reviewed-by: attila, jlaskey ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/lookup/MethodHandleFactory.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/PropertyHashMap.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java - test/script/basic/runsunspider-lazy.js.EXPECTED From hannes.wallnoefer at oracle.com Tue Apr 1 12:35:19 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 01 Apr 2014 14:35:19 +0200 Subject: Review request for JDK-8038638: Persistent store for compiled scripts Message-ID: <533AB287.6050000@oracle.com> Please review JDK-8038638: Persistent store for compiled scripts: http://cr.openjdk.java.net/~hannesw/8038638/webrev.01/ This adds a --persistent-code-cache/-pcc option to allow storing compiled script classes between runs. Thanks, Hannes From marcus.lagergren at oracle.com Tue Apr 1 14:12:59 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Tue, 01 Apr 2014 14:12:59 +0000 Subject: hg: nashorn/jdk9/nashorn: 8038945: Simplify strict undefined checks Message-ID: <201404011413.s31ED0dC003616@aojmv0008> Changeset: 1b9bd93570f8 Author: lagergren Date: 2014-04-01 16:12 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/1b9bd93570f8 8038945: Simplify strict undefined checks Reviewed-by: jlaskey, hannesw ! src/jdk/internal/dynalink/support/CallSiteDescriptorFactory.java ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationEnvironment.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FindScopeDepths.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java + test/script/basic/JDK-8038945.js + test/script/basic/JDK-8038945.js.EXPECTED From marcus.lagergren at oracle.com Wed Apr 2 08:54:45 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Wed, 02 Apr 2014 08:54:45 +0000 Subject: hg: nashorn/jdk9/nashorn: 8039044: Expand undefined intrinsics for all commutative combinators of scrict undefined checks Message-ID: <201404020854.s328sjjn014310@aojmv0008> Changeset: 2aaf89857444 Author: lagergren Date: 2014-04-02 10:52 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/2aaf89857444 8039044: Expand undefined intrinsics for all commutative combinators of scrict undefined checks Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! test/script/basic/JDK-8038945.js ! test/script/basic/JDK-8038945.js.EXPECTED From sundararajan.athijegannathan at oracle.com Wed Apr 2 09:38:36 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 02 Apr 2014 15:08:36 +0530 Subject: RFR 8039047: Parser accepts conditional catch clauses even when --no-syntax-extensions / -nse option is passed Message-ID: <533BDA9C.2000407@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8039047/ Bug: https://bugs.openjdk.java.net/browse/JDK-8039047 Thanks -Sundar From marcus.lagergren at oracle.com Wed Apr 2 13:28:22 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 2 Apr 2014 15:28:22 +0200 Subject: RFR 8039047: Parser accepts conditional catch clauses even when --no-syntax-extensions / -nse option is passed In-Reply-To: <533BDA9C.2000407@oracle.com> References: <533BDA9C.2000407@oracle.com> Message-ID: <9C89FCD2-4A68-4943-A6AC-646E99513050@oracle.com> Looks good. +1 /M On 02 Apr 2014, at 11:38, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8039047/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8039047 > > Thanks > -Sundar From marcus.lagergren at oracle.com Wed Apr 2 13:28:34 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 2 Apr 2014 15:28:34 +0200 Subject: Review request for JDK-8038638: Persistent store for compiled scripts In-Reply-To: <533AB287.6050000@oracle.com> References: <533AB287.6050000@oracle.com> Message-ID: Looks good. On 01 Apr 2014, at 14:35, Hannes Wallnoefer wrote: > Please review JDK-8038638: Persistent store for compiled scripts: > > http://cr.openjdk.java.net/~hannesw/8038638/webrev.01/ > > This adds a --persistent-code-cache/-pcc option to allow storing compiled script classes between runs. > > Thanks, > Hannes From attila.szegedi at oracle.com Wed Apr 2 13:28:31 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 2 Apr 2014 15:28:31 +0200 Subject: RFR 8039047: Parser accepts conditional catch clauses even when --no-syntax-extensions / -nse option is passed In-Reply-To: <533BDA9C.2000407@oracle.com> References: <533BDA9C.2000407@oracle.com> Message-ID: <770E1A20-1029-47F9-997B-5A2E37BCC277@oracle.com> +1 On Apr 2, 2014, at 11:38 AM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8039047/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8039047 > > Thanks > -Sundar From hannes.wallnoefer at oracle.com Thu Apr 3 15:32:54 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 03 Apr 2014 17:32:54 +0200 Subject: Review request for JDK-8039181: Persistent code store does not use absolute paths internally Message-ID: <533D7F26.2070300@oracle.com> Please review JDK-8039181: Persistent code store does not use absolute paths internally: http://cr.openjdk.java.net/~hannesw/8039181/ The updated webrev makes sure File.getAbsoluteFile() is called in doPrivileged section. Thanks, Hannes From james_ladd at hotmail.com Sun Apr 6 03:51:56 2014 From: james_ladd at hotmail.com (James Ladd) Date: Sun, 6 Apr 2014 13:51:56 +1000 Subject: remote code/scripts ... In-Reply-To: References: , Message-ID: I'd like to fetch remote code on the server side much like the script tag allows for in the browser. How can I do this with Nashorn? Anything built in? - James. From kon at outrospective.org Sun Apr 6 04:19:30 2014 From: kon at outrospective.org (Kon Soulianidis) Date: Sun, 6 Apr 2014 14:19:30 +1000 Subject: remote code/scripts ... In-Reply-To: <5342334E1D9E4FCCAB6E54CC987841B4@outrospecitve.org> References: <,> <5342334E1D9E4FCCAB6E54CC987841B4@outrospecitve.org> Message-ID: <136034378746453BB610803BF4A60A88@outrospecitve.org> Hi James Would the load function listed in the Nashorn extensions page under Extension properties, functions in global object (https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-Extensionpropertieshttps://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions) do the trick? Cheers -- Kon Soulianidis Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Sunday, 6 April 2014 at 1:51 pm, James Ladd wrote: > I'd like to fetch remote code on the server side much like the script tag > allows for in the browser. > > How can I do this with Nashorn? Anything built in? > > - James. > From james_ladd at hotmail.com Sun Apr 6 05:13:58 2014 From: james_ladd at hotmail.com (James Ladd) Date: Sun, 6 Apr 2014 15:13:58 +1000 Subject: can load from URL wout --scripting? In-Reply-To: References: Message-ID: Nashorners, Can I call load() with a URL without the --scripting extensions? I'm running JDK8 and default Nashorn environment and I want to use load() to load a URL but it appears to just hang. Are there security permissions to be enabled to allow load of URL's? - James. From hannes.wallnoefer at oracle.com Sun Apr 6 07:41:21 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Sun, 06 Apr 2014 09:41:21 +0200 Subject: can load from URL wout --scripting? In-Reply-To: References: Message-ID: <53410521.8030500@oracle.com> This works for me with plain jjs command: jjs> load("https://raw.github.com/lodash/lodash/2.4.1/dist/lodash.js"); Maybe it has something to do with your proxy settings. Did you test whether cURL/wget or similar command line tool work with the same URL? This might be useful: http://docs.oracle.com/javase/6/docs/technotes/guides/net/proxies.html Hannes Am 2014-04-06 07:13, schrieb James Ladd: > Nashorners, > > Can I call load() with a URL without the --scripting extensions? > > I'm running JDK8 and default Nashorn environment and I want to > use load() to load a URL but it appears to just hang. > > Are there security permissions to be enabled to allow load of URL's? > > - James. > From sundararajan.athijegannathan at oracle.com Mon Apr 7 03:07:58 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 07 Apr 2014 08:37:58 +0530 Subject: can load from URL wout --scripting? In-Reply-To: References: Message-ID: <5342168E.4030906@oracle.com> load is available always - regardless of -scripting option. If you are running under security manager, your app's permissions to resolve/read a URL will apply. Also, make sure that you can reach beyond your proxy, if any. i.e., you can download that .js file from your Java code at all, you should be able to use 'load' to download and execute that script. -Sundar On Sunday 06 April 2014 10:43 AM, James Ladd wrote: > Nashorners, > > Can I call load() with a URL without the --scripting extensions? > > I'm running JDK8 and default Nashorn environment and I want to > use load() to load a URL but it appears to just hang. > > Are there security permissions to be enabled to allow load of URL's? > > - James. > From kon at outrospective.org Sun Apr 6 04:13:00 2014 From: kon at outrospective.org (Kon Soulianidis) Date: Sun, 6 Apr 2014 14:13:00 +1000 Subject: remote code/scripts ... In-Reply-To: References: <,> Message-ID: Hi James Would the load function listed in the Nashorn extensions page under Extension properties, functions in global object (https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-Extensionpropertieshttps://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions) do the trick? Cheers -- Kon Soulianidis Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Sunday, 6 April 2014 at 1:51 pm, James Ladd wrote: > I'd like to fetch remote code on the server side much like the script tag > allows for in the browser. > > How can I do this with Nashorn? Anything built in? > > - James. > > > From kon at outrospective.org Sun Apr 6 04:16:04 2014 From: kon at outrospective.org (Kon Soulianidis) Date: Sun, 6 Apr 2014 14:16:04 +1000 Subject: remote code/scripts ... In-Reply-To: References: <,> Message-ID: <5342334E1D9E4FCCAB6E54CC987841B4@outrospecitve.org> Hi James Would the load function listed in the Nashorn extensions page under Extension properties, functions in global object (https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-Extensionpropertieshttps://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions) do the trick? Cheers -- Kon Soulianidis Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Sunday, 6 April 2014 at 1:51 pm, James Ladd wrote: > I'd like to fetch remote code on the server side much like the script tag > > > allows for in the browser. > > How can I do this with Nashorn? Anything built in? > > - James. > > From sundararajan.athijegannathan at oracle.com Mon Apr 7 15:23:29 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 07 Apr 2014 20:53:29 +0530 Subject: RFR 8039387: Nashorn supports indexed access of List elements, but length property is not supported Message-ID: <5342C2F1.4070400@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8039387/ Bug: https://bugs.openjdk.java.net/browse/JDK-8039387 Thanks -Sundar From james.laskey at oracle.com Mon Apr 7 16:20:17 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 7 Apr 2014 13:20:17 -0300 Subject: RFR 8039387: Nashorn supports indexed access of List elements, but length property is not supported In-Reply-To: <5342C2F1.4070400@oracle.com> References: <5342C2F1.4070400@oracle.com> Message-ID: <9B7DB210-540B-4263-AF3D-B62D827BF102@oracle.com> +1 On Apr 7, 2014, at 12:23 PM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8039387/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8039387 > > Thanks > -Sundar From youribm at gmail.com Wed Apr 9 15:23:21 2014 From: youribm at gmail.com (=?ISO-8859-1?Q?Youri_Bonnaff=E9?=) Date: Wed, 9 Apr 2014 17:23:21 +0200 Subject: Nashorn, Security manager and custom policy Message-ID: Hi, I'm trying to run this very sample JS file: println(java.lang.System.getProperty("os.name")) using jrunscript. $> jrunscript test.js Linux Now when I set a Security Manager: $> jrunscript -J-Djava.security.manager test.js Exception in thread "main" java.security.AccessControlException: access denied ("java.io.FilePermission" "test.js" "read") at java.security.AccessControlContext.checkPermission(AccessControlContext.java:457) at java.security.AccessController.checkPermission(AccessController.java:884) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.lang.SecurityManager.checkRead(SecurityManager.java:888) at java.io.FileInputStream.(FileInputStream.java:121) at java.io.FileInputStream.(FileInputStream.java:87) at com.sun.tools.script.shell.Main.processSource(Main.java:279) at com.sun.tools.script.shell.Main.access$100(Main.java:37) at com.sun.tools.script.shell.Main$2.run(Main.java:200) at com.sun.tools.script.shell.Main.main(Main.java:48) which is expected. Now when I set a custom policy such as: grant { permission java.security.AllPermission; }; $> jrunscript -J-Djava.security.manager -J-Djava.security.policy=test.policy test.js java.security.AccessControlException: access denied ("java.util.PropertyPermission" "os.name" "read") at java.security.AccessControlContext.checkPermission(AccessControlContext.java:457) at java.security.AccessController.checkPermission(AccessController.java:884) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) at java.lang.System.getProperty(System.java:714) at jdk.nashorn.internal.scripts.Script$test.runScript(test.js:1) at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:498) at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:206) at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:378) at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:546) at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:528) at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:524) at jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:189) at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:249) at com.sun.tools.script.shell.Main.evaluateReader(Main.java:332) at com.sun.tools.script.shell.Main.evaluateStream(Main.java:368) at com.sun.tools.script.shell.Main.processSource(Main.java:285) at com.sun.tools.script.shell.Main.access$100(Main.java:37) at com.sun.tools.script.shell.Main$2.run(Main.java:200) at com.sun.tools.script.shell.Main.main(Main.java:48) This happens only with a JDK8/Nashorn, if I do the same with JDK7, the last command will succeed. I failed to find information elsewhere so that's why I asking for help here. Do you understand what might happen? And what changed around security manager with JDK8/Nashorn? Thanks, Youri From sundararajan.athijegannathan at oracle.com Wed Apr 9 15:58:15 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 09 Apr 2014 21:28:15 +0530 Subject: Nashorn, Security manager and custom policy In-Reply-To: References: Message-ID: <53456E17.3010805@oracle.com> Hi, There are two shell tools in JDK8. "jjs", "jrunscript". jjs uses direct Nashorn (internal) classes and associates script URL to source files (and therefore permission etc.) Your example works fine with jjs with println replaced as "print". jjs -J-Djava.security.manager -J-Djava.security.policy=test.policy test.js is fine. Prints OS name with the modified policy and throws security exception without that policy. jrunscript uses javax.script API and evaluates scripts by ScriptEngine.eval methods (passing "string" code or Reader made out of test.js). javax.script API has no way to associate a source URL to a script (either String or Reader). So, "test.js" is loaded as script without "origin" (i.e., origin unknown). Such scripts are given only minimal permissions (url being null). But, then your policy gives AllPermission to any code regardless code origin and so it can be expected to have AllPermission (even when url is null). That issue - of only giving minimal permissions to null url scripts - has been fixed in update release. It'll appear in an 8 update release. For the interim, please use jjs for this case. Note that specific URL permission should work now as expected. PS. BTW, AFAIK, jrunscript in jdk7 uses Rhino and does not work with security manager enabled. Are you sure it worked for you? you may want to double check. Hope this helps, -Sundar On Wednesday 09 April 2014 08:53 PM, Youri Bonnaff? wrote: > Hi, > > I'm trying to run this very sample JS file: > > println(java.lang.System.getProperty("os.name")) > > using jrunscript. > > $> jrunscript test.js > Linux > > Now when I set a Security Manager: > > $> jrunscript -J-Djava.security.manager test.js > Exception in thread "main" java.security.AccessControlException: access > denied ("java.io.FilePermission" "test.js" "read") > at > java.security.AccessControlContext.checkPermission(AccessControlContext.java:457) > at java.security.AccessController.checkPermission(AccessController.java:884) > at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) > at java.lang.SecurityManager.checkRead(SecurityManager.java:888) > at java.io.FileInputStream.(FileInputStream.java:121) > at java.io.FileInputStream.(FileInputStream.java:87) > at com.sun.tools.script.shell.Main.processSource(Main.java:279) > at com.sun.tools.script.shell.Main.access$100(Main.java:37) > at com.sun.tools.script.shell.Main$2.run(Main.java:200) > at com.sun.tools.script.shell.Main.main(Main.java:48) > > which is expected. > > Now when I set a custom policy such as: > > grant { > permission java.security.AllPermission; > }; > > $> jrunscript -J-Djava.security.manager > -J-Djava.security.policy=test.policy test.js > java.security.AccessControlException: access denied > ("java.util.PropertyPermission" "os.name" "read") > at > java.security.AccessControlContext.checkPermission(AccessControlContext.java:457) > at java.security.AccessController.checkPermission(AccessController.java:884) > at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) > at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) > at java.lang.System.getProperty(System.java:714) > at jdk.nashorn.internal.scripts.Script$test.runScript(test.js:1) > at > jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:498) > at > jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:206) > at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:378) > at > jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:546) > at > jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:528) > at > jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:524) > at > jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:189) > at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:249) > at com.sun.tools.script.shell.Main.evaluateReader(Main.java:332) > at com.sun.tools.script.shell.Main.evaluateStream(Main.java:368) > at com.sun.tools.script.shell.Main.processSource(Main.java:285) > at com.sun.tools.script.shell.Main.access$100(Main.java:37) > at com.sun.tools.script.shell.Main$2.run(Main.java:200) > at com.sun.tools.script.shell.Main.main(Main.java:48) > > This happens only with a JDK8/Nashorn, if I do the same with JDK7, the last > command will succeed. I failed to find information elsewhere so that's why > I asking for help here. Do you understand what might happen? And what > changed around security manager with JDK8/Nashorn? > > Thanks, > > Youri From youribm at gmail.com Thu Apr 10 08:27:41 2014 From: youribm at gmail.com (=?ISO-8859-1?Q?Youri_Bonnaff=E9?=) Date: Thu, 10 Apr 2014 10:27:41 +0200 Subject: Nashorn, Security manager and custom policy In-Reply-To: <53456E17.3010805@oracle.com> References: <53456E17.3010805@oracle.com> Message-ID: Thanks for you answer. Unfortunately our use case uses the ScriptEngine from Java code to run JS scripts (I was using jrunscript here for testing purpose), so jjs is not an option for us. I double checked with JDK7: $> jrunscript -J-Djava.security.manager test.js script error in file : sun.org.mozilla.javascript.internal.WrappedException: Wrapped java.security.AccessControlException: access denied ("java.util.PropertyPermission" "*" "read,write") (#194) in at line number 194 It seems the security manager is enabled but raises an exception even before the script is executed. I tested something else. Here is the policy used: *grant {* * permission java.io.FilePermission "test.js", "read";* * permission java.io.FilePermission "foo", "read";* * permission java.util.PropertyPermission "*", "read,write";* *};* and the script: *println(java.lang.System.getProperty("os.name "))* *new java.io.File("titi").exists()* if I run *$> jrunscript -J-Djava.security.manager -J-Djava.security.policy=test.policy test.js* it works. Now if I comment out the line with the file permission on "foo", it will produce: *$> jrunscript -J-Djava.security.manager -J-Djava.security.policy=test.policy test.js* *Linux* *script error in file test.js : sun.org.mozilla.javascript.internal.WrappedException: Wrapped java.security.AccessControlException: access denied ("java.io.FilePermission" "foo" "read") (test.js#2) in test.js at line number 2* It seems that the security manager is taken into account. It it quite an issue for us as we run our application with security manager enabled and allow JS scripts to be executed through the ScriptEngine. The scripts can be String or Reader and they can be provided by the end user (so setting codeBase values is not an option). Do you have any idea on when the fix will be released? Thanks, Youri, On 9 April 2014 17:58, A. Sundararajan < sundararajan.athijegannathan at oracle.com> wrote: > Hi, > > There are two shell tools in JDK8. "jjs", "jrunscript". > > jjs uses direct Nashorn (internal) classes and associates script URL to > source files (and therefore permission etc.) Your example works fine with > jjs with println replaced as "print". > > jjs -J-Djava.security.manager -J-Djava.security.policy=test.policy > test.js > > is fine. Prints OS name with the modified policy and throws security > exception without that policy. > > jrunscript uses javax.script API and evaluates scripts by > ScriptEngine.eval methods (passing "string" code or Reader made out of > test.js). javax.script API has no way to associate a source URL to a script > (either String or Reader). So, "test.js" is loaded as script without > "origin" (i.e., origin unknown). Such scripts are given only minimal > permissions (url being null). But, then your policy gives AllPermission to > any code regardless code origin and so it can be expected to have > AllPermission (even when url is null). That issue - of only giving minimal > permissions to null url scripts - has been fixed in update release. It'll > appear in an 8 update release. For the interim, please use jjs for this > case. Note that specific URL permission should work now as expected. > > PS. BTW, AFAIK, jrunscript in jdk7 uses Rhino and does not work with > security manager enabled. Are you sure it worked for you? you may want to > double check. > > Hope this helps, > -Sundar > > > On Wednesday 09 April 2014 08:53 PM, Youri Bonnaff? wrote: > >> Hi, >> >> I'm trying to run this very sample JS file: >> >> println(java.lang.System.getProperty("os.name")) >> >> using jrunscript. >> >> $> jrunscript test.js >> Linux >> >> Now when I set a Security Manager: >> >> $> jrunscript -J-Djava.security.manager test.js >> Exception in thread "main" java.security.AccessControlException: access >> denied ("java.io.FilePermission" "test.js" "read") >> at >> java.security.AccessControlContext.checkPermission( >> AccessControlContext.java:457) >> at java.security.AccessController.checkPermission( >> AccessController.java:884) >> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) >> at java.lang.SecurityManager.checkRead(SecurityManager.java:888) >> at java.io.FileInputStream.(FileInputStream.java:121) >> at java.io.FileInputStream.(FileInputStream.java:87) >> at com.sun.tools.script.shell.Main.processSource(Main.java:279) >> at com.sun.tools.script.shell.Main.access$100(Main.java:37) >> at com.sun.tools.script.shell.Main$2.run(Main.java:200) >> at com.sun.tools.script.shell.Main.main(Main.java:48) >> >> which is expected. >> >> Now when I set a custom policy such as: >> >> grant { >> permission java.security.AllPermission; >> }; >> >> $> jrunscript -J-Djava.security.manager >> -J-Djava.security.policy=test.policy test.js >> java.security.AccessControlException: access denied >> ("java.util.PropertyPermission" "os.name" "read") >> at >> java.security.AccessControlContext.checkPermission( >> AccessControlContext.java:457) >> at java.security.AccessController.checkPermission( >> AccessController.java:884) >> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) >> at java.lang.SecurityManager.checkPropertyAccess( >> SecurityManager.java:1294) >> at java.lang.System.getProperty(System.java:714) >> at jdk.nashorn.internal.scripts.Script$test.runScript(test.js:1) >> at >> jdk.nashorn.internal.runtime.ScriptFunctionData.invoke( >> ScriptFunctionData.java:498) >> at >> jdk.nashorn.internal.runtime.ScriptFunction.invoke( >> ScriptFunction.java:206) >> at jdk.nashorn.internal.runtime.ScriptRuntime.apply( >> ScriptRuntime.java:378) >> at >> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl( >> NashornScriptEngine.java:546) >> at >> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl( >> NashornScriptEngine.java:528) >> at >> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl( >> NashornScriptEngine.java:524) >> at >> jdk.nashorn.api.scripting.NashornScriptEngine.eval( >> NashornScriptEngine.java:189) >> at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:249) >> at com.sun.tools.script.shell.Main.evaluateReader(Main.java:332) >> at com.sun.tools.script.shell.Main.evaluateStream(Main.java:368) >> at com.sun.tools.script.shell.Main.processSource(Main.java:285) >> at com.sun.tools.script.shell.Main.access$100(Main.java:37) >> at com.sun.tools.script.shell.Main$2.run(Main.java:200) >> at com.sun.tools.script.shell.Main.main(Main.java:48) >> >> This happens only with a JDK8/Nashorn, if I do the same with JDK7, the >> last >> command will succeed. I failed to find information elsewhere so that's why >> I asking for help here. Do you understand what might happen? And what >> changed around security manager with JDK8/Nashorn? >> >> Thanks, >> >> Youri >> > > From sundararajan.athijegannathan at oracle.com Thu Apr 10 09:40:00 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 10 Apr 2014 15:10:00 +0530 Subject: Nashorn, Security manager and custom policy In-Reply-To: References: <53456E17.3010805@oracle.com> Message-ID: <534666F0.3020503@oracle.com> As I said earlier, with jdk7 jrunscript + security manager mode never worked - which is what you confirmed. jrunscript's initial script "init.js" itself throws security exception - i.e., you may have to give lot more permissions as you found out. As for particular release in which nashorn's fix for null URL will make it in, I can't say for sure - most likely 8u20. Please watch out jdk8u-dev alias and/or release notes of jdk8 update releases. Thanks -Sundar On Thursday 10 April 2014 01:57 PM, Youri Bonnaff? wrote: > Thanks for you answer. > > Unfortunately our use case uses the ScriptEngine from Java code to run JS > scripts (I was using jrunscript here for testing purpose), so jjs is not an > option for us. > > I double checked with JDK7: > > $> jrunscript -J-Djava.security.manager test.js > script error in file : > sun.org.mozilla.javascript.internal.WrappedException: Wrapped > java.security.AccessControlException: access denied > ("java.util.PropertyPermission" "*" "read,write") (#194) in > at line number 194 > > It seems the security manager is enabled but raises an exception even > before the script is executed. I tested something else. Here is the policy > used: > > *grant {* > * permission java.io.FilePermission "test.js", "read";* > * permission java.io.FilePermission "foo", "read";* > * permission java.util.PropertyPermission "*", "read,write";* > *};* > > and the script: > > *println(java.lang.System.getProperty("os.name "))* > *new java.io.File("titi").exists()* > > if I run > > > *$> jrunscript -J-Djava.security.manager > -J-Djava.security.policy=test.policy test.js* > > it works. Now if I comment out the line with the file permission on "foo", > it will produce: > > *$> jrunscript -J-Djava.security.manager > -J-Djava.security.policy=test.policy test.js* > *Linux* > *script error in file test.js : > sun.org.mozilla.javascript.internal.WrappedException: Wrapped > java.security.AccessControlException: access denied > ("java.io.FilePermission" "foo" "read") (test.js#2) in test.js at line > number 2* > > It seems that the security manager is taken into account. It it quite an > issue for us as we run our application with security manager enabled and > allow JS scripts to be executed through the ScriptEngine. The scripts can > be String or Reader and they can be provided by the end user (so setting > codeBase values is not an option). > Do you have any idea on when the fix will be released? > > Thanks, > > Youri, > > > On 9 April 2014 17:58, A. Sundararajan < > sundararajan.athijegannathan at oracle.com> wrote: > >> Hi, >> >> There are two shell tools in JDK8. "jjs", "jrunscript". >> >> jjs uses direct Nashorn (internal) classes and associates script URL to >> source files (and therefore permission etc.) Your example works fine with >> jjs with println replaced as "print". >> >> jjs -J-Djava.security.manager -J-Djava.security.policy=test.policy >> test.js >> >> is fine. Prints OS name with the modified policy and throws security >> exception without that policy. >> >> jrunscript uses javax.script API and evaluates scripts by >> ScriptEngine.eval methods (passing "string" code or Reader made out of >> test.js). javax.script API has no way to associate a source URL to a script >> (either String or Reader). So, "test.js" is loaded as script without >> "origin" (i.e., origin unknown). Such scripts are given only minimal >> permissions (url being null). But, then your policy gives AllPermission to >> any code regardless code origin and so it can be expected to have >> AllPermission (even when url is null). That issue - of only giving minimal >> permissions to null url scripts - has been fixed in update release. It'll >> appear in an 8 update release. For the interim, please use jjs for this >> case. Note that specific URL permission should work now as expected. >> >> PS. BTW, AFAIK, jrunscript in jdk7 uses Rhino and does not work with >> security manager enabled. Are you sure it worked for you? you may want to >> double check. >> >> Hope this helps, >> -Sundar >> >> >> On Wednesday 09 April 2014 08:53 PM, Youri Bonnaff? wrote: >> >>> Hi, >>> >>> I'm trying to run this very sample JS file: >>> >>> println(java.lang.System.getProperty("os.name")) >>> >>> using jrunscript. >>> >>> $> jrunscript test.js >>> Linux >>> >>> Now when I set a Security Manager: >>> >>> $> jrunscript -J-Djava.security.manager test.js >>> Exception in thread "main" java.security.AccessControlException: access >>> denied ("java.io.FilePermission" "test.js" "read") >>> at >>> java.security.AccessControlContext.checkPermission( >>> AccessControlContext.java:457) >>> at java.security.AccessController.checkPermission( >>> AccessController.java:884) >>> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) >>> at java.lang.SecurityManager.checkRead(SecurityManager.java:888) >>> at java.io.FileInputStream.(FileInputStream.java:121) >>> at java.io.FileInputStream.(FileInputStream.java:87) >>> at com.sun.tools.script.shell.Main.processSource(Main.java:279) >>> at com.sun.tools.script.shell.Main.access$100(Main.java:37) >>> at com.sun.tools.script.shell.Main$2.run(Main.java:200) >>> at com.sun.tools.script.shell.Main.main(Main.java:48) >>> >>> which is expected. >>> >>> Now when I set a custom policy such as: >>> >>> grant { >>> permission java.security.AllPermission; >>> }; >>> >>> $> jrunscript -J-Djava.security.manager >>> -J-Djava.security.policy=test.policy test.js >>> java.security.AccessControlException: access denied >>> ("java.util.PropertyPermission" "os.name" "read") >>> at >>> java.security.AccessControlContext.checkPermission( >>> AccessControlContext.java:457) >>> at java.security.AccessController.checkPermission( >>> AccessController.java:884) >>> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) >>> at java.lang.SecurityManager.checkPropertyAccess( >>> SecurityManager.java:1294) >>> at java.lang.System.getProperty(System.java:714) >>> at jdk.nashorn.internal.scripts.Script$test.runScript(test.js:1) >>> at >>> jdk.nashorn.internal.runtime.ScriptFunctionData.invoke( >>> ScriptFunctionData.java:498) >>> at >>> jdk.nashorn.internal.runtime.ScriptFunction.invoke( >>> ScriptFunction.java:206) >>> at jdk.nashorn.internal.runtime.ScriptRuntime.apply( >>> ScriptRuntime.java:378) >>> at >>> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl( >>> NashornScriptEngine.java:546) >>> at >>> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl( >>> NashornScriptEngine.java:528) >>> at >>> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl( >>> NashornScriptEngine.java:524) >>> at >>> jdk.nashorn.api.scripting.NashornScriptEngine.eval( >>> NashornScriptEngine.java:189) >>> at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:249) >>> at com.sun.tools.script.shell.Main.evaluateReader(Main.java:332) >>> at com.sun.tools.script.shell.Main.evaluateStream(Main.java:368) >>> at com.sun.tools.script.shell.Main.processSource(Main.java:285) >>> at com.sun.tools.script.shell.Main.access$100(Main.java:37) >>> at com.sun.tools.script.shell.Main$2.run(Main.java:200) >>> at com.sun.tools.script.shell.Main.main(Main.java:48) >>> >>> This happens only with a JDK8/Nashorn, if I do the same with JDK7, the >>> last >>> command will succeed. I failed to find information elsewhere so that's why >>> I asking for help here. Do you understand what might happen? And what >>> changed around security manager with JDK8/Nashorn? >>> >>> Thanks, >>> >>> Youri >>> >> From youribm at gmail.com Thu Apr 10 10:20:38 2014 From: youribm at gmail.com (=?ISO-8859-1?Q?Youri_Bonnaff=E9?=) Date: Thu, 10 Apr 2014 12:20:38 +0200 Subject: Nashorn, Security manager and custom policy In-Reply-To: <534666F0.3020503@oracle.com> References: <53456E17.3010805@oracle.com> <534666F0.3020503@oracle.com> Message-ID: >From my tests above and my understanding of Java security it seems that the security manager with jrunscript and JDK7 works (the file permission on "foo" is taken into account). On 10 April 2014 11:40, A. Sundararajan < sundararajan.athijegannathan at oracle.com> wrote: > As I said earlier, with jdk7 jrunscript + security manager mode never > worked - which is what you confirmed. jrunscript's initial script "init.js" > itself throws security exception - i.e., you may have to give lot more > permissions as you found out. > > As for particular release in which nashorn's fix for null URL will make it > in, I can't say for sure - most likely 8u20. Please watch out jdk8u-dev > alias and/or release notes of jdk8 update releases. > > Thanks > -Sundar > > > On Thursday 10 April 2014 01:57 PM, Youri Bonnaff? wrote: > >> Thanks for you answer. >> >> Unfortunately our use case uses the ScriptEngine from Java code to run JS >> scripts (I was using jrunscript here for testing purpose), so jjs is not >> an >> option for us. >> >> I double checked with JDK7: >> >> $> jrunscript -J-Djava.security.manager test.js >> script error in file : >> sun.org.mozilla.javascript.internal.WrappedException: Wrapped >> java.security.AccessControlException: access denied >> ("java.util.PropertyPermission" "*" "read,write") (#194) in >> at line number 194 >> >> It seems the security manager is enabled but raises an exception even >> before the script is executed. I tested something else. Here is the policy >> used: >> >> *grant {* >> * permission java.io.FilePermission "test.js", "read";* >> * permission java.io.FilePermission "foo", "read";* >> * permission java.util.PropertyPermission "*", "read,write";* >> *};* >> >> and the script: >> >> *println(java.lang.System.getProperty("os.name "))* >> *new java.io.File("titi").exists()* >> >> if I run >> >> >> *$> jrunscript -J-Djava.security.manager >> -J-Djava.security.policy=test.policy test.js* >> >> >> it works. Now if I comment out the line with the file permission on "foo", >> it will produce: >> >> *$> jrunscript -J-Djava.security.manager >> -J-Djava.security.policy=test.policy test.js* >> *Linux* >> *script error in file test.js : >> >> sun.org.mozilla.javascript.internal.WrappedException: Wrapped >> java.security.AccessControlException: access denied >> ("java.io.FilePermission" "foo" "read") (test.js#2) in test.js at line >> number 2* >> >> >> It seems that the security manager is taken into account. It it quite an >> issue for us as we run our application with security manager enabled and >> allow JS scripts to be executed through the ScriptEngine. The scripts can >> be String or Reader and they can be provided by the end user (so setting >> codeBase values is not an option). >> Do you have any idea on when the fix will be released? >> >> Thanks, >> >> Youri, >> >> >> On 9 April 2014 17:58, A. Sundararajan < >> sundararajan.athijegannathan at oracle.com> wrote: >> >> Hi, >>> >>> There are two shell tools in JDK8. "jjs", "jrunscript". >>> >>> jjs uses direct Nashorn (internal) classes and associates script URL to >>> source files (and therefore permission etc.) Your example works fine with >>> jjs with println replaced as "print". >>> >>> jjs -J-Djava.security.manager -J-Djava.security.policy=test.policy >>> test.js >>> >>> is fine. Prints OS name with the modified policy and throws security >>> exception without that policy. >>> >>> jrunscript uses javax.script API and evaluates scripts by >>> ScriptEngine.eval methods (passing "string" code or Reader made out of >>> test.js). javax.script API has no way to associate a source URL to a >>> script >>> (either String or Reader). So, "test.js" is loaded as script without >>> "origin" (i.e., origin unknown). Such scripts are given only minimal >>> permissions (url being null). But, then your policy gives AllPermission >>> to >>> any code regardless code origin and so it can be expected to have >>> AllPermission (even when url is null). That issue - of only giving >>> minimal >>> permissions to null url scripts - has been fixed in update release. It'll >>> appear in an 8 update release. For the interim, please use jjs for this >>> case. Note that specific URL permission should work now as expected. >>> >>> PS. BTW, AFAIK, jrunscript in jdk7 uses Rhino and does not work with >>> security manager enabled. Are you sure it worked for you? you may want to >>> double check. >>> >>> Hope this helps, >>> -Sundar >>> >>> >>> On Wednesday 09 April 2014 08:53 PM, Youri Bonnaff? wrote: >>> >>> Hi, >>>> >>>> I'm trying to run this very sample JS file: >>>> >>>> println(java.lang.System.getProperty("os.name")) >>>> >>>> using jrunscript. >>>> >>>> $> jrunscript test.js >>>> Linux >>>> >>>> Now when I set a Security Manager: >>>> >>>> $> jrunscript -J-Djava.security.manager test.js >>>> Exception in thread "main" java.security.AccessControlException: access >>>> denied ("java.io.FilePermission" "test.js" "read") >>>> at >>>> java.security.AccessControlContext.checkPermission( >>>> AccessControlContext.java:457) >>>> at java.security.AccessController.checkPermission( >>>> AccessController.java:884) >>>> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) >>>> at java.lang.SecurityManager.checkRead(SecurityManager.java:888) >>>> at java.io.FileInputStream.(FileInputStream.java:121) >>>> at java.io.FileInputStream.(FileInputStream.java:87) >>>> at com.sun.tools.script.shell.Main.processSource(Main.java:279) >>>> at com.sun.tools.script.shell.Main.access$100(Main.java:37) >>>> at com.sun.tools.script.shell.Main$2.run(Main.java:200) >>>> at com.sun.tools.script.shell.Main.main(Main.java:48) >>>> >>>> which is expected. >>>> >>>> Now when I set a custom policy such as: >>>> >>>> grant { >>>> permission java.security.AllPermission; >>>> }; >>>> >>>> $> jrunscript -J-Djava.security.manager >>>> -J-Djava.security.policy=test.policy test.js >>>> java.security.AccessControlException: access denied >>>> ("java.util.PropertyPermission" "os.name" "read") >>>> at >>>> java.security.AccessControlContext.checkPermission( >>>> AccessControlContext.java:457) >>>> at java.security.AccessController.checkPermission( >>>> AccessController.java:884) >>>> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) >>>> at java.lang.SecurityManager.checkPropertyAccess( >>>> >>>> SecurityManager.java:1294) >>>> at java.lang.System.getProperty(System.java:714) >>>> at jdk.nashorn.internal.scripts.Script$test.runScript(test.js:1) >>>> at >>>> jdk.nashorn.internal.runtime.ScriptFunctionData.invoke( >>>> ScriptFunctionData.java:498) >>>> at >>>> jdk.nashorn.internal.runtime.ScriptFunction.invoke( >>>> ScriptFunction.java:206) >>>> at jdk.nashorn.internal.runtime.ScriptRuntime.apply( >>>> ScriptRuntime.java:378) >>>> at >>>> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl( >>>> NashornScriptEngine.java:546) >>>> at >>>> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl( >>>> NashornScriptEngine.java:528) >>>> at >>>> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl( >>>> NashornScriptEngine.java:524) >>>> at >>>> jdk.nashorn.api.scripting.NashornScriptEngine.eval( >>>> NashornScriptEngine.java:189) >>>> at javax.script.AbstractScriptEngine.eval( >>>> AbstractScriptEngine.java:249) >>>> at com.sun.tools.script.shell.Main.evaluateReader(Main.java:332) >>>> at com.sun.tools.script.shell.Main.evaluateStream(Main.java:368) >>>> at com.sun.tools.script.shell.Main.processSource(Main.java:285) >>>> at com.sun.tools.script.shell.Main.access$100(Main.java:37) >>>> at com.sun.tools.script.shell.Main$2.run(Main.java:200) >>>> at com.sun.tools.script.shell.Main.main(Main.java:48) >>>> >>>> This happens only with a JDK8/Nashorn, if I do the same with JDK7, the >>>> last >>>> command will succeed. I failed to find information elsewhere so that's >>>> why >>>> I asking for help here. Do you understand what might happen? And what >>>> changed around security manager with JDK8/Nashorn? >>>> >>>> Thanks, >>>> >>>> Youri >>>> >>>> >>> > From attila.szegedi at oracle.com Fri Apr 11 14:37:18 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 11 Apr 2014 16:37:18 +0200 Subject: Review request for JDK-8040024 Message-ID: Please review at Thanks, Attila. From attila.szegedi at oracle.com Fri Apr 11 14:40:09 2014 From: attila.szegedi at oracle.com (attila.szegedi at oracle.com) Date: Fri, 11 Apr 2014 14:40:09 +0000 Subject: hg: nashorn/jdk9/nashorn: 8040024: BranchOptimizer produces bad code for NaN FP comparison Message-ID: <201404111440.s3BEeAmn024461@aojmv0008> Changeset: f47393d4559b Author: attila Date: 2014-04-11 16:40 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/f47393d4559b 8040024: BranchOptimizer produces bad code for NaN FP comparison Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java + test/script/basic/JDK-8040024.js + test/script/basic/JDK-8040024.js.EXPECTED From james.laskey at oracle.com Fri Apr 11 14:42:39 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 11 Apr 2014 11:42:39 -0300 Subject: Review request for JDK-8040024 In-Reply-To: References: Message-ID: +1 On Apr 11, 2014, at 11:37 AM, Attila Szegedi wrote: > Please review at > > Thanks, > Attila. From marcus.lagergren at oracle.com Fri Apr 11 14:53:28 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Fri, 11 Apr 2014 14:53:28 +0000 Subject: hg: nashorn/jdk9/nashorn: 2 new changesets Message-ID: <201404111453.s3BErUkq026724@aojmv0008> Changeset: ddda121eca56 Author: lagergren Date: 2014-04-11 16:52 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/ddda121eca56 8039746: Transform applies to calls wherever possible, for ScriptFunctions and JSObjects. Reviewed-by: hannesw, attila, sundar, jlaskey ! src/jdk/internal/dynalink/linker/GuardedInvocation.java + src/jdk/nashorn/internal/codegen/ApplySpecialization.java ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationEnvironment.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/ObjectCreator.java ! src/jdk/nashorn/internal/codegen/SpillObjectCreator.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/Flags.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/CompiledFunction.java ! src/jdk/nashorn/internal/runtime/CompiledFunctions.java ! src/jdk/nashorn/internal/runtime/GlobalConstants.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java ! src/jdk/nashorn/internal/runtime/arrays/ContinuousArrayData.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + test/examples/apply_to_call_benchmark.js ! test/script/basic/JDK-8016618.js ! test/script/basic/JDK-8016618.js.EXPECTED + test/script/basic/apply_to_call/apply_to_call1.js + test/script/basic/apply_to_call/apply_to_call1.js.EXPECTED + test/script/basic/apply_to_call/apply_to_call2.js + test/script/basic/apply_to_call/apply_to_call2.js.EXPECTED + test/script/basic/apply_to_call/apply_to_call3.js + test/script/basic/apply_to_call/apply_to_call3.js.EXPECTED + test/script/basic/apply_to_call/apply_to_call4.js + test/script/basic/apply_to_call/apply_to_call4.js.EXPECTED + test/script/basic/apply_to_call/apply_to_call_bench.js + test/script/basic/apply_to_call/apply_to_call_bench.js.EXPECTED ! test/src/jdk/nashorn/api/scripting/ScriptEngineSecurityTest.java ! test/src/jdk/nashorn/internal/runtime/TrustedScriptEngineTest.java Changeset: 636c6e455269 Author: lagergren Date: 2014-04-11 16:52 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/636c6e455269 Merge From marcus.lagergren at oracle.com Sun Apr 13 21:07:04 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Sun, 13 Apr 2014 23:07:04 +0200 Subject: Review request for JDK-8040024 In-Reply-To: References: Message-ID: <8E0C64E0-5B1A-483C-B394-E5AE602E31EF@oracle.com> +1 On 11 Apr 2014, at 16:37, Attila Szegedi wrote: > Please review at > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Mon Apr 14 14:53:59 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 14 Apr 2014 16:53:59 +0200 Subject: Review requests for JDK-8030199, JDK-8030200 Message-ID: <534BF687.3030002@oracle.com> Please review the following patches: JDK-8030199: Nashorn: Uint8ClampedArray - Incorrect ToUint8Clamp implementation http://cr.openjdk.java.net/~hannesw/8030199/ JDK-8030200: Wrong result for Number.prototype.toString() for certain radix/inputs http://cr.openjdk.java.net/~hannesw/8030200/ Thanks, Hannes From sundararajan.athijegannathan at oracle.com Mon Apr 14 14:56:49 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 14 Apr 2014 20:26:49 +0530 Subject: Review requests for JDK-8030199, JDK-8030200 In-Reply-To: <534BF687.3030002@oracle.com> References: <534BF687.3030002@oracle.com> Message-ID: <534BF731.1080208@oracle.com> +1 -Sundar On Monday 14 April 2014 08:23 PM, Hannes Wallnoefer wrote: > Please review the following patches: > > JDK-8030199: Nashorn: Uint8ClampedArray - Incorrect ToUint8Clamp > implementation > http://cr.openjdk.java.net/~hannesw/8030199/ > > JDK-8030200: Wrong result for Number.prototype.toString() for certain > radix/inputs > http://cr.openjdk.java.net/~hannesw/8030200/ > > Thanks, > Hannes From hrjet9 at gmail.com Wed Apr 16 18:33:20 2014 From: hrjet9 at gmail.com (HRJet) Date: Thu, 17 Apr 2014 00:03:20 +0530 Subject: Monkey patching a Java class? Message-ID: Is it possible to monkey patch a Java class for use within Javascript? For example, I want to add a convenience method to java.io.File class, say "readAsString()". Then, in javascript I want to call file.readAsString() where file is an instance of java.io.File. Note that the file instance may be created by some third-party code, over which I have no control. In Java land, this seems to be usually done with CGLib or AspectJ, etc. I was wondering if nashorn had some trick up its sleeve for doing this in script land, since this sort of thing is common in Javascript. thanks, HRJ From marcus.lagergren at oracle.com Thu Apr 17 18:15:10 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Thu, 17 Apr 2014 18:15:10 +0000 Subject: hg: nashorn/jdk9/nashorn: 8040089: Apply to call transform was incomplete. Now passes all tests and performance is back Message-ID: <201404171815.s3HIFBnx020425@aojmv0008> Changeset: 8423d57c70de Author: lagergren Date: 2014-04-17 20:01 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/8423d57c70de 8040089: Apply to call transform was incomplete. Now passes all tests and performance is back Reviewed-by: hannesw, attila, sundar, jlaskey ! bin/fixwhitespace.sh ! bin/runoptdualcatch.sh ! src/jdk/nashorn/internal/codegen/ApplySpecialization.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/ParamTypeMap.java ! src/jdk/nashorn/internal/codegen/ProgramPoints.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/runtime/CompiledFunction.java ! src/jdk/nashorn/internal/runtime/CompiledFunctions.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! test/script/basic/apply_to_call/apply_to_call1.js ! test/script/basic/apply_to_call/apply_to_call2.js ! test/script/basic/apply_to_call/apply_to_call3.js ! test/script/basic/apply_to_call/apply_to_call4.js ! test/script/basic/apply_to_call/apply_to_call_bench.js + test/script/basic/apply_to_call/apply_to_call_recompile.js + test/script/basic/apply_to_call/apply_to_call_recompile.js.EXPECTED + test/script/basic/apply_to_call/apply_to_call_varargs.js + test/script/basic/apply_to_call/apply_to_call_varargs.js.EXPECTED ! test/script/basic/run-octane.js From dev at remibarraquand.com Fri Apr 18 08:24:53 2014 From: dev at remibarraquand.com (=?ISO-8859-1?Q?R=E9mi_Barraquand?=) Date: Fri, 18 Apr 2014 10:24:53 +0200 Subject: Nashorn integration with third party libraries Message-ID: <5350E155.5000409@remibarraquand.com> Hi all, I might not be the first person to ask such question but I didn't found that much information regarding my issue on the official Nashorn page. *Context*: In an open-source project I'm working on, I'm using JavaFx WebView to develop a client application written mostly in JavaScript (RequireJS, Backbone, JQuery, Handlebars, etc). The application is running perfectly. I nevertheless want to add a Command-Line Interface (CLI) to let users interact with the application (in my case access a compiler written in JS) from their terminal without having to open a windowed interface (GUI). I therefore want to execute some JS code without the use of the JavaFx WebView. As a result I'm trying to make use of Nashorn! *Problem*: The code I'm trying to execute in the Nashorn script engine is using third party libraries such as Backbone Models and JQuery for the generation and manipulation of HTML (I do not need to render anything, just to generate HTML). I therefore tried to load JQuery library within Nashorn but I got a strange error... The code: |> ScriptEngine engine = manager.getEngineByName("nashorn"); > engine.eval(new InputStreamReader(CLI.class.getResourceAsStream("/io/dahuapp/core/scripts/jquery.js"))); | The error: |--- ERROR --- Exception in thread "main" javax.script.ScriptException: TypeError: Cannot read property "defaultView" from undefined in at line number 1010 at jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException(NashornScriptEngine.java:564) at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:548) at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:528) at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:524) at jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:189) at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:249) at io.dahuapp.cli.CLI.main(CLI.java:45) Caused by::1010 TypeError: Cannot read property "defaultView" from undefined at jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:56) at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:212) at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:184) at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:171) at jdk.nashorn.internal.runtime.Undefined.lookupTypeError(Undefined.java:128) at jdk.nashorn.internal.runtime.Undefined.lookup(Undefined.java:113) at jdk.nashorn.internal.runtime.linker.NashornLinker.getGuardedInvocation(NashornLinker.java:98) at jdk.internal.dynalink.support.CompositeTypeBasedGuardingDynamicLinker.getGuardedInvocation(CompositeTypeBasedGuardingDynamicLinker.java:176) at jdk.internal.dynalink.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:124) at jdk.internal.dynalink.support.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:144) at jdk.internal.dynalink.DynamicLinker.relink(DynamicLinker.java:232) at jdk.nashorn.internal.scripts.Script$\^eval\_$4._L38$_L563$_L1007(:1010) at jdk.nashorn.internal.scripts.Script$\^eval\_$4.scopeCall-14() at jdk.nashorn.internal.scripts.Script$\^eval\_$4._L38$_L563(:2503) at jdk.nashorn.internal.scripts.Script$\^eval\_$2.$split(:563) at jdk.nashorn.internal.scripts.Script$\^eval\_._L38() at jdk.nashorn.internal.scripts.Script$\^eval\_._L15(:34) at jdk.nashorn.internal.scripts.Script$\^eval\_.runScript(:15) at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:498) at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:206) at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:378) at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:546) ... 5 more --- END ERROR --- | I tracked the error down in the JQuery code and the error is coming from the block: |setDocument = Sizzle.setDocument = function( node ) { var hasCompare, doc = node ? node.ownerDocument || node : preferredDoc, **parent = doc.defaultView;** // *ERROR* // If no document and documentElement is available, return if ( doc === document || doc.nodeType !== 9 || !doc.documentElement ) { return document; } .... | *Question*: 1. is it possible to load any third party library within Nashorn ? 2. does someone tried to load JQuery inside Nashorn ? 3. does someone have an idea from where this error might come from? Thanks, R?mi -- R?mi Barraquand, Phd VP of Engineering at Carnot-LSI http://remibarraquand.com From ekemokai at gmail.com Fri Apr 18 10:24:19 2014 From: ekemokai at gmail.com (Edmond Kemokai) Date: Fri, 18 Apr 2014 06:24:19 -0400 Subject: Nashorn integration with third party libraries In-Reply-To: <5350E155.5000409@remibarraquand.com> References: <5350E155.5000409@remibarraquand.com> Message-ID: I don't see how what you are trying to do could work. You are executing the jquery script in a context that lacks the key variables such as document which jquery relies on. JQuery is for DOM manipulation primarily, as your error source indicates, there's no document for jquery to act on. On Fri, Apr 18, 2014 at 4:24 AM, R?mi Barraquand wrote: > Hi all, > > I might not be the first person to ask such question but I didn't found > that much information regarding my issue on the official Nashorn page. > > *Context*: In an open-source project I'm working on, I'm using JavaFx > WebView to develop a client application written mostly in JavaScript > (RequireJS, Backbone, JQuery, Handlebars, etc). The application is running > perfectly. I nevertheless want to add a Command-Line Interface (CLI) to let > users interact with the application (in my case access a compiler written > in JS) from their terminal without having to open a windowed interface > (GUI). I therefore want to execute some JS code without the use of the > JavaFx WebView. As a result I'm trying to make use of Nashorn! > > *Problem*: The code I'm trying to execute in the Nashorn script engine is > using third party libraries such as Backbone Models and JQuery for the > generation and manipulation of HTML (I do not need to render anything, just > to generate HTML). I therefore tried to load JQuery library within Nashorn > but I got a strange error... > > The code: > > |> ScriptEngine engine = manager.getEngineByName("nashorn"); > >> engine.eval(new InputStreamReader(CLI.class.getResourceAsStream("/io/ >> dahuapp/core/scripts/jquery.js"))); >> > | > > The error: > > |--- ERROR --- > Exception in thread "main" javax.script.ScriptException: TypeError: > Cannot read property "defaultView" from undefined in at line number > 1010 > at jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException( > NashornScriptEngine.java:564) > at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl( > NashornScriptEngine.java:548) > at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl( > NashornScriptEngine.java:528) > at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl( > NashornScriptEngine.java:524) > at jdk.nashorn.api.scripting.NashornScriptEngine.eval( > NashornScriptEngine.java:189) > at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:249) > at io.dahuapp.cli.CLI.main(CLI.java:45) > Caused by::1010 TypeError: Cannot read property "defaultView" from > undefined > at jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:56) > at jdk.nashorn.internal.runtime.ECMAErrors.typeError( > ECMAErrors.java:212) > at jdk.nashorn.internal.runtime.ECMAErrors.typeError( > ECMAErrors.java:184) > at jdk.nashorn.internal.runtime.ECMAErrors.typeError( > ECMAErrors.java:171) > at jdk.nashorn.internal.runtime.Undefined.lookupTypeError( > Undefined.java:128) > at jdk.nashorn.internal.runtime.Undefined.lookup(Undefined.java:113) > at jdk.nashorn.internal.runtime.linker.NashornLinker. > getGuardedInvocation(NashornLinker.java:98) > at jdk.internal.dynalink.support.CompositeTypeBasedGuardingDyna > micLinker.getGuardedInvocation(CompositeTypeBasedGuardingDyna > micLinker.java:176) > at jdk.internal.dynalink.support.CompositeGuardingDynamicLinker > .getGuardedInvocation(CompositeGuardingDynamicLinker.java:124) > at jdk.internal.dynalink.support.LinkerServicesImpl. > getGuardedInvocation(LinkerServicesImpl.java:144) > at jdk.internal.dynalink.DynamicLinker.relink(DynamicLinker.java:232) > at jdk.nashorn.internal.scripts.Script$\^eval\_$4._L38$_L563$_ > L1007(:1010) > at jdk.nashorn.internal.scripts.Script$\^eval\_$4.scopeCall- > 14() > at jdk.nashorn.internal.scripts.Script$\^eval\_$4._L38$_L563(< > eval>:2503) > at jdk.nashorn.internal.scripts.Script$\^eval\_$2.$split(< > eval>:563) > at jdk.nashorn.internal.scripts. > Script$\^eval\_._L38() > at jdk.nashorn.internal.scripts. > Script$\^eval\_._L15(:34) > at jdk.nashorn.internal.scripts. > Script$\^eval\_.runScript(:15) > at jdk.nashorn.internal.runtime. > ScriptFunctionData.invoke(ScriptFunctionData.java:498) > at jdk.nashorn.internal.runtime. > ScriptFunction.invoke(ScriptFunction.java:206) > at jdk.nashorn.internal.runtime. > ScriptRuntime.apply(ScriptRuntime.java:378) > at jdk.nashorn.api.scripting. > NashornScriptEngine.evalImpl(NashornScriptEngine.java:546) > ... 5 more > --- END ERROR --- > | > > I tracked the error down in the JQuery code and the error is coming from > the block: > > |setDocument = Sizzle.setDocument = function( node ) { > var hasCompare, > doc = node ? node.ownerDocument || node : preferredDoc, > **parent = doc.defaultView;** // *ERROR* > > // If no document and documentElement is available, return > if ( doc === document || doc.nodeType !== 9 || !doc.documentElement ) { > return document; > } > > .... > | > > *Question*: > > 1. is it possible to load any third party library within Nashorn ? > 2. does someone tried to load JQuery inside Nashorn ? > 3. does someone have an idea from where this error might come from? > > Thanks, > R?mi > > -- > R?mi Barraquand, Phd > VP of Engineering at Carnot-LSI > http://remibarraquand.com > > > -- ?talk trash and carry a small stick.? PAUL KRUGMAN (NYT) "I believe god invented man, because he was disappointed in the monkey" Mark Twain "Beware of geeks bearing formulas" Warren Buffett From hrjet9 at gmail.com Fri Apr 18 10:33:20 2014 From: hrjet9 at gmail.com (HRJet) Date: Fri, 18 Apr 2014 16:03:20 +0530 Subject: Nashorn integration with third party libraries In-Reply-To: References: <5350E155.5000409@remibarraquand.com> Message-ID: ?@R?mi Adding to what Edmond said, you can't even use ? ?the org.w3c.dom.* Java classes with ? ?jQuery, because jQuery assumes certain properties which are not available in w3c DOM but are standard in browsers, such as the property `innerHTML`. These are part of Living Standards by WhatWG group. @all Since Nashorn is intended to be used on server side, are there official plans for a w3c + WhatWG compliant DOM model in Java? There are some third party libraries which try this, but an official library would be nice. From james.laskey at oracle.com Fri Apr 18 10:50:18 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 18 Apr 2014 07:50:18 -0300 Subject: DOM (Was: Nashorn integration with third party libraries) In-Reply-To: References: <5350E155.5000409@remibarraquand.com> Message-ID: R?mi, Edmond and RJ are correct. Your script is failing because of the lack of DOM (DOM is a browser library), otherwise yes Nashorn supports 3rd party Javascript (and Java.) All, I've been looking for members of the community to implement Nashorn/DOM so that people can use existing browser libraries on top of JavaFX. With JavaFX, rendering performance would figuratively smoke existing browsers. The effort would involve taking a library like env.js and adding the guts. I can help coordinate the activity, but I don't have the cycles to do the work myself. Cheers, - Jim On Apr 18, 2014, at 7:24 AM, Edmond Kemokai wrote: > I don't see how what you are trying to do could work. You are executing the > jquery script in a context that lacks the key variables such as document > which jquery relies on. JQuery is for DOM manipulation primarily, as your > error source indicates, there's no document for jquery to act on. > > > > > On Fri, Apr 18, 2014 at 4:24 AM, R?mi Barraquand wrote: > >> Hi all, >> >> I might not be the first person to ask such question but I didn't found >> that much information regarding my issue on the official Nashorn page. >> >> *Context*: In an open-source project I'm working on, I'm using JavaFx >> WebView to develop a client application written mostly in JavaScript >> (RequireJS, Backbone, JQuery, Handlebars, etc). The application is running >> perfectly. I nevertheless want to add a Command-Line Interface (CLI) to let >> users interact with the application (in my case access a compiler written >> in JS) from their terminal without having to open a windowed interface >> (GUI). I therefore want to execute some JS code without the use of the >> JavaFx WebView. As a result I'm trying to make use of Nashorn! >> >> *Problem*: The code I'm trying to execute in the Nashorn script engine is >> using third party libraries such as Backbone Models and JQuery for the >> generation and manipulation of HTML (I do not need to render anything, just >> to generate HTML). I therefore tried to load JQuery library within Nashorn >> but I got a strange error... >> >> The code: >> >> |> ScriptEngine engine = manager.getEngineByName("nashorn"); >> >>> engine.eval(new InputStreamReader(CLI.class.getResourceAsStream("/io/ >>> dahuapp/core/scripts/jquery.js"))); >>> >> | >> >> The error: >> >> |--- ERROR --- >> Exception in thread "main" javax.script.ScriptException: TypeError: >> Cannot read property "defaultView" from undefined in at line number >> 1010 >> at jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException( >> NashornScriptEngine.java:564) >> at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl( >> NashornScriptEngine.java:548) >> at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl( >> NashornScriptEngine.java:528) >> at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl( >> NashornScriptEngine.java:524) >> at jdk.nashorn.api.scripting.NashornScriptEngine.eval( >> NashornScriptEngine.java:189) >> at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:249) >> at io.dahuapp.cli.CLI.main(CLI.java:45) >> Caused by::1010 TypeError: Cannot read property "defaultView" from >> undefined >> at jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:56) >> at jdk.nashorn.internal.runtime.ECMAErrors.typeError( >> ECMAErrors.java:212) >> at jdk.nashorn.internal.runtime.ECMAErrors.typeError( >> ECMAErrors.java:184) >> at jdk.nashorn.internal.runtime.ECMAErrors.typeError( >> ECMAErrors.java:171) >> at jdk.nashorn.internal.runtime.Undefined.lookupTypeError( >> Undefined.java:128) >> at jdk.nashorn.internal.runtime.Undefined.lookup(Undefined.java:113) >> at jdk.nashorn.internal.runtime.linker.NashornLinker. >> getGuardedInvocation(NashornLinker.java:98) >> at jdk.internal.dynalink.support.CompositeTypeBasedGuardingDyna >> micLinker.getGuardedInvocation(CompositeTypeBasedGuardingDyna >> micLinker.java:176) >> at jdk.internal.dynalink.support.CompositeGuardingDynamicLinker >> .getGuardedInvocation(CompositeGuardingDynamicLinker.java:124) >> at jdk.internal.dynalink.support.LinkerServicesImpl. >> getGuardedInvocation(LinkerServicesImpl.java:144) >> at jdk.internal.dynalink.DynamicLinker.relink(DynamicLinker.java:232) >> at jdk.nashorn.internal.scripts.Script$\^eval\_$4._L38$_L563$_ >> L1007(:1010) >> at jdk.nashorn.internal.scripts.Script$\^eval\_$4.scopeCall- >> 14() >> at jdk.nashorn.internal.scripts.Script$\^eval\_$4._L38$_L563(< >> eval>:2503) >> at jdk.nashorn.internal.scripts.Script$\^eval\_$2.$split(< >> eval>:563) >> at jdk.nashorn.internal.scripts. >> Script$\^eval\_._L38() >> at jdk.nashorn.internal.scripts. >> Script$\^eval\_._L15(:34) >> at jdk.nashorn.internal.scripts. >> Script$\^eval\_.runScript(:15) >> at jdk.nashorn.internal.runtime. >> ScriptFunctionData.invoke(ScriptFunctionData.java:498) >> at jdk.nashorn.internal.runtime. >> ScriptFunction.invoke(ScriptFunction.java:206) >> at jdk.nashorn.internal.runtime. >> ScriptRuntime.apply(ScriptRuntime.java:378) >> at jdk.nashorn.api.scripting. >> NashornScriptEngine.evalImpl(NashornScriptEngine.java:546) >> ... 5 more >> --- END ERROR --- >> | >> >> I tracked the error down in the JQuery code and the error is coming from >> the block: >> >> |setDocument = Sizzle.setDocument = function( node ) { >> var hasCompare, >> doc = node ? node.ownerDocument || node : preferredDoc, >> **parent = doc.defaultView;** // *ERROR* >> >> // If no document and documentElement is available, return >> if ( doc === document || doc.nodeType !== 9 || !doc.documentElement ) { >> return document; >> } >> >> .... >> | >> >> *Question*: >> >> 1. is it possible to load any third party library within Nashorn ? >> 2. does someone tried to load JQuery inside Nashorn ? >> 3. does someone have an idea from where this error might come from? >> >> Thanks, >> R?mi >> >> -- >> R?mi Barraquand, Phd >> VP of Engineering at Carnot-LSI >> http://remibarraquand.com >> >> >> > > > -- > ?talk trash and carry a small stick.? > PAUL KRUGMAN (NYT) > > "I believe god invented man, because he was disappointed in the monkey" > Mark Twain > > "Beware of geeks bearing formulas" > Warren Buffett From hrjet9 at gmail.com Fri Apr 18 11:47:39 2014 From: hrjet9 at gmail.com (HRJet) Date: Fri, 18 Apr 2014 17:17:39 +0530 Subject: DOM (Was: Nashorn integration with third party libraries) In-Reply-To: References: <5350E155.5000409@remibarraquand.com> Message-ID: Hi Jim, Count me very interested. On Fri, Apr 18, 2014 at 4:20 PM, Jim Laskey (Oracle) < james.laskey at oracle.com> wrote: > R?mi, > > Edmond and RJ are correct. Your script is failing because of the lack of > DOM (DOM is a browser library), otherwise yes Nashorn supports 3rd party > Javascript (and Java.) > > All, > > I've been looking for members of the community to implement Nashorn/DOM so > that people can use existing browser libraries on top of JavaFX. With > JavaFX, rendering performance would figuratively smoke existing browsers. > The effort would involve taking a library like env.js and adding the guts. > I can help coordinate the activity, but I don't have the cycles to do the > work myself. > > From dev at remibarraquand.com Fri Apr 18 12:05:44 2014 From: dev at remibarraquand.com (=?UTF-8?B?UsOpbWkgQmFycmFxdWFuZA==?=) Date: Fri, 18 Apr 2014 14:05:44 +0200 Subject: Nashorn integration with third party libraries In-Reply-To: References: <5350E155.5000409@remibarraquand.com> Message-ID: <53511518.9070605@remibarraquand.com> Hi all, > I don't see how what you are trying to do could work. You are > executing the jquery script in a context that lacks the key variables > such as document which jquery relies on. JQuery is for DOM > manipulation primarily, as your error source indicates, there's no > document for jquery to act on. Indeed that's so obvious :) Why I didn't think of that :/ Since my aim is to easily create an manipulate HTML document not attached to the DOM, I should rather turn turn toward ReactJS which uses VirtualDOM or templating engine such as Handlebars. @edmond thanks for pointing that out anyway :) @jim i'm also interested :) From marcus.lagergren at oracle.com Fri Apr 18 18:22:21 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Fri, 18 Apr 2014 18:22:21 +0000 Subject: hg: nashorn/jdk9/nashorn: 8040102: Remove all references to Unsafe and definition of anonymous clases from the code Message-ID: <201404181822.s3IIML9j028414@aojmv0008> Changeset: 82dc816bf225 Author: lagergren Date: 2014-04-18 20:12 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/82dc816bf225 8040102: Remove all references to Unsafe and definition of anonymous clases from the code Summary: As the catch combinator optimization is now part of java.lang.invoke we don't need to put our own in the boot class path in any configuration anymore. Furthermore, with the completion of the array performance subtask of optimistic typing, we can remove the experimental (commented out) Unsafe accessors in the ArrayData classes Reviewed-by: attila, jlaskey - bin/checkintest.sh - bin/fastCatchCombinator.jar ! bin/runopt.sh < bin/runoptdualcatch.sh + bin/runopt_noassert.sh + bin/runopt_nojfr.sh - bin/runoptdualcatch9.sh ! src/jdk/internal/dynalink/linker/GuardedInvocation.java - src/jdk/internal/dynalink/support/CatchExceptionCombinator.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/runtime/CompiledFunction.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java From marcus.lagergren at oracle.com Fri Apr 18 19:32:16 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Fri, 18 Apr 2014 19:32:16 +0000 Subject: hg: nashorn/jdk9/nashorn: 8040655: When processing a RewriteException debug object, the return value has already been reset to null. We need to catch this value before that. Message-ID: <201404181932.s3IJWHHY008664@aojmv0008> Changeset: e8c0262bafdd Author: lagergren Date: 2014-04-18 21:24 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/e8c0262bafdd 8040655: When processing a RewriteException debug object, the return value has already been reset to null. We need to catch this value before that. Reviewed-by: attila, lagergren Contributed-by: matherey.nunez at oracle.com ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/runtime/CompiledFunction.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/RewriteException.java - src/jdk/nashorn/internal/runtime/RuntimeEvent.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + src/jdk/nashorn/internal/runtime/events/RecompilationEvent.java + src/jdk/nashorn/internal/runtime/events/RuntimeEvent.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java - test/script/basic/arraysIntKey.js - test/script/basic/arraysIntKey.js.EXPECTED + test/script/basic/arrays_int_key.js + test/script/basic/arrays_int_key.js.EXPECTED - test/script/basic/relinkIndexGetter.js - test/script/basic/relinkIndexGetter.js.EXPECTED + test/script/basic/relink_index_getter.js + test/script/basic/relink_index_getter.js.EXPECTED ! test/script/trusted/event_queue.js ! test/script/trusted/event_queue.js.EXPECTED From greg at apigee.com Mon Apr 21 20:02:49 2014 From: greg at apigee.com (Greg Brail) Date: Mon, 21 Apr 2014 21:02:49 +0100 Subject: Getting file names on stack traces. Message-ID: Let's say that I have some JS code like this: (function(foo) { throw new Error('Sorry, ' + foo); }) and I execute it by reading it into a String variable, then executing it using ScriptEngine.eval(string), and then I call the function later, either from Java directly or from some other JS code. Right now, in Nashorn, I see that the stack trace of my exception will include the entry: ":2" to indicate the "file name" and line number of my error. I would like instead to stick in a file name so that the file name appears instead of "". Is there a way for me to do that? I did try setting the property "ScriptEngine.FILENAME" on my script context, but that seems to be a global context. It works the first time I run the script, but if I call the function later on from inside another script, the file name doesn't "stick" to the code. I can provide an example if I need to, but is there anything you guys can think of that I can do in order to get a file name to stick to this function for the purpose of stack traces? -- *greg brail* | *apigee * | twitter @gbrail From benjamin.sieffert at metrigo.de Tue Apr 22 07:47:02 2014 From: benjamin.sieffert at metrigo.de (Benjamin Sieffert) Date: Tue, 22 Apr 2014 09:47:02 +0200 Subject: Getting file names on stack traces. In-Reply-To: References: Message-ID: Hi Greg, I've also tried to do this, but (without looking into it very extensively) didn't find a way other than to build a second string that wraps the first one like this: String scriptWithFileName = "load(" // will be shown as scriptname in stacktraces + "{ name: \"" + name + '"' + ',' // the actual script + "script:" + escapeJavaScript(script) + '"' + '}' + ')'; It's working as intended and doesn't seem to have any unwanted side-effects, but of course it would be nice to be able to do this more cleanly from Java. I guess there's the possibility of calling the load-extension somewhere, but it doesn't seem to be public (Java) API. Hope this helps 2014-04-21 22:02 GMT+02:00 Greg Brail : > Let's say that I have some JS code like this: > > (function(foo) { > throw new Error('Sorry, ' + foo); > }) > > and I execute it by reading it into a String variable, then executing it > using ScriptEngine.eval(string), and then I call the function later, either > from Java directly or from some other JS code. > > Right now, in Nashorn, I see that the stack trace of my exception will > include the entry: > > ":2" > > to indicate the "file name" and line number of my error. > > I would like instead to stick in a file name so that the file name appears > instead of "". Is there a way for me to do that? > > I did try setting the property "ScriptEngine.FILENAME" on my script > context, but that seems to be a global context. It works the first time I > run the script, but if I call the function later on from inside another > script, the file name doesn't "stick" to the code. > > I can provide an example if I need to, but is there anything you guys can > think of that I can do in order to get a file name to stick to this > function for the purpose of stack traces? > > -- > *greg brail* | *apigee * | twitter > @gbrail > -- Benjamin Sieffert metrigo GmbH Sternstr. 106 20357 Hamburg Gesch?ftsf?hrer: Christian M?ller, Tobias Schlottke, Philipp Westermeyer, Martin Rie? Die Gesellschaft ist eingetragen beim Registergericht Hamburg Nr. HRB 120447. From marcus.lagergren at oracle.com Tue Apr 22 12:09:49 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Tue, 22 Apr 2014 12:09:49 +0000 Subject: hg: nashorn/jdk9/nashorn: 8033105: Make sure Nashorn test harness can run zlib benchmark Message-ID: <201404221209.s3MC9niY002729@aojmv0008> Changeset: 75e8d1a4ba23 Author: lagergren Date: 2014-04-22 14:09 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/75e8d1a4ba23 8033105: Make sure Nashorn test harness can run zlib benchmark Reviewed-by: attila, hannesw ! src/jdk/nashorn/internal/lookup/MethodHandleFactory.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! test/script/basic/compile-octane-splitter.js ! test/script/basic/compile-octane-splitter.js.EXPECTED ! test/script/basic/compile-octane.js ! test/script/basic/compile-octane.js.EXPECTED ! test/script/basic/run-octane.js - test/script/basic/runsunspider-eager.js ! test/script/basic/runsunspider.js + test/script/basic/runsunspider.js.EXPECTED From james.laskey at oracle.com Tue Apr 22 12:33:14 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 22 Apr 2014 09:33:14 -0300 Subject: Getting file names on stack traces. In-Reply-To: References: Message-ID: <7E4FF64B-7511-4AF8-AE4B-F153690C7054@oracle.com> Benjamin's recommendation is also ours. We're rather limited to how much we can extend the the javax.script APIs. I would, however, recommend assigning the script and name to globals such as $SCRIPT and $SCRIPT_NAME using engine.put. Then engine.eval("load('{script: $SCRIPT, name: $SCRIPT_NAME}')"). That way you can avoid having to escape your strings. Cheers, -- Jim On Apr 22, 2014, at 4:47 AM, Benjamin Sieffert wrote: > Hi Greg, > > I've also tried to do this, but (without looking into it very extensively) > didn't find a way other than to build a second string that wraps the first > one like this: > > String scriptWithFileName = "load(" > // will be shown as scriptname in stacktraces > + "{ name: \"" + name + '"' + ',' > // the actual script > + "script:" + escapeJavaScript(script) + '"' > + '}' > + ')'; > > It's working as intended and doesn't seem to have any unwanted > side-effects, but of course it would be nice to be able to do this more > cleanly from Java. I guess there's the possibility of calling the > load-extension somewhere, but it doesn't seem to be public (Java) API. > > Hope this helps > > > 2014-04-21 22:02 GMT+02:00 Greg Brail : > >> Let's say that I have some JS code like this: >> >> (function(foo) { >> throw new Error('Sorry, ' + foo); >> }) >> >> and I execute it by reading it into a String variable, then executing it >> using ScriptEngine.eval(string), and then I call the function later, either >> from Java directly or from some other JS code. >> >> Right now, in Nashorn, I see that the stack trace of my exception will >> include the entry: >> >> ":2" >> >> to indicate the "file name" and line number of my error. >> >> I would like instead to stick in a file name so that the file name appears >> instead of "". Is there a way for me to do that? >> >> I did try setting the property "ScriptEngine.FILENAME" on my script >> context, but that seems to be a global context. It works the first time I >> run the script, but if I call the function later on from inside another >> script, the file name doesn't "stick" to the code. >> >> I can provide an example if I need to, but is there anything you guys can >> think of that I can do in order to get a file name to stick to this >> function for the purpose of stack traces? >> >> -- >> *greg brail* | *apigee * | twitter >> @gbrail >> > > > > -- > Benjamin Sieffert > metrigo GmbH > Sternstr. 106 > 20357 Hamburg > > Gesch?ftsf?hrer: Christian M?ller, Tobias Schlottke, Philipp Westermeyer, > Martin Rie? > Die Gesellschaft ist eingetragen beim Registergericht Hamburg > Nr. HRB 120447. From ggmmaallee at gmail.com Wed Apr 23 06:40:51 2014 From: ggmmaallee at gmail.com (=?UTF-8?B?6auY5a+S?=) Date: Wed, 23 Apr 2014 14:40:51 +0800 Subject: CompiledScript slower when eval with binding ? Message-ID: Dears I found if the script is evaled with binding, the execution time increased a lot. Do you know the reason? Check this String script_text = "var a = 1"; ScriptEngineManager manager = new ScriptEngineManager(); ScriptEngine engine = manager.getEngineByName("js"); CompiledScript script = ((Compilable) engine).compile(script_text); Bindings bindings = engine.createBindings(); long dt = new Date().getTime(); for (int i = 0; i < 100000; i++) { script.eval(); //script.eval(bindings); // switch to this line and feel the slow speed, } System.out.println(new Date().getTime() - dt); -- Best wishes GAO From marcus.lagergren at oracle.com Thu Apr 24 08:15:15 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Thu, 24 Apr 2014 08:15:15 +0000 Subject: hg: nashorn/jdk9/nashorn: 2 new changesets Message-ID: <201404240815.s3O8FGvG023681@aojmv0008> Changeset: 222d989ca549 Author: lagergren Date: 2014-04-23 16:13 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/222d989ca549 8038426: Move all loggers from process wide scope into Global scope Reviewed-by: attila, hannesw ! src/jdk/nashorn/internal/codegen/ApplySpecialization.java ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/DumpBytecode.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FindScopeDepths.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/RangeAnalyzer.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/types/Range.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/lookup/MethodHandleFactory.java ! src/jdk/nashorn/internal/lookup/MethodHandleFunctionality.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/CompiledFunction.java ! src/jdk/nashorn/internal/runtime/Context.java - src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/GlobalConstants.java - src/jdk/nashorn/internal/runtime/Logging.java ! src/jdk/nashorn/internal/runtime/PropertyHashMap.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/arrays/ContinuousArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/TypedArrayData.java ! src/jdk/nashorn/internal/runtime/events/RecompilationEvent.java + src/jdk/nashorn/internal/runtime/logging/DebugLogger.java + src/jdk/nashorn/internal/runtime/logging/Loggable.java + src/jdk/nashorn/internal/runtime/logging/Logger.java ! src/jdk/nashorn/internal/runtime/options/KeyValueOption.java + src/jdk/nashorn/internal/runtime/options/LoggingOption.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/tools/Shell.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java ! test/src/jdk/nashorn/internal/test/framework/ParallelTestRunner.java Changeset: 0c4cda533038 Author: lagergren Date: 2014-04-23 17:37 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/0c4cda533038 8041434: Add synchronization to the common global constants structure Reviewed-by: attila, hannesw ! bin/runopt.sh ! src/jdk/nashorn/internal/codegen/ApplySpecialization.java ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationEnvironment.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FindScopeDepths.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/RangeAnalyzer.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/lookup/MethodHandleFactory.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/CompiledFunction.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/GlobalConstants.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/arrays/ContinuousArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/TypedArrayData.java ! src/jdk/nashorn/internal/runtime/events/RecompilationEvent.java ! src/jdk/nashorn/internal/runtime/logging/DebugLogger.java ! src/jdk/nashorn/internal/runtime/logging/Loggable.java ! src/jdk/nashorn/tools/Shell.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java From james.laskey at oracle.com Thu Apr 24 11:45:52 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 24 Apr 2014 08:45:52 -0300 Subject: CompiledScript slower when eval with binding ? In-Reply-To: References: Message-ID: GAO, I launched an investigation. You can monitor by following https://bugs.openjdk.java.net/browse/JDK-8041697 . Cheers, -- Jim On Apr 23, 2014, at 3:40 AM, ?? wrote: > Dears > > I found if the script is evaled with binding, the execution time increased > a lot. > Do you know the reason? > Check this > > String script_text = "var a = 1"; > > ScriptEngineManager manager = new ScriptEngineManager(); > ScriptEngine engine = manager.getEngineByName("js"); > CompiledScript script = ((Compilable) engine).compile(script_text); > > Bindings bindings = engine.createBindings(); > > long dt = new Date().getTime(); > for (int i = 0; i < 100000; i++) { > script.eval(); > //script.eval(bindings); // switch to this line and feel the > slow speed, > } > System.out.println(new Date().getTime() - dt); > > -- > Best wishes > GAO From marcus.lagergren at oracle.com Fri Apr 25 12:31:34 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Fri, 25 Apr 2014 12:31:34 +0000 Subject: hg: nashorn/jdk9/nashorn: 8041905: Fix apply2call bug that prevented avatar.js unit tests from running correctly Message-ID: <201404251231.s3PCVYSl013943@aojmv0008> Changeset: 77511a74bb48 Author: lagergren Date: 2014-04-25 14:26 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/77511a74bb48 8041905: Fix apply2call bug that prevented avatar.js unit tests from running correctly Reviewed-by: attila, hannesw ! src/jdk/nashorn/internal/codegen/ApplySpecialization.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java From hannes.wallnoefer at oracle.com Mon Apr 28 13:08:04 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 28 Apr 2014 15:08:04 +0200 Subject: Review request for JDK-8041953 Message-ID: <535E52B4.5010909@oracle.com> Please review JDK-8041953: JDK-8031359.js fails in 8u-dev: http://cr.openjdk.java.net/~hannesw/8041953/ This fixes a number of merge errors in JDK-8031359.js fails in 8u-dev. Thanks, Hannes From andrebargull at googlemail.com Mon Apr 28 13:30:50 2014 From: andrebargull at googlemail.com (=?UTF-8?B?QW5kcsOpIEJhcmd1bGw=?=) Date: Mon, 28 Apr 2014 15:30:50 +0200 Subject: Fuzzing jdk9/dev/nashorn and nashorn/jdk9/nashorn Message-ID: <535E580A.8070006@googlemail.com> Hi, here are the current jsfunfuzz results for jdk9/dev/nashorn at 794:e88f1df9b412 and nashorn/jdk9/nashorn at 794:77511a74bb48 using JDK 9 b09. Bugs which are only reproducible in one of the two repositories are marked as such. Except for the `Function("if(eval('', eval('', function() {}))) { }")` test case, all other bugs in jdk9/dev/nashorn look familiar, so most likely they were already reported some time ago (but I didn't verify it...). - Andr? -------------- Oh, first of all you may want to apply this change. ;-) diff --git a/src/jdk/nashorn/tools/Shell.java b/src/jdk/nashorn/tools/Shell.java --- a/src/jdk/nashorn/tools/Shell.java +++ b/src/jdk/nashorn/tools/Shell.java @@ -448,15 +448,15 @@ public class Shell { } if (res != ScriptRuntime.UNDEFINED) { err.println(JSType.toString(res)); } } } finally { if (globalChanged) { - Context.setGlobal(global); + Context.setGlobal(oldGlobal); } } return SUCCESS; } } -------------- jjs> Function("switch(0) { default: {break;} return }") Exception in thread "main" java.lang.VerifyError: Code generation bug in "L:1": likely stack misaligned: java.lang.NullPointerException at jdk.nashorn.internal.codegen.CodeGenerator.leaveFunctionNode(CodeGenerator.java:1582) at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:324) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.LexicalContextExpression.accept(LexicalContextExpression.java:46) at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:52) at jdk.nashorn.internal.codegen.CodeGenerator$3.enterFunctionNode(CodeGenerator.java:620) at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:323) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.LexicalContextExpression.accept(LexicalContextExpression.java:46) at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:52) ... jjs> Function("L: { { break L; } return; }") Exception in thread "main" java.lang.VerifyError: StackMapTable error: bad offset Exception Details: Location: jdk/nashorn/internal/scripts/Script$\^function\_.L:1(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;)Ljava/lang/Object; @0: aload_0 Reason: Invalid stackmap specification. Current Frame: bci: @12 flags: { } locals: { 'jdk/nashorn/internal/runtime/ScriptFunction', 'java/lang/Object', 'jdk/nashorn/internal/runtime/ScriptObject' } stack: { } Bytecode: 0000000: 2ab6 0018 4da7 0007 0000 00bf Stackmap Table: full_frame(@8,{},{Object[#52]}) append_frame(@12,Object[#20],Object[#54],Object[#56]) jjs> Function("L: { while(0)break L; return; }") Exception in thread "main" java.lang.VerifyError: StackMapTable error: bad offset Exception Details: Location: jdk/nashorn/internal/scripts/Script$\^function\_.L:1(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;)Ljava/lang/Object; @0: aload_0 Reason: Invalid stackmap specification. Current Frame: bci: @19 flags: { } locals: { 'jdk/nashorn/internal/runtime/ScriptFunction', 'java/lang/Object', 'jdk/nashorn/internal/runtime/ScriptObject' } stack: { } Bytecode: 0000000: 2ab6 0018 4da7 0006 a700 0b03 9aff fcb2 0000010: 002b b0 Stackmap Table: append_frame(@8,Object[#52]) same_frame(@11) same_frame(@19) jjs> Function("L: {while(0)break L; return [](); }") Exception in thread "main" java.lang.VerifyError: Code generation bug in "L:1": likely stack misaligned: java.lang.ArrayIndexOutOfBoundsException: 0 at jdk.nashorn.internal.codegen.CodeGenerator.leaveFunctionNode(CodeGenerator.java:1582) at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:324) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.LexicalContextExpression.accept(LexicalContextExpression.java:46) at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:52) at jdk.nashorn.internal.codegen.CodeGenerator$3.enterFunctionNode(CodeGenerator.java:620) at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:323) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.LexicalContextExpression.accept(LexicalContextExpression.java:46) at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:52) ... [nashorn/jdk9/nashorn] jjs> Function("do with({}) break ; while(0);") Exception in thread "main" java.lang.AssertionError at jdk.nashorn.internal.codegen.CodeGenerator.popScopes(CodeGenerator.java:807) at jdk.nashorn.internal.codegen.CodeGenerator.popScopesUntil(CodeGenerator.java:799) at jdk.nashorn.internal.codegen.CodeGenerator.enterBreakNode(CodeGenerator.java:820) at jdk.nashorn.internal.ir.BreakNode.accept(BreakNode.java:63) at jdk.nashorn.internal.ir.Node.accept(Node.java:306) at jdk.nashorn.internal.ir.Block.accept(Block.java:155) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.Block.accept(Block.java:378) at jdk.nashorn.internal.codegen.CodeGenerator.enterWithNode(CodeGenerator.java:2820) at jdk.nashorn.internal.ir.WithNode.accept(WithNode.java:68) ... [nashorn/jdk9/nashorn] jjs> Function("while(0)with({}) continue ;") Exception in thread "main" java.lang.AssertionError at jdk.nashorn.internal.codegen.CodeGenerator.popScopes(CodeGenerator.java:807) at jdk.nashorn.internal.codegen.CodeGenerator.popScopesUntil(CodeGenerator.java:799) at jdk.nashorn.internal.codegen.CodeGenerator.enterContinueNode(CodeGenerator.java:1229) at jdk.nashorn.internal.ir.ContinueNode.accept(ContinueNode.java:59) at jdk.nashorn.internal.ir.Node.accept(Node.java:306) at jdk.nashorn.internal.ir.Block.accept(Block.java:155) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.Block.accept(Block.java:378) at jdk.nashorn.internal.codegen.CodeGenerator.enterWithNode(CodeGenerator.java:2820) at jdk.nashorn.internal.ir.WithNode.accept(WithNode.java:68) ... [nashorn/jdk9/nashorn] jjs> Function("eval([]);") Exception in thread "main" java.lang.AssertionError at jdk.nashorn.internal.ir.LiteralNode$ArrayLiteralNode.analyze(LiteralNode.java:659) at jdk.nashorn.internal.codegen.Attr.leaveLiteralNode(Attr.java:841) at jdk.nashorn.internal.ir.LiteralNode$ArrayLiteralNode.accept(LiteralNode.java:872) at jdk.nashorn.internal.ir.CallNode.accept(CallNode.java:216) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.LexicalContextExpression.accept(LexicalContextExpression.java:46) at jdk.nashorn.internal.ir.CallNode.accept(CallNode.java:40) at jdk.nashorn.internal.ir.ExpressionStatement.accept(ExpressionStatement.java:67) at jdk.nashorn.internal.ir.Node.accept(Node.java:306) at jdk.nashorn.internal.ir.Block.accept(Block.java:155) ... [nashorn/jdk9/nashorn] jjs> Function("try{}finally{[]}") Exception in thread "main" java.lang.AssertionError at jdk.nashorn.internal.ir.LiteralNode$ArrayLiteralNode.analyze(LiteralNode.java:659) at jdk.nashorn.internal.codegen.Attr.leaveLiteralNode(Attr.java:841) at jdk.nashorn.internal.ir.LiteralNode$ArrayLiteralNode.accept(LiteralNode.java:872) at jdk.nashorn.internal.ir.ExpressionStatement.accept(ExpressionStatement.java:67) at jdk.nashorn.internal.ir.Node.accept(Node.java:306) at jdk.nashorn.internal.ir.Block.accept(Block.java:155) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.Block.accept(Block.java:378) at jdk.nashorn.internal.ir.BlockStatement.accept(BlockStatement.java:85) at jdk.nashorn.internal.ir.Node.accept(Node.java:306) ... [nashorn/jdk9/nashorn] jjs> Function("try { } catch(x if 1) { try { } catch(x2) { } } ") Exception in thread "main" java.lang.AssertionError: stacks [] is not equivalent with [boolean] at join point skip_117 at jdk.nashorn.internal.codegen.MethodEmitter.mergeStackTo(MethodEmitter.java:1696) at jdk.nashorn.internal.codegen.MethodEmitter.label(MethodEmitter.java:1719) at jdk.nashorn.internal.codegen.CodeGenerator.enterTryNode(CodeGenerator.java:2718) at jdk.nashorn.internal.ir.TryNode.accept(TryNode.java:110) at jdk.nashorn.internal.ir.Node.accept(Node.java:306) at jdk.nashorn.internal.ir.Block.accept(Block.java:155) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.Block.accept(Block.java:378) at jdk.nashorn.internal.codegen.CodeGenerator.enterBlockStatement(CodeGenerator.java:1257) at jdk.nashorn.internal.ir.BlockStatement.accept(BlockStatement.java:84) ... [nashorn/jdk9/nashorn] jjs> Function("try { } catch(x if 1) { try { return; } catch(x2) { { } } } ") Exception in thread "main" java.lang.AssertionError: Only return value on stack allowed at return point - depth=2 stack = [boolean, object] at jdk.nashorn.internal.codegen.MethodEmitter._return(MethodEmitter.java:1429) at jdk.nashorn.internal.codegen.CodeGenerator.enterReturnNode(CodeGenerator.java:2009) at jdk.nashorn.internal.ir.ReturnNode.accept(ReturnNode.java:91) at jdk.nashorn.internal.ir.Node.accept(Node.java:306) at jdk.nashorn.internal.ir.Block.accept(Block.java:155) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.Block.accept(Block.java:378) at jdk.nashorn.internal.codegen.CodeGenerator.enterTryNode(CodeGenerator.java:2632) at jdk.nashorn.internal.ir.TryNode.accept(TryNode.java:110) at jdk.nashorn.internal.ir.Node.accept(Node.java:306) ... [nashorn/jdk9/nashorn] jjs> try{ Function("Error() * (false)[-0]--") } catch(e){ e.printStackTrace() } java.lang.UnsupportedOperationException: getBytecodeStackType at jdk.nashorn.internal.codegen.types.Type$7.getBytecodeStackType(Type.java:973) at jdk.nashorn.internal.codegen.CodeGenerator.appendType(CodeGenerator.java:4213) at jdk.nashorn.internal.codegen.CodeGenerator.getLvarTypesDescriptor(CodeGenerator.java:4199) at jdk.nashorn.internal.codegen.CodeGenerator.access$4400(CodeGenerator.java:176) at jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.addUnwarrantedOptimismHandlerLabel(CodeGenerator.java:4127) at jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:4008) at jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:3952) at jdk.nashorn.internal.codegen.CodeGenerator$15.storeNonDiscard(CodeGenerator.java:2908) at jdk.nashorn.internal.codegen.CodeGenerator$Store.store(CodeGenerator.java:3840) at jdk.nashorn.internal.codegen.CodeGenerator.enterDECINC(CodeGenerator.java:2925) ... jjs> Function("try { var x = 1, x = null; } finally { }") Exception in thread "main" java.lang.VerifyError: Stack map does not match the one at exception handler 14 Exception Details: Location: jdk/nashorn/internal/scripts/Script$\^function\_.L:1(Ljava/lang/Object;)Ljava/lang/Object; @14: astore_2 Reason: Type 'java/lang/Integer' (current frame, locals[1]) is not assignable to null (stack map, locals[1]) Current Frame: bci: @8 flags: { } locals: { 'java/lang/Object', 'java/lang/Integer', null } stack: { 'java/lang/Throwable' } Stackmap Frame: bci: @14 flags: { } locals: { 'java/lang/Object', null, null } stack: { 'java/lang/Throwable' } Bytecode: 0000000: 014c 014d 04b8 0033 4c01 4ca7 0008 4d2c 0000010: 4e2d bfb2 002b b0 Exception Handler Table: bci [4, 14] => handler: 14 Stackmap Table: full_frame(@14,{Object[#61],Null,Null},{Object[#53]}) same_frame(@19) [nashorn/jdk9/nashorn] jjs> Function("try { var x = {}, x = []; } catch(x3) { } ") Exception in thread "main" java.lang.VerifyError: Stack map does not match the one at exception handler 34 Exception Details: Location: jdk/nashorn/internal/scripts/Script$\^function\_.L:1(Ljava/lang/Object;)Ljava/lang/Object; @34: astore_2 Reason: Type 'jdk/nashorn/internal/scripts/JO4' (current frame, locals[1]) is not assignable to 'jdk/nashorn/internal/objects/NativeArray' (stack map, locals[1]) Current Frame: bci: @22 flags: { } locals: { 'java/lang/Object', 'jdk/nashorn/internal/scripts/JO4', null } stack: { 'java/lang/Throwable' } Stackmap Frame: bci: @34 flags: { } locals: { 'java/lang/Object', 'jdk/nashorn/internal/objects/NativeArray', null } stack: { 'java/lang/Throwable' } Bytecode: 0000000: 014c 014d bb00 2f59 03b8 001e b700 3259 0000010: b800 37b6 003d 4c04 b800 41b8 0045 4ca7 0000020: 0013 4d2c 59c1 0049 9900 09c0 0049 b400 0000030: 4d4e b200 2bb0 Exception Handler Table: bci [4, 34] => handler: 34 Stackmap Table: full_frame(@34,{Object[#84],Object[#86],Null},{Object[#71]}) full_frame(@49,{Object[#84],Object[#86],Object[#71]},{Object[#84]}) same_frame(@50) [nashorn/jdk9/nashorn] jjs> Function("[delete this]") Exception in thread "main" java.lang.AssertionError at jdk.nashorn.internal.ir.LiteralNode$ArrayLiteralNode.presetObjectArray(LiteralNode.java:737) at jdk.nashorn.internal.ir.LiteralNode$ArrayLiteralNode.getPresets(LiteralNode.java:843) at jdk.nashorn.internal.codegen.CodeGenerator.loadArray(CodeGenerator.java:1664) at jdk.nashorn.internal.codegen.CodeGenerator.loadLiteral(CodeGenerator.java:1847) at jdk.nashorn.internal.codegen.CodeGenerator.enterLiteralNode(CodeGenerator.java:1897) at jdk.nashorn.internal.codegen.CodeGenerator.access$900(CodeGenerator.java:176) at jdk.nashorn.internal.codegen.CodeGenerator$3.enterLiteralNode(CodeGenerator.java:637) at jdk.nashorn.internal.ir.LiteralNode$ArrayLiteralNode.accept(LiteralNode.java:869) at jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:570) at jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:549) ... [jdk9/dev/nashorn] jjs> try { Function("if(eval('', eval('', function() {}))) { }") } catch (e) { e.printStackTrace() } java.lang.ArrayIndexOutOfBoundsException: -2 at jdk.nashorn.internal.codegen.CodeGeneratorLexicalContext.nextFreeSlot(CodeGeneratorLexicalContext.java:195) at jdk.nashorn.internal.codegen.CodeGenerator.initLocals(CodeGenerator.java:958) at jdk.nashorn.internal.codegen.CodeGenerator.enterBlock(CodeGenerator.java:568) at jdk.nashorn.internal.ir.Block.accept(Block.java:142) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.Block.accept(Block.java:361) at jdk.nashorn.internal.codegen.CodeGenerator.enterIfNode(CodeGenerator.java:1154) at jdk.nashorn.internal.ir.IfNode.accept(IfNode.java:76) at jdk.nashorn.internal.ir.Node.accept(Node.java:291) at jdk.nashorn.internal.ir.Block.accept(Block.java:143) ... [nashorn/jdk9/nashorn] jjs> try { Function("if(eval('', eval('', function() {}))) { }")() } catch (e) { e.printStackTrace() } java.lang.AssertionError at jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:4012) at jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:3952) at jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:3940) at jdk.nashorn.internal.codegen.CodeGenerator$4.evalCall(CodeGenerator.java:976) at jdk.nashorn.internal.codegen.CodeGenerator$4.enterIdentNode(CodeGenerator.java:993) at jdk.nashorn.internal.ir.IdentNode.accept(IdentNode.java:111) at jdk.nashorn.internal.codegen.CodeGenerator.enterCallNode(CodeGenerator.java:879) at jdk.nashorn.internal.codegen.CodeGenerator.access$800(CodeGenerator.java:176) at jdk.nashorn.internal.codegen.CodeGenerator$3.enterCallNode(CodeGenerator.java:632) at jdk.nashorn.internal.ir.CallNode.accept(CallNode.java:210) ... [nashorn/jdk9/nashorn] jjs> Function("eval(\"[,,];\", [11,12,13,14].some)")() Exception in thread "main" java.lang.AssertionError at jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:4012) at jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:3952) at jdk.nashorn.internal.codegen.CodeGenerator$3.enterAccessNode(CodeGenerator.java:592) at jdk.nashorn.internal.ir.AccessNode.accept(AccessNode.java:64) at jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:570) at jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:549) at jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:505) at jdk.nashorn.internal.codegen.CodeGenerator.loadArgs(CodeGenerator.java:852) at jdk.nashorn.internal.codegen.CodeGenerator.loadArgs(CodeGenerator.java:831) at jdk.nashorn.internal.codegen.CodeGenerator.loadArgs(CodeGenerator.java:827) ... [nashorn/jdk9/nashorn] jjs> Function("eval(\"1.2e3\", ({})[ /x/ ])")() Exception in thread "main" java.lang.AssertionError at jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:4012) at jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:3952) at jdk.nashorn.internal.codegen.CodeGenerator$3.enterIndexNode(CodeGenerator.java:611) at jdk.nashorn.internal.ir.IndexNode.accept(IndexNode.java:59) at jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:570) at jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:549) at jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:505) at jdk.nashorn.internal.codegen.CodeGenerator.loadArgs(CodeGenerator.java:852) at jdk.nashorn.internal.codegen.CodeGenerator.loadArgs(CodeGenerator.java:831) at jdk.nashorn.internal.codegen.CodeGenerator.loadArgs(CodeGenerator.java:827) ... [nashorn/jdk9/nashorn] jjs> Function("eval(\"x4\", x3);")() :2 ReferenceError: "x3" is not defined jjs> x3={}; x4={} [object Object] jjs> Function("eval(\"x4\", x3);")() Exception in thread "main" java.lang.AssertionError at jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:4012) at jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:3948) at jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:3944) at jdk.nashorn.internal.codegen.CodeGenerator.loadIdent(CodeGenerator.java:328) at jdk.nashorn.internal.codegen.CodeGenerator.access$500(CodeGenerator.java:176) at jdk.nashorn.internal.codegen.CodeGenerator$3.enterIdentNode(CodeGenerator.java:573) at jdk.nashorn.internal.ir.IdentNode.accept(IdentNode.java:111) at jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:570) at jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:549) at jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:505) ... [nashorn/jdk9/nashorn] jjs> Function("with({5.0000000000000000000000: String()}){(false); }")() Exception in thread "main" java.lang.VerifyError: Code generation bug in "L:1": likely stack misaligned: java.lang.AssertionError: int is not a script object at jdk.nashorn.internal.codegen.CodeGenerator.leaveFunctionNode(CodeGenerator.java:1582) at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:324) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.LexicalContextExpression.accept(LexicalContextExpression.java:46) at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:52) at jdk.nashorn.internal.codegen.CompilationPhase$9.transform(CompilationPhase.java:330) at jdk.nashorn.internal.codegen.CompilationPhase.apply(CompilationPhase.java:436) at jdk.nashorn.internal.codegen.Compiler.compileInternal(Compiler.java:278) at jdk.nashorn.internal.codegen.Compiler.compile(Compiler.java:257) at jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.compileRestOfMethod(RecompilableScriptFunctionData.java:440) at jdk.nashorn.internal.runtime.CompiledFunction$OptimismInfo.compileRestOfMethod(CompiledFunction.java:661) at jdk.nashorn.internal.runtime.CompiledFunction.handleRewriteException(CompiledFunction.java:615) at jdk.nashorn.internal.runtime.CompiledFunction.handleRewriteException(CompiledFunction.java:564) at jdk.nashorn.internal.scripts.Script$\^shell\_.:program(:1) at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:555) at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:221) at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:376) at jdk.nashorn.internal.runtime.Context.eval(Context.java:516) at jdk.nashorn.tools.Shell.readEvalPrint(Shell.java:441) at jdk.nashorn.tools.Shell.run(Shell.java:157) at jdk.nashorn.tools.Shell.main(Shell.java:132) at jdk.nashorn.tools.Shell.main(Shell.java:111) Caused by: java.lang.AssertionError: int is not a script object at jdk.nashorn.internal.codegen.CodeGenerator.generateContinuationHandler(CodeGenerator.java:4587) at jdk.nashorn.internal.codegen.CodeGenerator.leaveFunctionNode(CodeGenerator.java:1563) ... 21 more [nashorn/jdk9/nashorn] jjs> Function("try { var x = undefined, x = 5.0000000000000000000000; } catch(x) { x = undefined; } ")() Exception in thread "main" java.lang.VerifyError: Stack map does not match the one at exception handler 27 Exception Details: Location: jdk/nashorn/internal/scripts/Script$Recompilation$1$\^function\_.L:1(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;)Ljava/lang/Object; @27: astore Reason: Type 'java/lang/Object' (current frame, locals[3]) is not assignable to 'java/lang/Double' (stack map, locals[3]) Current Frame: bci: @16 flags: { } locals: { 'jdk/nashorn/internal/runtime/ScriptFunction', 'java/lang/Object', 'jdk/nashorn/internal/runtime/ScriptObject', 'java/lang/Object', null } stack: { 'java/lang/Throwable' } Stackmap Frame: bci: @27 flags: { } locals: { 'jdk/nashorn/internal/runtime/ScriptFunction', 'java/lang/Object', 'jdk/nashorn/internal/runtime/ScriptObject', 'java/lang/Double', null } stack: { 'java/lang/Throwable' } Bytecode: 0000000: 2ab6 0018 4d01 4e01 3a04 2cba 0024 0000 0000010: 4e14 0025 b800 2c4e a700 1e3a 0419 0459 0000020: c100 3099 0009 c000 30b4 0034 3a05 2cba 0000030: 0024 0000 3a05 b200 3db0 Exception Handler Table: bci [10, 27] => handler: 27 Stackmap Table: full_frame(@27,{Object[#20],Object[#68],Object[#70],Object[#40],Null},{Object[#46]}) full_frame(@44,{Object[#20],Object[#68],Object[#70],Object[#40],Object[#46]},{Object[#68]}) same_frame(@54) [nashorn/jdk9/nashorn] jjs> try { Function("(function (x){ x %= this}(false))")() } catch(e) { e.printStackTrace() } java.lang.invoke.WrongMethodTypeException: cannot convert MethodHandle(Object,double)Object to (Object,boolean)Object at java.lang.invoke.MethodHandle.asTypeUncached(MethodHandle.java:776) at java.lang.invoke.MethodHandle.asType(MethodHandle.java:770) at jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.addCode(RecompilableScriptFunctionData.java:601) at jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.getBest(RecompilableScriptFunctionData.java:610) at jdk.nashorn.internal.runtime.ScriptFunctionData.getBestInvoker(ScriptFunctionData.java:223) at jdk.nashorn.internal.runtime.ScriptFunction.findCallMethod(ScriptFunction.java:545) at jdk.nashorn.internal.runtime.ScriptObject.lookup(ScriptObject.java:1767) at jdk.nashorn.internal.runtime.linker.NashornLinker.getGuardedInvocation(NashornLinker.java:100) at jdk.nashorn.internal.runtime.linker.NashornLinker.getGuardedInvocation(NashornLinker.java:94) at jdk.internal.dynalink.support.CompositeTypeBasedGuardingDynamicLinker.getGuardedInvocation(CompositeTypeBasedGuardingDynamicLinker.java:176) ... [nashorn/jdk9/nashorn] jjs> try { Function("eval.apply.apply(function(){ eval('') })")() } catch (e) { e.printStackTrace() } java.lang.IndexOutOfBoundsException: start=4 end=3 at java.lang.invoke.MethodType.newIndexOutOfBoundsException(MethodType.java:189) at java.lang.invoke.MethodType.dropParameterTypes(MethodType.java:482) at jdk.internal.dynalink.support.Guards.getTestType(Guards.java:247) at jdk.internal.dynalink.support.Guards.asType(Guards.java:243) at jdk.internal.dynalink.linker.GuardedInvocation.asTypeSafeReturn(GuardedInvocation.java:342) at jdk.nashorn.internal.runtime.linker.Bootstrap.asTypeSafeReturn(Bootstrap.java:394) at jdk.nashorn.internal.runtime.linker.NashornLinker.getGuardedInvocation(NashornLinker.java:94) at jdk.internal.dynalink.support.CompositeTypeBasedGuardingDynamicLinker.getGuardedInvocation(CompositeTypeBasedGuardingDynamicLinker.java:176) at jdk.internal.dynalink.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:124) at jdk.internal.dynalink.support.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:149) ... [nashorn/jdk9/nashorn] jjs> try{ Function("(false % !this) && 0")() } catch (e) { e.printStackTrace() } java.lang.ArithmeticException: / by zero at jdk.nashorn.internal.scripts.Script$\^function\_.L:1(:2) at jdk.nashorn.internal.scripts.Script$\^shell\_.:program(:1) at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:555) at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:221) at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:376) at jdk.nashorn.internal.runtime.Context.eval(Context.java:516) at jdk.nashorn.tools.Shell.readEvalPrint(Shell.java:441) at jdk.nashorn.tools.Shell.run(Shell.java:157) at jdk.nashorn.tools.Shell.main(Shell.java:132) at jdk.nashorn.tools.Shell.main(Shell.java:111) ... [nashorn/jdk9/nashorn] jjs> Function("with({8: 'fafafa'.replace()}){ }")() Exception in thread "main" java.lang.VerifyError: Code generation bug in "L:1": likely stack misaligned: java.lang.AssertionError: int is not a script object at jdk.nashorn.internal.codegen.CodeGenerator.leaveFunctionNode(CodeGenerator.java:1582) at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:324) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.LexicalContextExpression.accept(LexicalContextExpression.java:46) at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:52) at jdk.nashorn.internal.codegen.CompilationPhase$9.transform(CompilationPhase.java:330) at jdk.nashorn.internal.codegen.CompilationPhase.apply(CompilationPhase.java:436) at jdk.nashorn.internal.codegen.Compiler.compileInternal(Compiler.java:278) at jdk.nashorn.internal.codegen.Compiler.compile(Compiler.java:257) at jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.compileRestOfMethod(RecompilableScriptFunctionData.java:440) ... Caused by: java.lang.AssertionError: int is not a script object at jdk.nashorn.internal.codegen.CodeGenerator.generateContinuationHandler(CodeGenerator.java:4587) at jdk.nashorn.internal.codegen.CodeGenerator.leaveFunctionNode(CodeGenerator.java:1563) ... 21 more [nashorn/jdk9/nashorn] jjs> try { Function("new eval(function(){})") } catch (e) { e.printStackTrace() } jdk.nashorn.internal.lookup.MethodHandleFactory$LookupException: java.lang.NoSuchMethodException: no such method: jdk.nashorn.internal.scripts.Script$\^function\_.L:1$L:2-1(Object)Object/invokeStatic at jdk.nashorn.internal.lookup.MethodHandleFactory$StandardMethodHandleFunctionality.findStatic(MethodHandleFactory.java:497) at jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.lookupCodeMethod(RecompilableScriptFunctionData.java:534) at jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.lookupWithExplicitType(RecompilableScriptFunctionData.java:530) at jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.lookup(RecompilableScriptFunctionData.java:526) at jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.addCode(RecompilableScriptFunctionData.java:558) at jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.initializeCode(RecompilableScriptFunctionData.java:548) at jdk.nashorn.internal.codegen.CompileUnit$FunctionInitializer.initializeCode(CompileUnit.java:60) at jdk.nashorn.internal.codegen.CompileUnit.initializeFunctionsCode(CompileUnit.java:130) at jdk.nashorn.internal.codegen.Compiler.install(Compiler.java:394) at jdk.nashorn.internal.runtime.Context.compile(Context.java:970) ... Caused by: java.lang.NoSuchMethodException: no such method: jdk.nashorn.internal.scripts.Script$\^function\_.L:1$L:2-1(Object)Object/invokeStatic at java.lang.invoke.MemberName.makeAccessException(MemberName.java:876) at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:993) at java.lang.invoke.MethodHandles$Lookup.resolveOrFail(MethodHandles.java:1377) at java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:774) at jdk.nashorn.internal.lookup.MethodHandleFactory$StandardMethodHandleFunctionality.findStatic(MethodHandleFactory.java:494) ... 21 more Caused by: java.lang.NoSuchMethodError: jdk.nashorn.internal.scripts.Script$\^function\_.L:1$L:2-1(Ljava/lang/Object;)Ljava/lang/Object; at java.lang.invoke.MethodHandleNatives.resolve(Native Method) at java.lang.invoke.MemberName$Factory.resolve(MemberName.java:965) at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:990) ... 24 more [nashorn/jdk9/nashorn] jjs> try{ Function("(function (x) '' )(true)")() }catch(e){ e.printStackTrace() } jdk.nashorn.internal.runtime.ParserException: :2:15 Missing close quote (function (x) '' )(true) ^ at jdk.nashorn.internal.parser.Lexer.error(Lexer.java:1697) at jdk.nashorn.internal.parser.Lexer.scanString(Lexer.java:995) at jdk.nashorn.internal.parser.Lexer.lexify(Lexer.java:1606) at jdk.nashorn.internal.parser.AbstractParser.getToken(AbstractParser.java:132) at jdk.nashorn.internal.parser.AbstractParser.nextToken(AbstractParser.java:211) at jdk.nashorn.internal.parser.AbstractParser.nextOrEOL(AbstractParser.java:170) at jdk.nashorn.internal.parser.AbstractParser.next(AbstractParser.java:157) at jdk.nashorn.internal.parser.Parser.parse(Parser.java:281) at jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.reparse(RecompilableScriptFunctionData.java:349) at jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.compile(RecompilableScriptFunctionData.java:456) ... [nashorn/jdk9/nashorn] jjs> Function("Function.prototype.apply.apply([11,12,13,14].sort)")() :2 TypeError: [Ljava.lang.Object;@96532d6 is not an Object => Error message contains internal type descriptor? From marcus.lagergren at oracle.com Mon Apr 28 14:38:05 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Mon, 28 Apr 2014 14:38:05 +0000 Subject: hg: nashorn/jdk9/nashorn: 8041995: Problems when loading tree expressions with several optimistic program points when optimistically initializing ObjectNodes Message-ID: <201404281438.s3SEc6a0016426@aojmv0008> Changeset: 0b3e11df32be Author: lagergren Date: 2014-04-28 16:37 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/0b3e11df32be 8041995: Problems when loading tree expressions with several optimistic program points when optimistically initializing ObjectNodes Reviewed-by: jlaskey, attila ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java + test/script/basic/JDK-8041995.js + test/script/basic/JDK-8041995.js.EXPECTED From attila.szegedi at oracle.com Mon Apr 28 14:48:07 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 28 Apr 2014 16:48:07 +0200 Subject: Review request for JDK-8041953 In-Reply-To: <535E52B4.5010909@oracle.com> References: <535E52B4.5010909@oracle.com> Message-ID: <753F6C59-3D69-4A5F-A4B5-BEB67EE550AE@oracle.com> +1 On Apr 28, 2014, at 3:08 PM, Hannes Wallnoefer wrote: > Please review JDK-8041953: JDK-8031359.js fails in 8u-dev: > > http://cr.openjdk.java.net/~hannesw/8041953/ > > This fixes a number of merge errors in JDK-8031359.js fails in 8u-dev. > > Thanks, > Hannes From marcus.lagergren at oracle.com Mon Apr 28 14:50:18 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 28 Apr 2014 16:50:18 +0200 Subject: Review request for JDK-8041953 In-Reply-To: <535E52B4.5010909@oracle.com> References: <535E52B4.5010909@oracle.com> Message-ID: <883B8647-B85E-41C5-97BF-7C74DD92385B@oracle.com> This looks good. I wonder what the original cause of the failure was and if there slipped through any more in this merge or others. However - this looks like it should. +1 /M On 28 Apr 2014, at 15:08, Hannes Wallnoefer wrote: > Please review JDK-8041953: JDK-8031359.js fails in 8u-dev: > > http://cr.openjdk.java.net/~hannesw/8041953/ > > This fixes a number of merge errors in JDK-8031359.js fails in 8u-dev. > > Thanks, > Hannes From attila.szegedi at oracle.com Tue Apr 29 14:20:59 2014 From: attila.szegedi at oracle.com (attila.szegedi at oracle.com) Date: Tue, 29 Apr 2014 14:20:59 +0000 Subject: hg: nashorn/jdk9/nashorn: 8038398: OptimisticRecompilationTest fails on staging repo nashorn/jdk9/nashorn due to test framework Message-ID: <201404291421.s3TEL0AK028258@aojmv0008> Changeset: d5c2bf69f341 Author: mnunez Date: 2014-04-29 16:00 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/d5c2bf69f341 8038398: OptimisticRecompilationTest fails on staging repo nashorn/jdk9/nashorn due to test framework Reviewed-by: attila, lagergren - test/script/currently-failing/OptimisticRecompilationTest.java + test/script/trusted/optimistic_recompilation.js + test/script/trusted/optimistic_recompilation.js.EXPECTED From david at code.davidpcaldwell.com Wed Apr 30 14:04:38 2014 From: david at code.davidpcaldwell.com (David P. Caldwell) Date: Wed, 30 Apr 2014 10:04:38 -0400 Subject: Nashorn caching of processed scripts? Message-ID: Does Nashorn do some kind of background incremental compilation and caching of compiled scripts somewhere in the local file system? Is it possible to disable it? I'm porting a very complex Rhino-based system -- complex in terms of scope and 'this' management in particular -- to Nashorn and I'm running into behavior consistent with that, so I'm wondering (and I'm wondering whether I can disable it temporarily or force it to run synchronously or in advance). The reason I ask is that after I make a code change I tend to get an initial error (A) until I run the tests 1-3 times, and then that error disappears and I get a different error (B). The fact that error A seems to be triggered by changing one of the scripts in the system -- I haven't figured out which one, or ones -- leads me toward the theory that there is a background process that leaves a mark on disk at work. I don't yet know what is really going on with Error A is because it's harder to reproduce than Error B -- after 1-3 runs I can reproduce Error B so I will surely figure that one out first. Error B, for what it's worth, seems to have to do with a reference to an argument being lost inside one of the scopes of an object. So a named argument essentially acquires a different value: var Constructor = function(parameter) { this.doIt = function() { parameter.doSomething(); } } In that usage, the parameter reference is somehow being lost (and ends up referring to a value from a different call to the same constructor). I was able to fix one occurrence of this by replacing the construct above with: var Constructor = function(parameter) { this.parameter = parameter; this.doIt = function() { this.parameter.doSomething(); } } If I nail down why this is happening at some point I'll report it, but right now there's so much surrounding code that I can't easily provide a reproduction case or nail down the root cause. And it may not even qualify as a "bug" because (a) it is possible that somewhere some threading rule is being violated in my code, and (b) I am already using a non-public Nashorn API (jdk.nashorn.internal.runtime.Context.evaluateSource(Source,ScriptObject,ScriptObject)) to replicate things the Rhino-based system was able to do with its custom embedding. I sort of doubt the threading explanation because as this is a test suite it is mostly single-threaded, but it's possible I'm missing something. So anyway, back to my question -- is there caching of some kind of code transformation, and if there is, can I disable it so I can narrow down on error A? Or force it to happen synchronously so that I can work around error A? -- David P Caldwell http://www.davidpcaldwell.com/ From attila.szegedi at oracle.com Wed Apr 30 14:42:38 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 30 Apr 2014 16:42:38 +0200 Subject: Nashorn caching of processed scripts? In-Reply-To: References: Message-ID: <3087221F-DA0C-47C6-A90C-C0C03DC4D987@oracle.com> Hi David, no, there's no such caching in the currently released version. Compilation happens on the thread that invokes the relevant javax.script API (e.g. ScriptEngine.eval or Compilable.compile), so there's no asynchrony involved either. The behavior you describe is indeed baffling, but I don't have an explanation for it within the Nashorn compilation pipeline. Attila. On Apr 30, 2014, at 4:04 PM, David P. Caldwell wrote: > Does Nashorn do some kind of background incremental compilation and > caching of compiled scripts somewhere in the local file system? Is it > possible to disable it? > > I'm porting a very complex Rhino-based system -- complex in terms of > scope and 'this' management in particular -- to Nashorn and I'm > running into behavior consistent with that, so I'm wondering (and I'm > wondering whether I can disable it temporarily or force it to run > synchronously or in advance). > > The reason I ask is that after I make a code change I tend to get an > initial error (A) until I run the tests 1-3 times, and then that error > disappears and I get a different error (B). The fact that error A > seems to be triggered by changing one of the scripts in the system -- > I haven't figured out which one, or ones -- leads me toward the theory > that there is a background process that leaves a mark on disk at work. > > I don't yet know what is really going on with Error A is because it's > harder to reproduce than Error B -- after 1-3 runs I can reproduce > Error B so I will surely figure that one out first. > > Error B, for what it's worth, seems to have to do with a reference to > an argument being lost inside one of the scopes of an object. So a > named argument essentially acquires a different value: > > var Constructor = function(parameter) { > this.doIt = function() { > parameter.doSomething(); > } > } > > In that usage, the parameter reference is somehow being lost (and ends > up referring to a value from a different call to the same > constructor). I was able to fix one occurrence of this by replacing > the construct above with: > > var Constructor = function(parameter) { > this.parameter = parameter; > > this.doIt = function() { > this.parameter.doSomething(); > } > } > > If I nail down why this is happening at some point I'll report it, but > right now there's so much surrounding code that I can't easily provide > a reproduction case or nail down the root cause. And it may not even > qualify as a "bug" because (a) it is possible that somewhere some > threading rule is being violated in my code, and (b) I am already > using a non-public Nashorn API > (jdk.nashorn.internal.runtime.Context.evaluateSource(Source,ScriptObject,ScriptObject)) > to replicate things the Rhino-based system was able to do with its > custom embedding. > > I sort of doubt the threading explanation because as this is a test > suite it is mostly single-threaded, but it's possible I'm missing > something. > > So anyway, back to my question -- is there caching of some kind of > code transformation, and if there is, can I disable it so I can narrow > down on error A? Or force it to happen synchronously so that I can > work around error A? > > -- David P Caldwell > http://www.davidpcaldwell.com/ From david at code.davidpcaldwell.com Wed Apr 30 15:00:25 2014 From: david at code.davidpcaldwell.com (David P. Caldwell) Date: Wed, 30 Apr 2014 11:00:25 -0400 Subject: Nashorn caching of processed scripts? In-Reply-To: <3087221F-DA0C-47C6-A90C-C0C03DC4D987@oracle.com> References: <3087221F-DA0C-47C6-A90C-C0C03DC4D987@oracle.com> Message-ID: Thanks, Attila. I'm still in the "bootstrapping" process with Nashorn so I haven't gotten to the point where I can run my scripts in a visual debugger, build and run Nashorn myself, etc. As I advance undoubtedly I'll acquire more tools and be able to further describe problems like the two noted above. I've already solved Error B: a local variable declared inside an object created by new was somehow getting shared across instances of the object (so a generalization of the problem I ran into earlier, where a constructor argument was being shared). Again, assigning the local variable to the object -- to 'this' -- and then using the object property fixed the problem. So if at some point I can narrow down why this is happening I'll let the list know. -- David P. Caldwell http://www.davidpcaldwell.com/ On Wed, Apr 30, 2014 at 10:42 AM, Attila Szegedi wrote: > Hi David, > > no, there's no such caching in the currently released version. Compilation happens on the thread that invokes the relevant javax.script API (e.g. ScriptEngine.eval or Compilable.compile), so there's no asynchrony involved either. The behavior you describe is indeed baffling, but I don't have an explanation for it within the Nashorn compilation pipeline. > > Attila. > > On Apr 30, 2014, at 4:04 PM, David P. Caldwell wrote: > >> Does Nashorn do some kind of background incremental compilation and >> caching of compiled scripts somewhere in the local file system? Is it >> possible to disable it? >> >> I'm porting a very complex Rhino-based system -- complex in terms of >> scope and 'this' management in particular -- to Nashorn and I'm >> running into behavior consistent with that, so I'm wondering (and I'm >> wondering whether I can disable it temporarily or force it to run >> synchronously or in advance). >> >> The reason I ask is that after I make a code change I tend to get an >> initial error (A) until I run the tests 1-3 times, and then that error >> disappears and I get a different error (B). The fact that error A >> seems to be triggered by changing one of the scripts in the system -- >> I haven't figured out which one, or ones -- leads me toward the theory >> that there is a background process that leaves a mark on disk at work. >> >> I don't yet know what is really going on with Error A is because it's >> harder to reproduce than Error B -- after 1-3 runs I can reproduce >> Error B so I will surely figure that one out first. >> >> Error B, for what it's worth, seems to have to do with a reference to >> an argument being lost inside one of the scopes of an object. So a >> named argument essentially acquires a different value: >> >> var Constructor = function(parameter) { >> this.doIt = function() { >> parameter.doSomething(); >> } >> } >> >> In that usage, the parameter reference is somehow being lost (and ends >> up referring to a value from a different call to the same >> constructor). I was able to fix one occurrence of this by replacing >> the construct above with: >> >> var Constructor = function(parameter) { >> this.parameter = parameter; >> >> this.doIt = function() { >> this.parameter.doSomething(); >> } >> } >> >> If I nail down why this is happening at some point I'll report it, but >> right now there's so much surrounding code that I can't easily provide >> a reproduction case or nail down the root cause. And it may not even >> qualify as a "bug" because (a) it is possible that somewhere some >> threading rule is being violated in my code, and (b) I am already >> using a non-public Nashorn API >> (jdk.nashorn.internal.runtime.Context.evaluateSource(Source,ScriptObject,ScriptObject)) >> to replicate things the Rhino-based system was able to do with its >> custom embedding. >> >> I sort of doubt the threading explanation because as this is a test >> suite it is mostly single-threaded, but it's possible I'm missing >> something. >> >> So anyway, back to my question -- is there caching of some kind of >> code transformation, and if there is, can I disable it so I can narrow >> down on error A? Or force it to happen synchronously so that I can >> work around error A? >> >> -- David P Caldwell >> http://www.davidpcaldwell.com/ >