From yikesaroni at gmail.com Wed May 22 15:40:40 2019 From: yikesaroni at gmail.com (yikes aroni) Date: Wed, 22 May 2019 11:40:40 -0400 Subject: ScriptEngines sharing global variables across threads Message-ID: Hi all ... So I thought i had this figured out, but apparently i did not. The way i use ScriptEngines is, for each Java thread, i instantiate a ScriptEngine like this more or less... I have a NashornScriptEngineFactory in a class that is static and final: private static final NashornScriptEngineFactory nashornFactory = new NashornScriptEngineFactory(); And i use that class to generate a script engine for each thread. ScriptEngine scriptEngine = nashornFactory.getScriptEngine() However, i just ran a test in which i generate a few threads (each with a single ScriptEngine instance bound to it), and invoke the JS function var Thread = Java.type('java.lang.Thread'); var fn = function () { myvar = Thread.currentThread().getName(); if (myvar != Thread.currentThread().getName()) { print('From ' + Thread.currentThread().getName() + ': ' + myvar); } }; Note that "myvar" is undeclared, so it goes into the global namespace. Then, what this script does is a) get the name of the current thread and write it to "myvar" in the global namespace; b) check the "myvar" in the global namespace to validate that it is equal to the name of the thread and, if not, to pring out the name of the current thread and the value of the "myvar" variable. Sample of output is >From qtp140110402-35: qtp140110402-34 >From qtp140110402-37: qtp140110402-32 >From qtp140110402-37: qtp140110402-35 So my question is: is it possible to create a multiple threads, bind a scriptengine instance to each of them, and guarantee that they do not share global namespace? thank you! From Roland.Houtman at nl.yokogawa.com Thu May 23 12:48:38 2019 From: Roland.Houtman at nl.yokogawa.com (Houtman, Roland) Date: Thu, 23 May 2019 12:48:38 +0000 Subject: (Adopt)OpenJDK 8 and Nashorn Message-ID: Dear Devs, Today I learned by surprise that the AdoptOpenJDK 8 contains the Nashorn Javascript engine. Glad that Nashorn is included! But I thought that both the WebView(HTML5-browser) and the Nashorn-engine were part of the JavaFX project. And that only the Oracle JDK8 contains JavaFX. So just to make sure; Do all the OpenJDK flavours-builds include the Nashorn engine, or is there more to it? Kind regards, Roland From james.laskey at oracle.com Thu May 23 13:19:55 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Thu, 23 May 2019 10:19:55 -0300 Subject: (Adopt)OpenJDK 8 and Nashorn In-Reply-To: References: Message-ID: <4B6BFC48-516B-4CE2-B7D7-6F6060586FF1@oracle.com> Nashorn is part of the JDK, so should be present. Note however, Nashorn is deprecated until a replacement finds its way in. Cheers, -- Jim > On May 23, 2019, at 9:48 AM, Houtman, Roland wrote: > > Dear Devs, > > Today I learned by surprise that the AdoptOpenJDK 8 contains the Nashorn Javascript engine. > Glad that Nashorn is included! > > But I thought that both the WebView(HTML5-browser) and the Nashorn-engine were part of the JavaFX project. And that only the Oracle JDK8 contains JavaFX. > > So just to make sure; > Do all the OpenJDK flavours-builds include the Nashorn engine, or is there more to it? > > Kind regards, > Roland From james.laskey at oracle.com Sun May 26 10:02:00 2019 From: james.laskey at oracle.com (James Laskey) Date: Sun, 26 May 2019 07:02:00 -0300 Subject: Nashorn on the module-path In-Reply-To: References: <883e6bd5-1240-9523-ec3e-1c457d5f4568@oracle.com> Message-ID: <75B5DE9B-BB22-48E7-BC37-458C3FBAD1C1@oracle.com> Christian, I can?t see the rest of the thread so I don?t have a context. Sent from my iPhone On May 26, 2019, at 6:17 AM, Christian Stein wrote: >> Have you brought this up on nashorn-dev... > > No, but cc-ed that list now. > >> ...as this might require digging into the dynalink linker >> and how method handles are used. > > Do you think it's still worth the effort in regard of Nashorn > being deprecated for removal? Perhaps the underlying > reason may show up on/in a different module, soon. > > Said that, the JUnit 5 team decided to remove "script- > based conditions" from Jupiter. So, "we" won't be affected > by this issue in the near future anymore. > > [1] https://github.com/junit-team/junit5/issues/1882 > > > > On Sun, May 26, 2019 at 10:35 AM Alan Bateman > wrote: > >> On 16/05/2019 15:02, Christian Stein wrote: >> >> : >> >> It didn't emit any new line. Is there another debug switch I can enable? >> >> Have you brought this up on nashorn-dev as this might require digging into >> the dynalink linker and how method handles are used. >> >> -Alan >> From sundararajan.athijegannathan at oracle.com Mon May 27 09:42:01 2019 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 27 May 2019 15:12:01 +0530 Subject: Nashorn on the module-path In-Reply-To: References: <883e6bd5-1240-9523-ec3e-1c457d5f4568@oracle.com> Message-ID: <5CEBB0E9.1040903@oracle.com> How can this be reproduced at out end? Thanks -Sundar On 26/05/19, 2:47 PM, Christian Stein wrote: >> Have you brought this up on nashorn-dev... > No, but cc-ed that list now. > >> ...as this might require digging into the dynalink linker >> and how method handles are used. > Do you think it's still worth the effort in regard of Nashorn > being deprecated for removal? Perhaps the underlying > reason may show up on/in a different module, soon. > > Said that, the JUnit 5 team decided to remove "script- > based conditions" from Jupiter. So, "we" won't be affected > by this issue in the near future anymore. > > [1] https://github.com/junit-team/junit5/issues/1882 > > > > On Sun, May 26, 2019 at 10:35 AM Alan Bateman > wrote: > >> On 16/05/2019 15:02, Christian Stein wrote: >> >> : >> >> It didn't emit any new line. Is there another debug switch I can enable? >> >> Have you brought this up on nashorn-dev as this might require digging into >> the dynalink linker and how method handles are used. >> >> -Alan >> From sundararajan.athijegannathan at oracle.com Mon May 27 09:47:48 2019 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 27 May 2019 15:17:48 +0530 Subject: Nashorn on the module-path In-Reply-To: References: <883e6bd5-1240-9523-ec3e-1c457d5f4568@oracle.com> <5CEBB0E9.1040903@oracle.com> Message-ID: <5CEBB244.1050909@oracle.com> Thanks. I'll check it out. -Sundar On 27/05/19, 3:10 PM, Christian Stein wrote: > On Mon, May 27, 2019 at 11:37 AM Sundararajan Athijegannathan > > wrote: > > How can this be reproduced at out end? > > > I compiled a small example project at [1] that describes and > demonstrates the issue. Please view the README.md file for > details. > > You may reproduce the issue by launching `jshell build.jsh` > within the root directory of the project -- having JDK 11+ installed. > > [1] https://github.com/sormuras/junit5-class-vs-module-path From hannes.wallnoefer at oracle.com Mon May 27 13:28:21 2019 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Mon, 27 May 2019 15:28:21 +0200 Subject: Nashorn on the module-path In-Reply-To: References: <883e6bd5-1240-9523-ec3e-1c457d5f4568@oracle.com> <5CEBB0E9.1040903@oracle.com> Message-ID: Hi Christian, I cloned and tried your example project. When I run the project, I get one successful and one aborted tests in both cases: Module path output: ?? JUnit Jupiter ? ?? CheckTests ? ?? test() ? ?? emitStringRepresentationOfTestModule() ? Assumption failed: module check Class path output: ?? JUnit Jupiter ? ?? CheckTests ? ?? test() ? ?? emitStringRepresentationOfTestModule() ? Assumption failed: unnamed module @306f16f3 Unfortunately it?s quite hard for me to understand what?s going on from there. Your Main class is quite complex with over 800 lines of code, and it seems like the interesting code is in junit-jupiter, which is included in binary form only. Do you think it?s possible to reduce the problem further, ideally to a plain java class? Hannes > Am 27.05.2019 um 11:40 schrieb Christian Stein : > > On Mon, May 27, 2019 at 11:37 AM Sundararajan Athijegannathan < > sundararajan.athijegannathan at oracle.com> wrote: > >> How can this be reproduced at out end? > > > I compiled a small example project at [1] that describes and > demonstrates the issue. Please view the README.md file for > details. > > You may reproduce the issue by launching `jshell build.jsh` > within the root directory of the project -- having JDK 11+ installed. > > [1] https://github.com/sormuras/junit5-class-vs-module-path From sormuras at gmail.com Sun May 26 09:17:32 2019 From: sormuras at gmail.com (Christian Stein) Date: Sun, 26 May 2019 11:17:32 +0200 Subject: Nashorn on the module-path In-Reply-To: References: <883e6bd5-1240-9523-ec3e-1c457d5f4568@oracle.com> Message-ID: > Have you brought this up on nashorn-dev... No, but cc-ed that list now. > ...as this might require digging into the dynalink linker > and how method handles are used. Do you think it's still worth the effort in regard of Nashorn being deprecated for removal? Perhaps the underlying reason may show up on/in a different module, soon. Said that, the JUnit 5 team decided to remove "script- based conditions" from Jupiter. So, "we" won't be affected by this issue in the near future anymore. [1] https://github.com/junit-team/junit5/issues/1882 On Sun, May 26, 2019 at 10:35 AM Alan Bateman wrote: > On 16/05/2019 15:02, Christian Stein wrote: > > : > > It didn't emit any new line. Is there another debug switch I can enable? > > Have you brought this up on nashorn-dev as this might require digging into > the dynalink linker and how method handles are used. > > -Alan > From sormuras at gmail.com Sun May 26 10:05:02 2019 From: sormuras at gmail.com (Christian Stein) Date: Sun, 26 May 2019 12:05:02 +0200 Subject: Nashorn on the module-path In-Reply-To: <75B5DE9B-BB22-48E7-BC37-458C3FBAD1C1@oracle.com> References: <883e6bd5-1240-9523-ec3e-1c457d5f4568@oracle.com> <75B5DE9B-BB22-48E7-BC37-458C3FBAD1C1@oracle.com> Message-ID: Pardon me, James! Here follows the original text copied from "jigaw-dev". Hi everybody, although I'm aware of Nashorn being deprecated for removal and that the JUnit team also tends to remove the experimental support for script-based test execution [2] in the near future, I'd like to learn the reason for why a global script binding behaves differently when running on the module-path or on the class-path. I guess(!), it boils down to swallowed illegal access exception that happens when a simple Java object is put into a Binding. Running on the class-path, an instance of SimpleDynamicMethod from package "jdk.dynalink.beans" is wrap around a method of the bound object. When running on the module-path, the type within the Nashorn is reported as: "undefined". I compiled a small example project [1] that describes and demonstrates the issue. Please view the README.md file for details. You may reproduce the issue by launching `jshell build.jsh` on any platform having JDK 11+ installed within the root directory of the project. Thanks in advance for any hint and clue. Cheers, Christian [1] https://github.com/sormuras/junit5-class-vs-module-path [2] https://junit.org/junit5/docs/current/user-guide/#writing-tests-conditional-execution-scripts On Sun, May 26, 2019 at 12:02 PM James Laskey wrote: > Christian, I can?t see the rest of the thread so I don?t have a context. > > Sent from my iPhone > > On May 26, 2019, at 6:17 AM, Christian Stein wrote: > > >> Have you brought this up on nashorn-dev... > > > > No, but cc-ed that list now. > > > >> ...as this might require digging into the dynalink linker > >> and how method handles are used. > > > > Do you think it's still worth the effort in regard of Nashorn > > being deprecated for removal? Perhaps the underlying > > reason may show up on/in a different module, soon. > > > > Said that, the JUnit 5 team decided to remove "script- > > based conditions" from Jupiter. So, "we" won't be affected > > by this issue in the near future anymore. > > > > [1] https://github.com/junit-team/junit5/issues/1882 > > > > > > > > On Sun, May 26, 2019 at 10:35 AM Alan Bateman > > wrote: > > > >> On 16/05/2019 15:02, Christian Stein wrote: > >> > >> : > >> > >> It didn't emit any new line. Is there another debug switch I can enable? > >> > >> Have you brought this up on nashorn-dev as this might require digging > into > >> the dynalink linker and how method handles are used. > >> > >> -Alan > >> > > From sormuras at gmail.com Mon May 27 09:40:33 2019 From: sormuras at gmail.com (Christian Stein) Date: Mon, 27 May 2019 11:40:33 +0200 Subject: Nashorn on the module-path In-Reply-To: <5CEBB0E9.1040903@oracle.com> References: <883e6bd5-1240-9523-ec3e-1c457d5f4568@oracle.com> <5CEBB0E9.1040903@oracle.com> Message-ID: On Mon, May 27, 2019 at 11:37 AM Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > How can this be reproduced at out end? I compiled a small example project at [1] that describes and demonstrates the issue. Please view the README.md file for details. You may reproduce the issue by launching `jshell build.jsh` within the root directory of the project -- having JDK 11+ installed. [1] https://github.com/sormuras/junit5-class-vs-module-path From sormuras at gmail.com Mon May 27 14:35:21 2019 From: sormuras at gmail.com (Christian Stein) Date: Mon, 27 May 2019 16:35:21 +0200 Subject: Nashorn on the module-path In-Reply-To: References: <883e6bd5-1240-9523-ec3e-1c457d5f4568@oracle.com> <5CEBB0E9.1040903@oracle.com> Message-ID: Hi Hannes, what you see is the expected output. Those assumptions are meant to fail ... perhaps a not so intuitive form of printing the test module name to console. The interesting lines are printed prior to the test run tree: Running the tests on the `--module-path` yields: >> org.junit.jupiter.engine.script.ScriptAccessor$SystemPropertyAccessor at 4716be8b undefined << Compare to what is printed when running on the `--class-path`: >> org.junit.jupiter.engine.script.ScriptAccessor$SystemPropertyAccessor at 275bf9b3 [jdk.dynalink.beans.SimpleDynamicMethod String org.junit.jupiter.engine.script.ScriptAccessor.SystemPropertyAccessor.get(String)] << The "undefined" type is what makes/breaks the script. That said, I'll try to destill it down two or three files... later this week. Cheers, Christian On Mon, May 27, 2019 at 3:30 PM Hannes Walln?fer < hannes.wallnoefer at oracle.com> wrote: > Hi Christian, > > I cloned and tried your example project. When I run the project, I get one > successful and one aborted tests in both cases: > > Module path output: > > ?? JUnit Jupiter ? > ?? CheckTests ? > ?? test() ? > ?? emitStringRepresentationOfTestModule() ? Assumption failed: > module check > > Class path output: > > ?? JUnit Jupiter ? > ?? CheckTests ? > ?? test() ? > ?? emitStringRepresentationOfTestModule() ? Assumption failed: > unnamed module @306f16f3 > > > Unfortunately it?s quite hard for me to understand what?s going on from > there. Your Main class is quite complex with over 800 lines of code, and it > seems like the interesting code is in junit-jupiter, which is included in > binary form only. > > Do you think it?s possible to reduce the problem further, ideally to a > plain java class? > > > Hannes > > > > Am 27.05.2019 um 11:40 schrieb Christian Stein : > > > > On Mon, May 27, 2019 at 11:37 AM Sundararajan Athijegannathan < > > sundararajan.athijegannathan at oracle.com> wrote: > > > >> How can this be reproduced at out end? > > > > > > I compiled a small example project at [1] that describes and > > demonstrates the issue. Please view the README.md file for > > details. > > > > You may reproduce the issue by launching `jshell build.jsh` > > within the root directory of the project -- having JDK 11+ installed. > > > > [1] https://github.com/sormuras/junit5-class-vs-module-path > >