Nashorn on the module-path

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Nashorn on the module-path

Christian Stein
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
Reply | Threaded
Open this post in threaded view
|

Re: Nashorn on the module-path

Alan Bateman
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 the bound object. When running on the module-path, the
> type within the Nashorn is reported as: "undefined".
>
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.

-Alan
Reply | Threaded
Open this post in threaded view
|

Re: Nashorn on the module-path

Christian Stein
On Thu, May 16, 2019 at 3:23 PM Alan Bateman <[hidden email]>
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 didn't emit any new line. Is there another debug switch I can enable?
Reply | Threaded
Open this post in threaded view
|

Re: Nashorn on the module-path

Alan Bateman
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
Reply | Threaded
Open this post in threaded view
|

Re: Nashorn on the module-path

Christian Stein
> 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 <[hidden email]>
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
>
Reply | Threaded
Open this post in threaded view
|

Re: Nashorn on the module-path

Jim Laskey (Oracle)
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 <[hidden email]> 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 <[hidden email]>
> 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
>>

Reply | Threaded
Open this post in threaded view
|

Re: Nashorn on the module-path

sundararajan.athijegannathan
In reply to this post by Christian Stein
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<[hidden email]>
> 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
>>
Reply | Threaded
Open this post in threaded view
|

Re: Nashorn on the module-path

Christian Stein
On Mon, May 27, 2019 at 11:37 AM Sundararajan Athijegannathan <
[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Nashorn on the module-path

sundararajan.athijegannathan
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
> <[hidden email]
> <mailto:[hidden email]>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Nashorn on the module-path

Hannes Wallnoefer
In reply to this post by Christian Stein
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 <[hidden email]>:
>
> On Mon, May 27, 2019 at 11:37 AM Sundararajan Athijegannathan <
> [hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Nashorn on the module-path

Christian Stein
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@4716be8b
undefined
<<


Compare to what is printed when running on  the `--class-path`:

>>
org.junit.jupiter.engine.script.ScriptAccessor$SystemPropertyAccessor@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 <
[hidden email]> 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 <[hidden email]>:
> >
> > On Mon, May 27, 2019 at 11:37 AM Sundararajan Athijegannathan <
> > [hidden email]> 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
>
>