From szegedia at gmail.com Tue Feb 9 20:03:00 2021 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 9 Feb 2021 21:03:00 +0100 Subject: Lowering minimum runtime requirement to Java 11 Message-ID: <4680139B-8DC7-4F20-BB0D-85774760D058@gmail.com> Hey folks, for uniformity, some users would prefer to be able to ship standalone Nashorn with earlier Java versions. Now, I?ve known for some time now that the code compiles cleanly and all tests pass on Java 11 ? that?s as far in the past we can reasonably go. Java 8 is unfortunately a no-go, there?s several APIs missing there (most notably, both Dynalink and JPMS debut in Java 9, but there?s dependence on some other smaller API changes.) It also looks like if standalone Nashorn is present in the system, it is picked up by javax.script.* system when a JavaScript runtime is requested, to wit, here?s my results with jrunscript on Java 11: jrunscript -q Language ECMAScript ECMA - 262 Edition 5.1 implementation "Oracle Nashorn" 11.0.10 $ jrunscript -J--module-path -J../../build/nashorn/dist:../../build/nashorn/dependencies -q Language ECMAScript ECMA - 262 Edition 5.1 implementation "Oracle Nashorn" 15.1.1 As you can see, putting the location of Nashorn and its dependencies on the module path selects it ? the version number it prints is 15.1.1. Unfortunately, the same doesn?t seem to work for classpath, but? shrug, at this point I?d settle for providing one path for backwards compatibility. So? I?m thinking of putting a 15.2 that?d functionally be identical to 15.1.1 just compiled for Java 11. There?s one minor point to consider: should it be compiled with Java 15 compiler, but targeting 11, or should it simply be compiled with Java 11 compiler? Is there any advantage in using javac from 15 targeting 11? Attila. From dalibor.topic at oracle.com Fri Feb 12 00:36:54 2021 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 12 Feb 2021 01:36:54 +0100 Subject: Lowering minimum runtime requirement to Java 11 In-Reply-To: <4680139B-8DC7-4F20-BB0D-85774760D058@gmail.com> References: <4680139B-8DC7-4F20-BB0D-85774760D058@gmail.com> Message-ID: On 09.02.2021 21:03, Attila Szegedi wrote: > There?s one minor point to consider: should it be compiled with Java 15 compiler, but targeting 11, or should it simply be compiled with Java 11 compiler? Is there any advantage in using javac from 15 targeting 11? I think it's usually better to set the javac --release flag to 11 in order to keep your options open to use the latest JDK release during development, than to limit yourself to building the code with the lowest supported release. cheers, dalibor topic -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 , Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From Rony.Flatscher at wu.ac.at Thu Feb 25 15:31:28 2021 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Thu, 25 Feb 2021 16:31:28 +0100 Subject: Question ad "arguments" and ScriptEngine.ARGV Message-ID: <4d861988-13b5-96a9-e2d9-bfe16417ee21@wu.ac.at> While using Nashorn from Java 8 in the context of a Java based web server for which I authored a tag library for scripting engines, I noted that "arguments" does not get set to the arguments passed via the engine ScriptContext [1] entry ScriptEngine.ARGV [2] (i.e. "javax.script.argv" a single dimensioned Java array of type Object of positional arguments) when invoking the Nashorn script via engine.eval(script). Is this really to be expected? If so, how can I cause the Nashorn engine to supply the Java arguments to the script or have the script fetch the supplied arguments in a different way? To illustrate, this is an example of three Nashorn fragments in a single JSP (one 'script' element with type 'nashorn', one 'expr' element with type 'javascript' and a 'script' element with type 'javascript'): <%@ page session="false" pageEncoding="UTF-8" contentType="text/html; charset=UTF-8" %> <%@ taglib uri="/WEB-INF/script-jsr223.tld" prefix="s" %> Sample Application JSP Page Using JavaScript Via JSR-223 (Title)

Sample Application JSP Page Using JavaScript Via Script (JSR223)

This is the output of a JSP page that is part of the Hello, World application.

Here is the text partially generated by a simple JavaScript script:
*****print("

Hello, world, this is Nashorn (JavaScript) speaking at ", Date(), "

")****print("

arguments: ", arguments, "

")*****

Here is the text generated by a simple JavaScript expression:

It is now exactly *Date()*.

The following script includes a syntax error (division by zero) intentionally. The error in the script will not inhibit the creation of the page.

*****print('cause a Nashorn/JavaScript error ...')****throw Error("This error is just for testing how the host behaves ...")*****

Done.

The resulting HTML text will show "arguments: " but no arguments going with it, although there are three arguments supplied via the engine scope ScriptContext with the entry ScriptEngine.ARGV as mentioned above. Here the resulting HTML text from the JSP above: Sample Application JSP Page Using JavaScript Via JSR-223 (Title)

Sample Application JSP Page Using JavaScript Via Script (JSR223)

This is the output of a JSP page that is part of the Hello, World application.

Here is the text partially generated by a simple JavaScript script:

Hello, world, this is Nashorn (JavaScript) speaking at Thu Feb 25 2021 16:30:38 GMT+0100 (CET)

arguments:

Here is the text generated by a simple JavaScript expression:

It is now exactly Thu Feb 25 2021 16:30:38 GMT+0100 (CET).

The following script includes a syntax error (division by zero) intentionally. The error in the script will not inhibit the creation of the page.

cause a Nashorn/JavaScript error ...

Done.

---rony [1] "Java Scripting Framework (JSR-223)": [2] "javax.script.ScriptContext": [3] "javax.script.ScriptEngine": [4] "Nashorn and Shell Scripting": P.S.: It seems from samples on the Internet that when using the shell to invoke Nashorn that the arguments get passed on to the script [4]. From Rony.Flatscher at wu.ac.at Thu Feb 25 15:36:15 2021 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Thu, 25 Feb 2021 16:36:15 +0100 Subject: Question ad "arguments" and ScriptEngine.ARGV In-Reply-To: <4d861988-13b5-96a9-e2d9-bfe16417ee21@wu.ac.at> References: <4d861988-13b5-96a9-e2d9-bfe16417ee21@wu.ac.at> Message-ID: Keep forgetting, that adding boldness breaks the text. Here the JSP text without any styling (hence without those injected asterisks): <%@ page session="false" pageEncoding="UTF-8" contentType="text/html; charset=UTF-8" %> <%@ taglib uri="/WEB-INF/script-jsr223.tld" prefix="s" %> Sample Application JSP Page Using JavaScript Via JSR-223 (Title)

Sample Application JSP Page Using JavaScript Via Script (JSR223)

This is the output of a JSP page that is part of the Hello, World application.

Here is the text partially generated by a simple JavaScript script:
print("

Hello, world, this is Nashorn (JavaScript) speaking at ", Date(), "

") print("

arguments: ", arguments, "

")

Here is the text generated by a simple JavaScript expression:

It is now exactly Date().

The following script includes a syntax error (division by zero) intentionally. The error in the script will not inhibit the creation of the page.

print('cause a Nashorn/JavaScript error ...') throw Error("This error is just for testing how the host behaves ...")

Done.

---rony On 25.02.2021 16:31, Rony G. Flatscher wrote: > While using Nashorn from Java 8 in the context of a Java based web server for which I authored a tag > library for scripting engines, I noted that "arguments" does not get set to the arguments passed via > the engine ScriptContext [1] entry ScriptEngine.ARGV [2] (i.e. "javax.script.argv" a single > dimensioned Java array of type Object of positional arguments) when invoking the Nashorn script via > engine.eval(script). > > Is this really to be expected? If so, how can I cause the Nashorn engine to supply the Java > arguments to the script or have the script fetch the supplied arguments in a different way? > > To illustrate, this is an example of three Nashorn fragments in a single JSP (one 'script' element > with type 'nashorn', one 'expr' element with type 'javascript' and a 'script' element with type > 'javascript'): > > <%@ page session="false" pageEncoding="UTF-8" contentType="text/html; charset=UTF-8" %> > <%@ taglib uri="/WEB-INF/script-jsr223.tld" prefix="s" %> > > > > > > Sample Application JSP Page Using JavaScript Via JSR-223 (Title) > > > >

> >
>

Sample Application JSP Page Using JavaScript Via Script (JSR223)

> This is the output of a JSP page that is part of the Hello, World > application. > >

Here is the text partially generated by a simple JavaScript script:
> > > *****print("

Hello, world, this is Nashorn (JavaScript) speaking at ", Date(), "

")****print("

arguments: ", arguments, "

")***** > >

Here is the text generated by a simple JavaScript expression:
> > >

It is now exactly *Date()*.

> >

The following script includes a syntax error (division by zero) intentionally. > The error in the script will not inhibit the creation of the page.

> > > *****print('cause a Nashorn/JavaScript error ...')****throw Error("This error is just for testing how the host behaves ...")***** > >

Done.

> > > > > The resulting HTML text will show "arguments: " but no arguments going with it, although there are > three arguments supplied via the engine scope ScriptContext with the entry ScriptEngine.ARGV as > mentioned above. > > Here the resulting HTML text from the JSP above: > > > > > > > > > Sample Application JSP Page Using JavaScript Via JSR-223 (Title) > > > >

> >
>

Sample Application JSP Page Using JavaScript Via Script (JSR223)

> This is the output of a JSP page that is part of the Hello, World > application. > >

Here is the text partially generated by a simple JavaScript script:
> > >

Hello, world, this is Nashorn (JavaScript) speaking at Thu Feb 25 2021 16:30:38 GMT+0100 (CET)

>

arguments:

> > >

Here is the text generated by a simple JavaScript expression:
> > >

It is now exactly Thu Feb 25 2021 16:30:38 GMT+0100 (CET).

> >

The following script includes a syntax error (division by zero) intentionally. > The error in the script will not inhibit the creation of the page.

> > > cause a Nashorn/JavaScript error ... > > >

Done.

> > > > > ---rony > > [1] "Java Scripting Framework (JSR-223)": > > [2] "javax.script.ScriptContext": > > [3] "javax.script.ScriptEngine": > > [4] "Nashorn and Shell Scripting": > > > P.S.: It seems from samples on the Internet that when using the shell to invoke Nashorn that the > arguments get passed on to the script [4]. > From bbiktop at gmail.com Sat Feb 27 13:53:53 2021 From: bbiktop at gmail.com (Viktor Remennik) Date: Sat, 27 Feb 2021 15:53:53 +0200 Subject: Terminate running script thread Message-ID: <31DDC95A-5C4E-43C8-B5C0-0EBE4B1E61E3@gmail.com> Is there already a way to terminate a running script? I found some old discussions and articles regarding it, is there any progress these days? It would be great to have something like CompiledScript#stop or something like interrupt handler inside the Nashorn eval, because currently I have to use Thread#stop with all its disadvantages and problems. I have user defined scripts running in my application, users are technicians but still could make a mistakes, so I'd like to control the script execution time and kill scripts threads if configured maximum execution time limit has been exceeded. As Nashorn is standalone now, I suppose I, or maybe someone more experienced in Nashorn's internals, could try to implement this, but I'd like to check first, isn't it is already implemented. https://stackoverflow.com/questions/24855182/interrupt-java-thread-running-nashorn-script http://blog.getsandbox.com/2018/01/15/nashorn-interupt/ Thank you Viktor From szegedia at gmail.com Sat Feb 27 17:07:55 2021 From: szegedia at gmail.com (Attila Szegedi) Date: Sat, 27 Feb 2021 18:07:55 +0100 Subject: Terminate running script thread In-Reply-To: <31DDC95A-5C4E-43C8-B5C0-0EBE4B1E61E3@gmail.com> References: <31DDC95A-5C4E-43C8-B5C0-0EBE4B1E61E3@gmail.com> Message-ID: No, there?s no support for that. Nashorn compiles all scripts to JVM bytecode and runs them as such. There?s no more of a way to stop that code than any Java code. Even if there was some other way, I don?t see how would stopping a thread be materially better than what Thread#stop provides. I?m not saying there?s no better way, I?m just saying I don?t see it. I?m open to suggestion on how could a different mechanism be better. I can imagine that if someone wanted something like this, they could implement a ClassFileTransformer and transform the bytecode to maybe add a check for some variable on the back edges of all loops? That?d help with infinite loops in Java code invoked from scripts as well. Of course, if the variable isn?t global, then you?d need to pass it around, or retrieve it from a thread local, which could be expensive (you could add a local variable for every loop to count and only check the thread local every 1000 iterations?) And again, how would the behavior of acting on the ?stop? flag be different than a stack unwind through a ThreadDeath? Lots of questions, but I?m happy to listen and discuss. Attila. > On 2021. Feb 27., at 14:53, Viktor Remennik wrote: > > Is there already a way to terminate a running script? I found some old discussions and articles regarding it, is there any progress these days? It would be great to have something like CompiledScript#stop or something like interrupt handler inside the Nashorn eval, because currently I have to use Thread#stop with all its disadvantages and problems. I have user defined scripts running in my application, users are technicians but still could make a mistakes, so I'd like to control the script execution time and kill scripts threads if configured maximum execution time limit has been exceeded. As Nashorn is standalone now, I suppose I, or maybe someone more experienced in Nashorn's internals, could try to implement this, but I'd like to check first, isn't it is already implemented. > > https://stackoverflow.com/questions/24855182/interrupt-java-thread-running-nashorn-script > http://blog.getsandbox.com/2018/01/15/nashorn-interupt/ > > > Thank you > > Viktor From bbiktop at gmail.com Sat Feb 27 17:59:09 2021 From: bbiktop at gmail.com (Viktor Remennik) Date: Sat, 27 Feb 2021 19:59:09 +0200 Subject: Terminate running script thread In-Reply-To: References: Message-ID: I didn?t checked it yet, just wanted to ask first. It is implemented in graal, will look there to check how. The first idea i thought, was to inject some global var checking in loops, but i am not a big specialist in that area yet. Will study it further then, thank you! Kind regards, Viktor > On 27 Feb 2021, at 19:07, Attila Szegedi wrote: > > ?No, there?s no support for that. Nashorn compiles all scripts to JVM bytecode and runs them as such. There?s no more of a way to stop that code than any Java code. Even if there was some other way, I don?t see how would stopping a thread be materially better than what Thread#stop provides. I?m not saying there?s no better way, I?m just saying I don?t see it. I?m open to suggestion on how could a different mechanism be better. > > I can imagine that if someone wanted something like this, they could implement a ClassFileTransformer and transform the bytecode to maybe add a check for some variable on the back edges of all loops? That?d help with infinite loops in Java code invoked from scripts as well. Of course, if the variable isn?t global, then you?d need to pass it around, or retrieve it from a thread local, which could be expensive (you could add a local variable for every loop to count and only check the thread local every 1000 iterations?) And again, how would the behavior of acting on the ?stop? flag be different than a stack unwind through a ThreadDeath? > > Lots of questions, but I?m happy to listen and discuss. > > Attila. > > >> On 2021. Feb 27., at 14:53, Viktor Remennik wrote: >> >> Is there already a way to terminate a running script? I found some old discussions and articles regarding it, is there any progress these days? It would be great to have something like CompiledScript#stop or something like interrupt handler inside the Nashorn eval, because currently I have to use Thread#stop with all its disadvantages and problems. I have user defined scripts running in my application, users are technicians but still could make a mistakes, so I'd like to control the script execution time and kill scripts threads if configured maximum execution time limit has been exceeded. As Nashorn is standalone now, I suppose I, or maybe someone more experienced in Nashorn's internals, could try to implement this, but I'd like to check first, isn't it is already implemented. >> >> https://stackoverflow.com/questions/24855182/interrupt-java-thread-running-nashorn-script >> http://blog.getsandbox.com/2018/01/15/nashorn-interupt/ >> >> >> Thank you >> >> Viktor > From szegedia at gmail.com Sat Feb 27 19:10:26 2021 From: szegedia at gmail.com (Attila Szegedi) Date: Sat, 27 Feb 2021 20:10:26 +0100 Subject: Terminate running script thread In-Reply-To: References: Message-ID: Thanks, by all means report back with what you found :-) Attila. > On 2021. Feb 27., at 18:59, Viktor Remennik wrote: > > I didn?t checked it yet, just wanted to ask first. It is implemented in graal, will look there to check how. The first idea i thought, was to inject some global var checking in loops, but i am not a big specialist in that area yet. Will study it further then, thank you! > > Kind regards, > Viktor > >> On 27 Feb 2021, at 19:07, Attila Szegedi wrote: >> >> ?No, there?s no support for that. Nashorn compiles all scripts to JVM bytecode and runs them as such. There?s no more of a way to stop that code than any Java code. Even if there was some other way, I don?t see how would stopping a thread be materially better than what Thread#stop provides. I?m not saying there?s no better way, I?m just saying I don?t see it. I?m open to suggestion on how could a different mechanism be better. >> >> I can imagine that if someone wanted something like this, they could implement a ClassFileTransformer and transform the bytecode to maybe add a check for some variable on the back edges of all loops? That?d help with infinite loops in Java code invoked from scripts as well. Of course, if the variable isn?t global, then you?d need to pass it around, or retrieve it from a thread local, which could be expensive (you could add a local variable for every loop to count and only check the thread local every 1000 iterations?) And again, how would the behavior of acting on the ?stop? flag be different than a stack unwind through a ThreadDeath? >> >> Lots of questions, but I?m happy to listen and discuss. >> >> Attila. >> >> >>> On 2021. Feb 27., at 14:53, Viktor Remennik wrote: >>> >>> Is there already a way to terminate a running script? I found some old discussions and articles regarding it, is there any progress these days? It would be great to have something like CompiledScript#stop or something like interrupt handler inside the Nashorn eval, because currently I have to use Thread#stop with all its disadvantages and problems. I have user defined scripts running in my application, users are technicians but still could make a mistakes, so I'd like to control the script execution time and kill scripts threads if configured maximum execution time limit has been exceeded. As Nashorn is standalone now, I suppose I, or maybe someone more experienced in Nashorn's internals, could try to implement this, but I'd like to check first, isn't it is already implemented. >>> >>> https://stackoverflow.com/questions/24855182/interrupt-java-thread-running-nashorn-script >>> http://blog.getsandbox.com/2018/01/15/nashorn-interupt/ >>> >>> >>> Thank you >>> >>> Viktor >> From forax at univ-mlv.fr Sat Feb 27 19:46:54 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 27 Feb 2021 20:46:54 +0100 (CET) Subject: Terminate running script thread In-Reply-To: References: <31DDC95A-5C4E-43C8-B5C0-0EBE4B1E61E3@gmail.com> Message-ID: <1750511023.1096198.1614455214642.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Attila Szegedi" > ?: "Viktor Remennik" > Cc: "nashorn-dev" > Envoy?: Samedi 27 F?vrier 2021 18:07:55 > Objet: Re: Terminate running script thread Hi, > No, there?s no support for that. Nashorn compiles all scripts to JVM bytecode > and runs them as such. There?s no more of a way to stop that code than any Java > code. Even if there was some other way, I don?t see how would stopping a thread > be materially better than what Thread#stop provides. I?m not saying there?s no > better way, I?m just saying I don?t see it. I?m open to suggestion on how could > a different mechanism be better. > > I can imagine that if someone wanted something like this, they could implement a > ClassFileTransformer and transform the bytecode to maybe add a check for some > variable on the back edges of all loops? That?d help with infinite loops in > Java code invoked from scripts as well. Of course, if the variable isn?t > global, then you?d need to pass it around, or retrieve it from a thread local, > which could be expensive (you could add a local variable for every loop to > count and only check the thread local every 1000 iterations?) And again, how > would the behavior of acting on the ?stop? flag be different than a stack > unwind through a ThreadDeath? > > Lots of questions, but I?m happy to listen and discuss. Loom has a mechanism to preempt a coroutine https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/Continuation.html#tryPreempt(java.lang.Thread) It uses the safepoint mechanism already present in the VM. So if you run on a pool of virtual threads and ask gently, it may work. > > Attila. R?mi > > >> On 2021. Feb 27., at 14:53, Viktor Remennik wrote: >> >> Is there already a way to terminate a running script? I found some old >> discussions and articles regarding it, is there any progress these days? It >> would be great to have something like CompiledScript#stop or something like >> interrupt handler inside the Nashorn eval, because currently I have to use >> Thread#stop with all its disadvantages and problems. I have user defined >> scripts running in my application, users are technicians but still could make a >> mistakes, so I'd like to control the script execution time and kill scripts >> threads if configured maximum execution time limit has been exceeded. As >> Nashorn is standalone now, I suppose I, or maybe someone more experienced in >> Nashorn's internals, could try to implement this, but I'd like to check first, >> isn't it is already implemented. >> >> https://stackoverflow.com/questions/24855182/interrupt-java-thread-running-nashorn-script >> >> http://blog.getsandbox.com/2018/01/15/nashorn-interupt/ >> >> >> >> Thank you >> > > Viktor