Re: Nashorn on the module-path

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.jupite

Re: Nashorn on the module-path

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

Re: Nashorn on the module-path

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 de

Re: Nashorn on the module-path

On Mon, May 27, 2019 at 11:37 AM Sundararajan Athijegannathan < sundararajan.athijegannat...@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 repro

Re: Nashorn on the module-path

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

Re: Nashorn on the module-path

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 >> a

Re: Nashorn on the module-path

> 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 s

Re: Nashorn on the module-path

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

Re: Nashorn on the module-path

On Thu, May 16, 2019 at 3:23 PM Alan Bateman wrote: > Can you run with -Dsun.reflect.debugModuleAccessChecks and see if > anything is printed? This can be useful to locate exception swallowing. > Given that Nashorn is using method handles it might not help but would > be useful to try. > It did

Re: Nashorn on the module-path

On 16/05/2019 05:02, Christian Stein wrote: : 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 t

Nashorn on the module-path

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 th