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 <
hannes.wallnoe...@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.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 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
>
>

Re: Nashorn on the module-path

[Hannes Wallnöfer]

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

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

Re: Nashorn on the module-path

[Christian Stein]

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

Re: Nashorn on the module-path

[Sundararajan Athijegannathan]

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

Re: Nashorn on the module-path

[James Laskey]

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

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

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

Re: Nashorn on the module-path

[Christian Stein]

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 didn't emit any new line. Is there another debug switch I can enable?