Re: Nashorn Standalone 15.3 engine returned is null

[Attila Szegedi]

Can you check if this is specific to 15.3, or does it also not work with e.g. 
15.2?

Attila.

> On 2021. Jul 15., at 12:49, Andreas Mueller  wrote:
> 
> Tested it again with listing the engine right befor getByName:
> 
> List factories = manager.getEngineFactories();
> for (int i = 0; i < factories.size(); i++) {
> ctx.logSwiftlet.logInformation(ctx.streamsSwiftlet.getName(), "name=" + 
> factories.get(i).getEngineName() +
> ", version=" + factories.get(i).getEngineVersion() + ", language 
> name=" + factories.get(i).getLanguageName() +
> ", language version=" + factories.get(i).getLanguageVersion() +
> ", names=" + factories.get(i).getNames());
> }
> engine = manager.getEngineByName((String) 
> entity.getProperty("script-language").getValue());
> 
> It is listed but returns null. This code is executed by a dedicated class 
> loader.
> 
> -- 
> Andreas Mueller
> IIT Software GmbH
> http://www.swiftmq.com 
> 
> 
> 
>> On 15. Jul 2021, at 10:59, Andreas Mueller > > wrote:
>> 
>> Hi Attila,
>> 
>> thanks but didn’t work in my environment. 
>> 
>> Tried every combination (using “nashorn”, “JavaScript” as name, using class 
>> path, using module path). 
>> 
>> Fact is, it lists the Nashorn engine correctly:
>> 
>> ScriptEngineManager manager = new ScriptEngineManager();
>> List factories = manager.getEngineFactories();
>> for (int i = 0; i < factories.size(); i++) {
>> ctx.logSwiftlet.logInformation(ctx.streamsSwiftlet.getName(), "name=" + 
>> factories.get(i).getEngineName() +
>> ", version=" + factories.get(i).getEngineVersion() + ", language 
>> name=" + factories.get(i).getLanguageName() +
>> ", language version=" + factories.get(i).getLanguageVersion() +
>> ", names=" + factories.get(i).getNames());
>> }
>> 
>> 2021-07-15 10:51:37.948/sys$streams/INFORMATION/name=OpenJDK Nashorn, 
>> version=15.3, language name=ECMAScript, language version=ECMA - 262 Edition 
>> 5.1, names=[nashorn, Nashorn, js, JS, JavaScript, javascript, ECMAScript, 
>> ecmascript]
>> 
>> But return null here:
>> 
>> engine = manager.getEngineByName(“JavaScript”);
>> 
>> I suspect it might have to do with class loaders as we use a dedicated class 
>> loader for every script:
>> 
>> ScriptEngineManager manager = new ScriptEngineManager();
>> ClassLoader classLoader = createClassLoader();
>> streamContext.classLoader = classLoader;
>> Thread.currentThread().setContextClassLoader(classLoader);
>> 
>> Thanks,
>> Andreas
>> 
>> -- 
>> Andreas Mueller
>> IIT Software GmbH
>> http://www.swiftmq.com 
>> 
>> 
>> 
>>> On 13. Jul 2021, at 16:01, Attila Szegedi  wrote:
>>> 
>>> I’m honestly not sure. I have this very small test program:
>>> 
>>> import javax.script.*;
>>> 
>>> public class X {
>>>public static void main(String[] args) throws ScriptException {
>>> ScriptEngineManager factory = new ScriptEngineManager(); 
>>> ScriptEngine engine = factory.getEngineByName("JavaScript"); 
>>> engine.eval("function f() { print('Hello, World!'); } f()");
>>>}
>>> }
>>> 
>>> if I put it in a directory where I checked out Nashorn repo, and run “ant 
>>> jar” to build the JAR file and run:
>>> 
>>> java --module-path build/nashorn/dist:build/nashorn/dependencies X.java
>>> 
>>> It prints "Hello, World!” as expected, so it definitely find the engine 
>>> under the name “JavaScript". I can also run it with classpath instead of 
>>> module path:
>>> 
>>> java -cp 
>>> build/nashorn/dist/nashorn.jar:build/nashorn/dependencies/asm-7.3.1.jar:build/nashorn/dependencies/asm-util-7.3.1.jar
>>>  X.java
>>> 
>>> and that works too. Do you have the dependencies (ASM) too?
>>> 
>>> Attila.
>>> 
 On 2021. Jul 13., at 15:33, Andreas Mueller  wrote:
 
 Hi,
 
 I’ve added Nashorn to Java 15 and it is properly displayed when listing 
 the engines:
 
 2021-07-13 15:14:30.233/sys$streams/INFORMATION/starting, available 
 Scripting Engines:
 2021-07-13 15:14:30.246/sys$streams/INFORMATION/name=OpenJDK Nashorn, 
 version=15.3, language name=ECMAScript, language version=ECMA - 262 
 Edition 5.1, names=[nashorn, Nashorn, js, JS, JavaScript, javascript, 
 ECMAScript, ecmascript]
 
 However, when I get the engine with name “JavaScript” it returns null:
 
 engine = manager.getEngineByName((String) 
 entity.getProperty("script-language").getValue());
 if (engine == null)
throw new Exception("Engine for script-language '" + 
 entity.getProperty("script-language").getValue() + "' not found!");
 
 2021-07-13 15:14:30.361/ERROR/Exception occured: java.lang.Exception: 
 Engine for script-language 'JavaScript' not found!
 
 Any ideas what the problem could be?
 
 Thanks,
 Andreas
 -- 
 Andreas Mueller
 IIT Software GmbH
 http://www.swiftmq.com  
 
 
>>> 
>> 

Re: Nashorn Standalone 15.3 engine returned is null

[Andreas Mueller]

Tested it again with listing the engine right befor getByName:

List factories = manager.getEngineFactories();
for (int i = 0; i < factories.size(); i++) {
    ctx.logSwiftlet.logInformation(ctx.streamsSwiftlet.getName(), "name=" + 
factories.get(i).getEngineName() +
            ", version=" + factories.get(i).getEngineVersion() + ", language 
name=" + factories.get(i).getLanguageName() +
            ", language version=" + factories.get(i).getLanguageVersion() +
            ", names=" + factories.get(i).getNames());
}
engine = manager.getEngineByName((String) 
entity.getProperty("script-language").getValue());

It is listed but returns null. This code is executed by a dedicated class 
loader.

-- 
Andreas Mueller
IIT Software GmbH
http://www.swiftmq.com  



On 15. Jul 2021, at 10:59, Andreas Mueller mailto:a...@iit.de> > 
wrote:

Hi Attila,

thanks but didn’t work in my environment. 

Tried every combination (using “nashorn”, “JavaScript” as name, using class 
path, using module path). 

Fact is, it lists the Nashorn engine correctly:

ScriptEngineManager manager = new ScriptEngineManager();
List factories = manager.getEngineFactories();
for (int i = 0; i < factories.size(); i++) {
    ctx.logSwiftlet.logInformation(ctx.streamsSwiftlet.getName(), "name=" + 
factories.get(i).getEngineName() +
            ", version=" + factories.get(i).getEngineVersion() + ", language 
name=" + factories.get(i).getLanguageName() +
            ", language version=" + factories.get(i).getLanguageVersion() +
            ", names=" + factories.get(i).getNames());
}

2021-07-15 10:51:37.948/sys$streams/INFORMATION/name=OpenJDK Nashorn, 
version=15.3, language name=ECMAScript, language version=ECMA - 262 Edition 
5.1, names=[nashorn, Nashorn, js, JS, JavaScript, javascript, ECMAScript, 
ecmascript]

But return null here:

engine = manager.getEngineByName(“JavaScript”);

I suspect it might have to do with class loaders as we use a dedicated class 
loader for every script:

ScriptEngineManager manager = new ScriptEngineManager();
ClassLoader classLoader = createClassLoader();
streamContext.classLoader = classLoader;
Thread.currentThread().setContextClassLoader(classLoader);

Thanks,
Andreas

-- 
Andreas Mueller
IIT Software GmbH
http://www.swiftmq.com  



On 13. Jul 2021, at 16:01, Attila Szegedi  wrote:

I’m honestly not sure. I have this very small test program:

import javax.script.*;

public class X {
   public static void main(String[] args) throws ScriptException {
ScriptEngineManager factory = new ScriptEngineManager(); 
ScriptEngine engine = factory.getEngineByName("JavaScript"); 
engine.eval("function f() { print('Hello, World!'); } f()");
   }
}

if I put it in a directory where I checked out Nashorn repo, and run “ant jar” 
to build the JAR file and run:

java --module-path build/nashorn/dist:build/nashorn/dependencies X.java

It prints "Hello, World!” as expected, so it definitely find the engine under 
the name “JavaScript". I can also run it with classpath instead of module path:

java -cp 
build/nashorn/dist/nashorn.jar:build/nashorn/dependencies/asm-7.3.1.jar:build/nashorn/dependencies/asm-util-7.3.1.jar
 X.java

and that works too. Do you have the dependencies (ASM) too?

Attila.

On 2021. Jul 13., at 15:33, Andreas Mueller  wrote:

Hi,

I’ve added Nashorn to Java 15 and it is properly displayed when listing the 
engines:

2021-07-13 15:14:30.233/sys$streams/INFORMATION/starting, available Scripting 
Engines:
2021-07-13 15:14:30.246/sys$streams/INFORMATION/name=OpenJDK Nashorn, 
version=15.3, language name=ECMAScript, language version=ECMA - 262 Edition 
5.1, names=[nashorn, Nashorn, js, JS, JavaScript, javascript, ECMAScript, 
ecmascript]

However, when I get the engine with name “JavaScript” it returns null:

engine = manager.getEngineByName((String) 
entity.getProperty("script-language").getValue());
if (engine == null)
   throw new Exception("Engine for script-language '" + 
entity.getProperty("script-language").getValue() + "' not found!");

2021-07-13 15:14:30.361/ERROR/Exception occured: java.lang.Exception: Engine 
for script-language 'JavaScript' not found!

Any ideas what the problem could be?

Thanks,
Andreas
-- 
Andreas Mueller
IIT Software GmbH
http://www.swiftmq.com  

Re: Nashorn Standalone 15.3 engine returned is null

[Andreas Mueller]

Here are the jar files I use:

am@Mac-mini scripts % ll ../nashorn
total 4968
-rwxr-xr-x  1 am  staff   121836 Jul 11 14:31 asm-7.3.1.jar
-rwxr-xr-x  1 am  staff    33446 Jul 11 14:31 asm-analysis-7.3.1.jar
-rwxr-xr-x  1 am  staff    71548 Jul 11 14:31 asm-commons-7.3.1.jar
-rwxr-xr-x  1 am  staff    52826 Jul 11 14:31 asm-tree-7.3.1.jar
-rwxr-xr-x  1 am  staff    84817 Jul 11 14:31 asm-util-7.3.1.jar
-rwxr-xr-x  1 am  staff  2167288 Jul 11 14:31 nashorn-core-15.3.jar

This is my module path:

--add-modules org.openjdk.nashorn --module-path ../nashorn

-- 
Andreas Mueller
IIT Software GmbH
http://www.swiftmq.com  

Re: Nashorn Standalone 15.3 engine returned is null

[Andreas Mueller]

Hi Attila,

thanks but didn’t work in my environment. 

Tried every combination (using “nashorn”, “JavaScript” as name, using class 
path, using module path). 

Fact is, it lists the Nashorn engine correctly:

ScriptEngineManager manager = new ScriptEngineManager();
List factories = manager.getEngineFactories();
for (int i = 0; i < factories.size(); i++) {
    ctx.logSwiftlet.logInformation(ctx.streamsSwiftlet.getName(), "name=" + 
factories.get(i).getEngineName() +
            ", version=" + factories.get(i).getEngineVersion() + ", language 
name=" + factories.get(i).getLanguageName() +
            ", language version=" + factories.get(i).getLanguageVersion() +
            ", names=" + factories.get(i).getNames());
}

2021-07-15 10:51:37.948/sys$streams/INFORMATION/name=OpenJDK Nashorn, 
version=15.3, language name=ECMAScript, language version=ECMA - 262 Edition 
5.1, names=[nashorn, Nashorn, js, JS, JavaScript, javascript, ECMAScript, 
ecmascript]

But return null here:

engine = manager.getEngineByName(“JavaScript”);

I suspect it might have to do with class loaders as we use a dedicated class 
loader for every script:

ScriptEngineManager manager = new ScriptEngineManager();
ClassLoader classLoader = createClassLoader();
streamContext.classLoader = classLoader;
Thread.currentThread().setContextClassLoader(classLoader);

Thanks,
Andreas

-- 
Andreas Mueller
IIT Software GmbH
http://www.swiftmq.com  



On 13. Jul 2021, at 16:01, Attila Szegedi mailto:szege...@gmail.com> > wrote:

I’m honestly not sure. I have this very small test program:

import javax.script.*;

public class X {
   public static void main(String[] args) throws ScriptException {
ScriptEngineManager factory = new ScriptEngineManager(); 
ScriptEngine engine = factory.getEngineByName("JavaScript"); 
engine.eval("function f() { print('Hello, World!'); } f()");
   }
}

if I put it in a directory where I checked out Nashorn repo, and run “ant jar” 
to build the JAR file and run:

java --module-path build/nashorn/dist:build/nashorn/dependencies X.java

It prints "Hello, World!” as expected, so it definitely find the engine under 
the name “JavaScript". I can also run it with classpath instead of module path:

java -cp 
build/nashorn/dist/nashorn.jar:build/nashorn/dependencies/asm-7.3.1.jar:build/nashorn/dependencies/asm-util-7.3.1.jar
 X.java

and that works too. Do you have the dependencies (ASM) too?

Attila.

On 2021. Jul 13., at 15:33, Andreas Mueller mailto:a...@iit.de> > 
wrote:

Hi,

I’ve added Nashorn to Java 15 and it is properly displayed when listing the 
engines:

2021-07-13 15:14:30.233/sys$streams/INFORMATION/starting, available Scripting 
Engines:
2021-07-13 15:14:30.246/sys$streams/INFORMATION/name=OpenJDK Nashorn, 
version=15.3, language name=ECMAScript, language version=ECMA - 262 Edition 
5.1, names=[nashorn, Nashorn, js, JS, JavaScript, javascript, ECMAScript, 
ecmascript]

However, when I get the engine with name “JavaScript” it returns null:

engine = manager.getEngineByName((String) 
entity.getProperty("script-language").getValue());
if (engine == null)
   throw new Exception("Engine for script-language '" + 
entity.getProperty("script-language").getValue() + "' not found!");

2021-07-13 15:14:30.361/ERROR/Exception occured: java.lang.Exception: Engine 
for script-language 'JavaScript' not found!

Any ideas what the problem could be?

Thanks,
Andreas
-- 
Andreas Mueller
IIT Software GmbH
http://www.swiftmq.com   > 

Re: Nashorn Standalone 15.3 engine returned is null

[Attila Szegedi]

I’m honestly not sure. I have this very small test program:

import javax.script.*;

public class X {
public static void main(String[] args) throws ScriptException {
ScriptEngineManager factory = new ScriptEngineManager(); 
ScriptEngine engine = factory.getEngineByName("JavaScript"); 
engine.eval("function f() { print('Hello, World!'); } f()");
}
}

if I put it in a directory where I checked out Nashorn repo, and run “ant jar” 
to build the JAR file and run:

java --module-path build/nashorn/dist:build/nashorn/dependencies X.java

It prints "Hello, World!” as expected, so it definitely find the engine under 
the name “JavaScript". I can also run it with classpath instead of module path:

java -cp 
build/nashorn/dist/nashorn.jar:build/nashorn/dependencies/asm-7.3.1.jar:build/nashorn/dependencies/asm-util-7.3.1.jar
 X.java

and that works too. Do you have the dependencies (ASM) too?

Attila.

> On 2021. Jul 13., at 15:33, Andreas Mueller  wrote:
> 
> Hi,
> 
> I’ve added Nashorn to Java 15 and it is properly displayed when listing the 
> engines:
> 
> 2021-07-13 15:14:30.233/sys$streams/INFORMATION/starting, available Scripting 
> Engines:
> 2021-07-13 15:14:30.246/sys$streams/INFORMATION/name=OpenJDK Nashorn, 
> version=15.3, language name=ECMAScript, language version=ECMA - 262 Edition 
> 5.1, names=[nashorn, Nashorn, js, JS, JavaScript, javascript, ECMAScript, 
> ecmascript]
> 
> However, when I get the engine with name “JavaScript” it returns null:
> 
> engine = manager.getEngineByName((String) 
> entity.getProperty("script-language").getValue());
> if (engine == null)
> throw new Exception("Engine for script-language '" + 
> entity.getProperty("script-language").getValue() + "' not found!");
> 
> 2021-07-13 15:14:30.361/ERROR/Exception occured: java.lang.Exception: Engine 
> for script-language 'JavaScript' not found!
> 
> Any ideas what the problem could be?
> 
> Thanks,
> Andreas
> -- 
> Andreas Mueller
> IIT Software GmbH
> http://www.swiftmq.com  
> 
> 

Re: Nashorn 15.3 is out

[Rony G. Flatscher]

On 01.07.2021 13:32, Attila Szegedi wrote:
> Hey all,
>
> I just released Nashorn 15.3[0]. Check the change log[1] to easily see what’s 
> new.
>
> The most notable change is that Nashorn now works with JDK 17.
>
> Attila.
>
> [0] 
> https://search.maven.org/artifact/org.openjdk.nashorn/nashorn-core/15.3/jar
> [1] https://github.com/openjdk/nashorn/blob/main/CHANGELOG.md

Cool, thank you very much!!

---rony

Re: Does Nashorn (org.openjdk.nashorn) have any support for Java 17?

[forax]

> From: "Attila Szegedi" 
> To: "Remi Forax" 
> Cc: "nashorn-dev" 
> Sent: Mardi 29 Juin 2021 00:37:56
> Subject: Re: Does Nashorn (org.openjdk.nashorn) have any support for Java 17?

>> On 2021. Jun 28., at 19:30, Remi Forax < [ mailto:fo...@univ-mlv.fr |
>> fo...@univ-mlv.fr ] > wrote:

>> In the meantime, I think you can use Lookup.defineClass() or do you rely on 
>> the
>> weird security model of the anonymous classes ?

> Thankfully, no. Nashorn regenerates code for the same function sometimes so it
> was convenient having old versions get garbage collectible when they were
> individual anonymous classes; not being registered with class loader didn’t
> make their reachability dependent on one another. I could simulate it with one
> class loader per generated class; but it’ll cause a bit of a proliferation of
> class loader objects. Anon classes were just convenient in this regard.

Yes, convenient but internally, you have one metaspace per anon class exactly 
like when you have one classloader per class. 

For lambdas, the jdk has moved from the weak semantics (le the proxy class is 
not linked to a classloader) to the strong semantics, the proxy class is linked 
to the class loader of the nestmate host class. 
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L405
 

> IIUC Lookup.defineClass() doesn’t help me with that. Does it have some 
> benefits
> over defining a class through a class loader ?

It does not help if you want the weak semantics, it helps if you want to use 
the strong semantics because lookup.defineClass() load the class with the same 
classloader as the lookup class. 

> Attila.

Rémi 

>>> Hope this helps,
>>> Attila.

>> Rémi

>>> [0] [ 
>>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077347.html
>>> | 
>>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077347.html ]

>>>> On 2021. Jun 28., at 18:24, Greg Watts < [ mailto:gwa...@us.ibm.com |
>>>> gwa...@us.ibm.com ] > wrote:

>>>> Dear Nashorn development team,

>>>> I am trying to run an ANT build of our product using
>>>> nashorn-core:15.1.1.jar with Java 17 (pre-release - build 27) and I get:

>>>> BUILD FAILED
>>>> java.lang.ExceptionInInitializerError
>>>> at
>>>> org.openjdk.nashorn.internal.runtime.Context.compile(Context.java:1509)
>>>> at
>>>> org.openjdk.nashorn.internal.runtime.Context.compileScript(Context.java:1449)
>>>> at
>>>> org.openjdk.nashorn.internal.runtime.Context.compileScript(Context.java:759)
>>>> at
>>>> org.openjdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:528)
>>>> at
>>>> org.openjdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:517)
>>>> at
>>>> org.openjdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:395)
>>>> at
>>>> org.openjdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:151)
>>>> at
>>>> java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:262)
>>>> at
>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>>>> Method)
>>>> at
>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>>>> at
>>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>>>> at org.apache.tools.ant.util.ReflectUtil.invoke(ReflectUtil.java:108)
>>>> at
>>>> org.apache.tools.ant.util.ReflectWrapper.invoke(ReflectWrapper.java:81)
>>>> at
>>>> org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:103)
>>>> at
>>>> org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67)
>>>> at
>>>> org.apache.tools.ant.taskdefs.optional.Script.execute(Script.java:52)
>>>> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
>>>> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
>>>> at
>>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>> at java.base/java.lang.reflect.Method.invoke(Me

Re: Does Nashorn (org.openjdk.nashorn) have any support for Java 17?

[Attila Szegedi]

> On 2021. Jun 28., at 19:30, Remi Forax  wrote:
> 
> 
> In the meantime, I think you can use Lookup.defineClass() or do you rely on 
> the weird security model of the anonymous classes ?

Thankfully, no. Nashorn regenerates code for the same function sometimes so it 
was convenient having old versions get garbage collectible when they were 
individual anonymous classes; not being registered with class loader didn’t 
make their reachability dependent on one another. I could simulate it with one 
class loader per generated class; but it’ll cause a bit of a proliferation of 
class loader objects. Anon classes were just convenient in this regard.

IIUC Lookup.defineClass() doesn’t help me with that. Does it have some benefits 
over defining a class through a class loader?

Attila.

> 
>> 
>> Hope this helps,
>> Attila.
> 
> Rémi
> 
>> 
>> [0] 
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077347.html
>> 
>> 
>>> On 2021. Jun 28., at 18:24, Greg Watts  wrote:
>>> 
>>> 
>>> Dear Nashorn development team,
>>> 
>>> I am trying to run an ANT build of our product using
>>> nashorn-core:15.1.1.jar with Java 17 (pre-release - build 27) and I get:
>>> 
>>> BUILD FAILED
>>> java.lang.ExceptionInInitializerError
>>>   at
>>> org.openjdk.nashorn.internal.runtime.Context.compile(Context.java:1509)
>>>   at
>>> org.openjdk.nashorn.internal.runtime.Context.compileScript(Context.java:1449)
>>>   at
>>> org.openjdk.nashorn.internal.runtime.Context.compileScript(Context.java:759)
>>>   at
>>> org.openjdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:528)
>>>   at
>>> org.openjdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:517)
>>>   at
>>> org.openjdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:395)
>>>   at
>>> org.openjdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:151)
>>>   at
>>> java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:262)
>>>   at
>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>>> Method)
>>>   at
>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>>>   at
>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>   at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>>>   at org.apache.tools.ant.util.ReflectUtil.invoke(ReflectUtil.java:108)
>>>   at
>>> org.apache.tools.ant.util.ReflectWrapper.invoke(ReflectWrapper.java:81)
>>>   at
>>> org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:103)
>>>   at
>>> org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67)
>>>   at
>>> org.apache.tools.ant.taskdefs.optional.Script.execute(Script.java:52)
>>>   at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
>>>   at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
>>>   at
>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>   at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>>>   at
>>> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
>>>   at org.apache.tools.ant.Task.perform(Task.java:348)
>>>   at org.apache.tools.ant.Target.execute(Target.java:392)
>>>   at org.apache.tools.ant.Target.performTasks(Target.java:413)
>>>   at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
>>>   at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
>>>   at
>>> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
>>>   at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
>>>   at org.apache.tools.ant.Main.runBuild(Main.java:811)
>>>   at org.apache.tools.ant.Main.startAnt(Main.java:217)
>>>   at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
>>>   at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
>>> Caused by: java.lang.RuntimeException: java.lang.NoSuchMethodException: no
>>> such method:
>>> sun.misc.Unsafe.defineAnonymousClass(Class,byte[],Object[])Class/invokeVirtual
>>>   at org.openjdk.nashorn.internal.runtime.Context
>>> $AnonymousContextCodeInstaller.lambda$getDefineAnonymousClass
>>> $0(Context.java:335)
>>>   at
>>> java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
>>>   at org.openjdk.nashorn.internal.runtime.Context
>>> $AnonymousContextCodeInstaller.getDefineAnonymousClass(Context.java:327)
>>>   at org.openjdk.nashorn.internal.runtime.Context
>>> $AnonymousContextCodeInstaller.(Context.java:317)
>>>   ... 33 more
>>> Caused by: java.lang.NoSuchMethodException: no such method:
>>> sun.misc.Unsafe.defineAnonymousClass(Class,byte[],Object[])Class/invokeVirtual
>>>   at
>>> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:976)
>>>   at 

Re: Does Nashorn (org.openjdk.nashorn) have any support for Java 17?

[Remi Forax]

- Original Message -
> From: "Attila Szegedi" 
> To: "nashorn-dev" 
> Cc: "Greg Watts" 
> Sent: Lundi 28 Juin 2021 19:07:38
> Subject: Re: Does Nashorn (org.openjdk.nashorn) have any support for Java 17?

> Hi Greg,
> 
> that’s a consequence of Java 17 removing the Unsafe.defineAnonymousClass 
> method.
> Unfortunately, we don’t have an ideal replacement for it yet.
> MethodHandles.Lookup.defineHiddenClass is supposed to be a publicly supported
> replacement, but it hides the generated classes from stack traces, and that
> makes Nashorn incorrectly report exception stack traces, since we use this
> method to emit code compiled from scripts.
> 
> There’s been some discussion about this[0] and the JDK team at Oracle is aware
> that we’d need a better replacement API but there’s not one available yet :-(
> 
> We use Unsafe.defineAnonymousClass for Nashorn’s lazy compilation feature, 
> where
> it compiles every function independently just before it is executed for the
> first time. This is in contrast to eager compilation, where the whole script 
> is
> compiled when it is loaded. Lazy compilation is the default.
> 
> One thing you can do right now is try to somehow pass “false” as the value of
> the “lazy.compilation” system property to turn off lazy compilation.
> 
> I’ve been working on a branch that’ll handle the problem gracefully and 
> default
> to eager compilation if Unsafe.defineAnonymousClass is not present in the Java
> runtime. I’ll probably make a release soon with this fix.

In the meantime, I think you can use Lookup.defineClass() or do you rely on the 
weird security model of the anonymous classes ?

> 
> Hope this helps,
>  Attila.

Rémi

> 
> [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077347.html
> 
> 
>> On 2021. Jun 28., at 18:24, Greg Watts  wrote:
>> 
>> 
>> Dear Nashorn development team,
>> 
>> I am trying to run an ANT build of our product using
>> nashorn-core:15.1.1.jar with Java 17 (pre-release - build 27) and I get:
>> 
>> BUILD FAILED
>> java.lang.ExceptionInInitializerError
>>at
>> org.openjdk.nashorn.internal.runtime.Context.compile(Context.java:1509)
>>at
>> org.openjdk.nashorn.internal.runtime.Context.compileScript(Context.java:1449)
>>at
>> org.openjdk.nashorn.internal.runtime.Context.compileScript(Context.java:759)
>>at
>> org.openjdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:528)
>>at
>> org.openjdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:517)
>>at
>> org.openjdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:395)
>>at
>> org.openjdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:151)
>>at
>> java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:262)
>>at
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>> Method)
>>at
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>>at
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>>at org.apache.tools.ant.util.ReflectUtil.invoke(ReflectUtil.java:108)
>>at
>> org.apache.tools.ant.util.ReflectWrapper.invoke(ReflectWrapper.java:81)
>>at
>> org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:103)
>>at
>> org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67)
>>at
>> org.apache.tools.ant.taskdefs.optional.Script.execute(Script.java:52)
>>at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
>>at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
>>at
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>>at
>> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
>>at org.apache.tools.ant.Task.perform(Task.java:348)
>>at org.apache.tools.ant.Target.execute(Target.java:392)
>>at org.apache.tools.ant.Target.performTasks(Target.java:413)
>>at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
>>at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
>>at
>> org.apache.tools

Re: Does Nashorn (org.openjdk.nashorn) have any support for Java 17?

[Attila Szegedi]

Hi Greg,

that’s a consequence of Java 17 removing the Unsafe.defineAnonymousClass 
method. Unfortunately, we don’t have an ideal replacement for it yet. 
MethodHandles.Lookup.defineHiddenClass is supposed to be a publicly supported 
replacement, but it hides the generated classes from stack traces, and that 
makes Nashorn incorrectly report exception stack traces, since we use this 
method to emit code compiled from scripts.

There’s been some discussion about this[0] and the JDK team at Oracle is aware 
that we’d need a better replacement API but there’s not one available yet :-(

We use Unsafe.defineAnonymousClass for Nashorn’s lazy compilation feature, 
where it compiles every function independently just before it is executed for 
the first time. This is in contrast to eager compilation, where the whole 
script is compiled when it is loaded. Lazy compilation is the default.

One thing you can do right now is try to somehow pass “false” as the value of 
the “lazy.compilation” system property to turn off lazy compilation.

I’ve been working on a branch that’ll handle the problem gracefully and default 
to eager compilation if Unsafe.defineAnonymousClass is not present in the Java 
runtime. I’ll probably make a release soon with this fix.

Hope this helps,
  Attila.

[0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077347.html


> On 2021. Jun 28., at 18:24, Greg Watts  wrote:
> 
> 
> Dear Nashorn development team,
> 
> I am trying to run an ANT build of our product using
> nashorn-core:15.1.1.jar with Java 17 (pre-release - build 27) and I get:
> 
> BUILD FAILED
> java.lang.ExceptionInInitializerError
>at
> org.openjdk.nashorn.internal.runtime.Context.compile(Context.java:1509)
>at
> org.openjdk.nashorn.internal.runtime.Context.compileScript(Context.java:1449)
>at
> org.openjdk.nashorn.internal.runtime.Context.compileScript(Context.java:759)
>at
> org.openjdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:528)
>at
> org.openjdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:517)
>at
> org.openjdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:395)
>at
> org.openjdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:151)
>at
> java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:262)
>at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>at org.apache.tools.ant.util.ReflectUtil.invoke(ReflectUtil.java:108)
>at
> org.apache.tools.ant.util.ReflectWrapper.invoke(ReflectWrapper.java:81)
>at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:103)
>at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67)
>at
> org.apache.tools.ant.taskdefs.optional.Script.execute(Script.java:52)
>at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
>at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
>at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
>at org.apache.tools.ant.Task.perform(Task.java:348)
>at org.apache.tools.ant.Target.execute(Target.java:392)
>at org.apache.tools.ant.Target.performTasks(Target.java:413)
>at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
>at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
>at
> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
>at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
>at org.apache.tools.ant.Main.runBuild(Main.java:811)
>at org.apache.tools.ant.Main.startAnt(Main.java:217)
>at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
>at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
> Caused by: java.lang.RuntimeException: java.lang.NoSuchMethodException: no
> such method:
> sun.misc.Unsafe.defineAnonymousClass(Class,byte[],Object[])Class/invokeVirtual
>at org.openjdk.nashorn.internal.runtime.Context
> $AnonymousContextCodeInstaller.lambda$getDefineAnonymousClass
> $0(Context.java:335)
>at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
>at org.openjdk.nashorn.internal.runtime.Context
> $AnonymousContextCodeInstaller.getDefineAnonymousClass(Context.java:327)
>at org.openjdk.nashorn.internal.runtime.Context

Re: JDK Dynalink only works with unconditionally exported packages

[Attila Szegedi]

On 2021. May 11., at 1:51, Thiago Henrique Hupner  wrote:
> 
> Hi all.
> 
> I've been testing the JDK Dynalink recently and
> I think I've found a bug.
> 
> The class jdk.dynalink.beans.CheckRestrictedPackage checks
> if a package is restricted.
> 
> So, I have a class that has some static methods. But to Dynalink find the
> class,
> the class needs to be public. OK,
> I've changed my class to be public. However, it needs that
> the package of the class is exported in the module too.
> 
> I think this is a little too restrictive. I don't want to expose
> to my users some internal implementation.

The module exports is exactly the feature used to regulate what are you 
exposing from the module. In this case, you could have a class in a different 
package exposing those static methods (even if only just delegating to the 
original unexported class), and export those methods. 

Dynalink’s BeansLinker deliberately implemented in such a manner that it only 
allows access to entirely unrestricted classes. So what you’re experiencing is 
not a bug, it is the expected behavior. It’s admittedly a compromise between a 
simpler security model vs. losing some power.

> 
> The main problem is that the method
> CheckRestrictedPackage::isRestrictedClass
> does the following check:
> 
> // ...
> final String pkgName = name.substring(0, i);
> final Module module = clazz.getModule();
> if (module != null && !module.isExported(pkgName)) {
>return true;
> }
> // ...
> 
> I have a feeling that this check should be changed to something like
> 
> // ...
> final String pkgName = name.substring(0, i);
> final Module module = clazz.getModule();
> if (module != null && !module.isOpen(pkgName,
> CheckRestrictedPackage.class.getModule())) {
>return true;
> }
> // ...
> 
> In this way, my code can only "opens" a single package to the jdk.dynalink
> module,
> not having to unconditionally export a package.

If we did just what you suggested, then every package you’d open to 
jdk.dynalink would become wide open accessible to everyone through Dynalink. 
That’d obviously be a problem as it’d allow circumventing module visibility 
rules.

That would be fixable with some more work, though. It would be possible to 
create an enhancement where Dynalink allows linking to methods of 
non-globally-exported classes if it’d verify each such link attempt through 
sun.invoke.util.VerifyAccess.isMemberAccessible, using the data from the 
MethodHandle.Lookup object passed in LinkRequest. These lookup objects 
typically originate from the bootstrap methods for invokedynamic call sites in 
the target class.

Then you’d also indeed need to ensure that Dynalink can reflect on those 
packages, so you’d still have to open the package towards Dynalink, but 
Dynalink itself would enforce that it itself only allows linking call sites 
according to JVM linkage rules. 

This is not very simple to implement though, as the isRestrictedClass is used 
for various purposes right now, and would need to be replaced with something 
more granular, and then calls to VerifyAccess.isMemberAccessible would be 
needed to be added into the logic for resolving property getters and setters 
and method getters.

Dynalink already uses the Lookup objects for various purposes; it is used for 
linking invocations of @CallerSensitive-marked methods (which Dynalink 
supports) as well as for linkage-rules respecting creation of type conversions 
(it’s somewhat surprising that the concern would pop up there, but it does…) 
All just to say that Dynalink having to deal with JVM linkage rules isn’t 
foreign to it, it’s already doing it in some contexts, but it indeed currently 
doesn’t support linking to classes that aren’t world-exported.

Attila.

> 
> From what I could understand, in Nashorn, the generated classes
> were defined in the unnamed module, that always exports all the packages,
> so the access always worked.
> 
> The code can be found here:
> https://github.com/openjdk/jdk/blob/master/src/jdk.dynalink/share/classes/jdk/dynalink/beans/CheckRestrictedPackage.java#L94
> 
> Best regards.
> 
> Thiago

Re: ECMAScript 6 through the ScriptEngineManager

[Attila Szegedi]

I’ve also been considering this idea. FWIW, there are some incompatibilities 
between ES5 and ES6. Most people wouldn’t ever encounter these as they 
typically make some things work in ES6 that wouldn’t work in ES6 

For example, there’s a bunch of methods on Object prototype that in ES5 throw a 
TypeError if their argument is not an object, but in ES6 they call ToObject on 
the argument. So there’s some code that could fail on ES5 but succeed on ES6. 
ES6 is generally a bit more lenient and these decisions seem commonsensical.

 E.g. calling

Object.getPrototypeOf(1)

should throw a “TypeError: 1 is not an object” under ES5 semantics, and return 
the prototype of Number(1) under ES6 semantics.

Similarly, Object.isExtensible(1) also throws TypeError under ES5 but returns 
the fairly sensical value of “false” under ES6.

Given how the world is moving towards ES6, it might make sense to switch 
Nashorn to conform to just ES6 and leave strict ES5 compliance behind.

Attila.


> On 2021. Mar 31., at 13:43, Rony G. Flatscher  wrote:
> 
> Hi Attila,
> 
> On 29.03.2021 19:29, Attila Szegedi wrote:
>> today the most used ECMAScript version is 6 (ES6); Nashorn OTOH implements 
>> the full ECMAScript 5.1 (ES5) specification and also a subset[0] of 6.  
>> Mostly for compatibility purposes though, it defaults to ES5 and ES6 
>> features aren’t enabled by default. 
> 
> Probably a stupid question: is there some incompatibility introduced in the 
> ES6-mode of Nashorn
> compared to 5.1? If not, why not have Nashorn run in ES6 mode by default and 
> maybe add a Bindings
> entry indicating the execution mode of Nashorn (being ES6 in this case)?
> 
> Another idea might be to have two different Nashorn script engines packaged 
> where one is contained
> in a module indicating ES5 and the other ES6 execution mode. Then it is 
> "merely" a matter which
> module to download for a developer. An application needing Nashorn in ES6 
> mode can then rely on
> these features be present if the ES6-module gets used without a need to 
> change anything in the
> script framework interfaces.
> 
> Other than that I think the System property approach would be the most 
> straight-forward one
> ("-Dorg.openjdk.nashorn.preferLanguage=es6") as developers are accustomed to 
> this pattern.
> 
> In any case, if there are two different execution modes possible it would be 
> helpful to allow
> finding out at runtime which mode is currently in use (suggesting placing 
> this information into the
> Bindings).
> 
> ---rony
> 
>> So, the problem I’d like to solve is: using only javax.script.* API, get 
>> Nashorn ScriptEngine that runs ES6. 
>> 
>> Using the Nashorn API you can do:
>> 
>> import org.openjdk.nashorn.api.scripting.*;
>> 
>> var factory = new NashornScriptEngineFactory();
>> var engine = factory.getScriptEngine(“--language=es6”)
>> …
>> 
>> But there’s no way to do it through just using javax.script.* APIs. 
>> 
>> Let’s see some ideas that led nowhere:
>> * specify ES6-specific MIME types: turns out, there’s none. text/javascript, 
>> application/javascript, text/ecmascript and application/ecmascript are all 
>> generic, non-versioned MIME types. 
>> * specify ES6-specific filename extensions: turns out, there are none. “.js” 
>> is generic, non-versioned.
>> 
>> I also have some ideas that do have legs. These are non-exclusive:
>> * Add a separate “NashornScriptEngineFactory6” class that answers to 
>> versioned names, e.g. “Nashorn ES6” allowing people to ask for an ES6 engine 
>> by name. That engine would answer to no MIME types or filename extensions.
>> * Add support for system property so people can launch the JVM with e.g. 
>> -Dorg.openjdk.nashorn.preferLanguage=es6. This could be used when people 
>> need to run existing systems that request a script engine with some name and 
>> they can’t change it. In this case, NashornScriptEngineFactory would  be 
>> creating ES6 engines instead of ES5 engines when the property is set.
>> 
>> I also considered allowing a special bindings key, so you could do something 
>> like:
>> 
>> var manager = new ScriptEngineManager();
>> manager.put(“org.openjdk.nashorn.options”, new String[] { “--language=es6”  
>> });
>> var engine = manager.getEngineByName(“javascript”);
>> 
>> but FWIW, if you can do this, you might as well be using the Nashorn API 
>> from the top of this e-mail, or ask for manager.getEngineByName(“Nashorn 
>> ES6”). So in the end, the separate engine name for ES6 + a system property 
>> for the cases where users can’t affect the engine name seems sufficient to 
>> me.
>> 
>> Thoughts?
>> 
>> Attila.
>> 
>> [0] Of course, it’s a whole other issue that ES6 support in Nashorn is 
>> incomplete; that’s not something I’m out to fix right now. It has enough 
>> goodies (const, let, arrow functions, etc.) that it’s justifiable that 
>> people would want to use what’s there.
> 

Re: ECMAScript 6 through the ScriptEngineManager

[Rony G. Flatscher]

Hi Attila,

On 29.03.2021 19:29, Attila Szegedi wrote:
> today the most used ECMAScript version is 6 (ES6); Nashorn OTOH implements 
> the full ECMAScript 5.1 (ES5) specification and also a subset[0] of 6.  
> Mostly for compatibility purposes though, it defaults to ES5 and ES6 features 
> aren’t enabled by default. 

Probably a stupid question: is there some incompatibility introduced in the 
ES6-mode of Nashorn
compared to 5.1? If not, why not have Nashorn run in ES6 mode by default and 
maybe add a Bindings
entry indicating the execution mode of Nashorn (being ES6 in this case)?

Another idea might be to have two different Nashorn script engines packaged 
where one is contained
in a module indicating ES5 and the other ES6 execution mode. Then it is 
"merely" a matter which
module to download for a developer. An application needing Nashorn in ES6 mode 
can then rely on
these features be present if the ES6-module gets used without a need to change 
anything in the
script framework interfaces.

Other than that I think the System property approach would be the most 
straight-forward one
("-Dorg.openjdk.nashorn.preferLanguage=es6") as developers are accustomed to 
this pattern.

In any case, if there are two different execution modes possible it would be 
helpful to allow
finding out at runtime which mode is currently in use (suggesting placing this 
information into the
Bindings).

---rony

> So, the problem I’d like to solve is: using only javax.script.* API, get 
> Nashorn ScriptEngine that runs ES6. 
>
> Using the Nashorn API you can do:
>
> import org.openjdk.nashorn.api.scripting.*;
>
> var factory = new NashornScriptEngineFactory();
> var engine = factory.getScriptEngine(“--language=es6”)
> …
>
> But there’s no way to do it through just using javax.script.* APIs. 
>
> Let’s see some ideas that led nowhere:
> * specify ES6-specific MIME types: turns out, there’s none. text/javascript, 
> application/javascript, text/ecmascript and application/ecmascript are all 
> generic, non-versioned MIME types. 
> * specify ES6-specific filename extensions: turns out, there are none. “.js” 
> is generic, non-versioned.
>
> I also have some ideas that do have legs. These are non-exclusive:
> * Add a separate “NashornScriptEngineFactory6” class that answers to 
> versioned names, e.g. “Nashorn ES6” allowing people to ask for an ES6 engine 
> by name. That engine would answer to no MIME types or filename extensions.
> * Add support for system property so people can launch the JVM with e.g. 
> -Dorg.openjdk.nashorn.preferLanguage=es6. This could be used when people need 
> to run existing systems that request a script engine with some name and they 
> can’t change it. In this case, NashornScriptEngineFactory would  be creating 
> ES6 engines instead of ES5 engines when the property is set.
>
> I also considered allowing a special bindings key, so you could do something 
> like:
>
> var manager = new ScriptEngineManager();
> manager.put(“org.openjdk.nashorn.options”, new String[] { “--language=es6”  
> });
> var engine = manager.getEngineByName(“javascript”);
>
> but FWIW, if you can do this, you might as well be using the Nashorn API from 
> the top of this e-mail, or ask for manager.getEngineByName(“Nashorn ES6”). So 
> in the end, the separate engine name for ES6 + a system property for the 
> cases where users can’t affect the engine name seems sufficient to me.
>
> Thoughts?
>
> Attila.
>
> [0] Of course, it’s a whole other issue that ES6 support in Nashorn is 
> incomplete; that’s not something I’m out to fix right now. It has enough 
> goodies (const, let, arrow functions, etc.) that it’s justifiable that people 
> would want to use what’s there.

Ad "Re: Run servlets on Nashorn written in server-side JavaScript" ...

[Rony G. Flatscher]

As this may be interesting for the Nashorn community as well FYI:

 Forwarded Message 
Subject:Re: Run servlets on Nashorn written in server-side JavaScript
Date:   Sun, 28 Feb 2021 17:33:22 +0100
From:   Rony G. Flatscher
Reply-To:   Tomcat Users List 
To: us...@tomcat.apache.org



Leo,

On 26.02.2021 01:52, leo wrote:
> On 25 Feb 2021, at 2:47, Rony G. Flatscher (Apache) wrote:
>
>> P.S.: Have tested my implementation with Nashorn on Java 8 and it works 
>> out of the box! Still, you
>> would need to test the implementation thoroughly yourself (stability, 
>> performance, resources) and
>> would be asked to come back with feedback on each of these qualities. So 
>> stay tuned, will publish a
>> link to the implementation with a proper Nashorn/JavaScript sample war 
>> in this mail thread in a few
>> days.
>
> How cool is this! Let me know when you it ready, please. Thanks a lot!

O.K., had a few things I could finalize. Created two war files, 
"demoJavaScript.war" and
"demoRhino.war". The first got tested against Nashorn, the second - you 
guessed it ;) - against
Rhino (7.1.13). They are meant as little proof-of-concepts that should help 
you to get up and
running with them.

Please note that the libraries are beta, though appear to be stable. Yet, 
there may be
errors/problems in them or there may be changes coming up.

If you have feedback of any sorts, please come forward (stability, 
usability, performance,
resources, etc.).

Basically you just need to go to [1] and get the two war-files (copy to 
$CATALINA_HOME/webapps) plus
either javax.ScriptTagLibs.jar (for Tomcat 9 or earlier) or 
jakarta.ScriptTagLibs.jar (for Tomcat
10) which you should copy to the shared directory at $CATALINA_HOME/lib and 
restart Tomcat to get
them recognized. If you want to test with Rhino you should follow the 
directions at [1] and copy the
mentioned two rhino jar files to the shared library directory as well.

In general you should take the time and look over that page at [1], I tried 
to remain as brief as
possible. :)

Also please do not forget that the target audience of [1] has been so far 
the Rexx community and my
BA students who learned programming using ooRexx in a semester and with 
that knowledge should now
become able to create little web sites for their own purposes and maybe 
with some experience for
small businesses/organizations given the information at [1] as a starting 
point.

Of course, if there are any questions please do not hesitate and please ask 
them!

HTH,

---rony

[1] Homepage of the ScriptTagLibs libraries:

<https://sourceforge.net/projects/bsf4oorexx/files/Sandbox/rgf/taglibs/beta/>

---rony

Re: Terminate running script thread

[Remi Forax]

- 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
>> <https://stackoverflow.com/questions/24855182/interrupt-java-thread-running-nashorn-script>
>> http://blog.getsandbox.com/2018/01/15/nashorn-interupt/
>> <http://blog.getsandbox.com/2018/01/15/nashorn-interupt/>
>> 
>> 
>> Thank you
>> 
> > Viktor

Re: Terminate running script thread

[Attila Szegedi]

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

Re: Terminate running script thread

[Viktor Remennik]

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
> 

Re: Terminate running script thread

[Attila Szegedi]

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

Re: Question ad "arguments" and ScriptEngine.ARGV

[Rony G. Flatscher]

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





body { background-color: ivory; }

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" %>
> 
> 
> 
> 
> 
> body { background-color: ivory; }
> 
> 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:
>
>
>
> 
> 
> 
> 
> 
> body { background-color: ivory; }
> 
> 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":
> 

Re: Lowering minimum runtime requirement to Java 11

[Dalibor Topic]

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

Re: Fix for NashornScriptEngineFactory.getOutputStatement(toDisplay) (Re: Standalone Nashorn is coming for Java 15+

[Attila Szegedi]

Hi,

thanks for reporting this. I filed a JBS issue[0] and I have a PR[0] to fix it 
put up. It’ll go into the next Nashorn release.

Thanks,
  Attila.

[0] https://bugs.openjdk.java.net/browse/JDK-8258787
[1] https://github.com/openjdk/nashorn/pull/11

> On 2020. Nov 23., at 17:20, Rony G. Flatscher  wrote:
> 
> Hi there,
> 
> the NashornScriptEngineFactory.getOutputStatement() does not create a valid 
> String from the
> toDisplay argument. As a result it is not possible to create correct 
> Javascript statements that
> output strings created with that method (Nashorn creates an exception when 
> running a statement it
> created itself).
> 
> The input string toDisplay:
> 
>~~~
>'hello world', this is "ECMAScript" speaking!
>~~~
> 
> The current getOutputStatement(toDisplay) returns the syntaxtically wrong 
> output statement (will
> cause an exception):
> 
>~~~
>print('hello world', this is "ECMAScript" speaking!)
>~~~
> 
> The following git diff would apply double-quotes and escape double-quotes, if 
> they are part of the
> supplied toDisplay argument:
> 
>~~~
>
> G:\dev\openjfx\nashorn\src\org.openjdk.nashorn\share\classes\org\openjdk\nashorn\api\scripting>git
>  diff
>diff --git 
> a/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/api/scripting/NashornScriptEngineFactory.java
>  
> b/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/api/scripting/NashornScriptEngineFactory.java
>index 8dc8895a..59d5d60b 100644
>--- 
> a/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/api/scripting/NashornScriptEngineFactory.java
>+++ 
> b/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/api/scripting/NashornScriptEngineFactory.java
>@@ -104,7 +104,7 @@ public final class NashornScriptEngineFactory 
> implements ScriptEngineFactory {
> 
> @Override
> public String getOutputStatement(final String toDisplay) {
>-return "print(" + toDisplay + ")";
>+return "print(\"" + toDisplay.replace("\"","\\\"") + "\")";
> }
> 
> @Override
>~~~
> 
> The corrected getOutputStatement(toDisplay) with the change returns:
> 
>~~~
>print("'hello world', this is \"ECMAScript\" speaking!")
>~~~
> 
> Please advise how to best proceed in order to fix this long standing bug.
> 
> ---rony
> 
> P.S.: If you want you can take that code directly as I signed the Oracle 
> Contributor Agreement and
> submitted changes in the OpenJFX project in the past.
> 
> 
> On 15.11.2020 18:25, Attila Szegedi wrote:
>> Hi y’all,
>> 
>> openjdk/nashorn repo is up and its main branch is populated with the initial 
>> copy of Nashorn as it existed in JDK 14. I added a fix for wrong/missing 
>> licenses for two files (agreed with Oracle) and an initial project README on 
>> top of it.
>> 
>> An even better news is that I have the initial standalone Nashorn 15.0.0 PR 
>> up ready for review. It is at:
>> 
>> 
>> 
>> 
>> The PR describes the steps to build the artifacts. I’d like to encourage 
>> everyone here to try it out and report back with your experiences, and to 
>> also give an earnest review of the PR. If it works out okay, we could merge 
>> this into main in the next few days and then I can get the artifacts 
>> published into Maven Central!
>> 
>> Attila.
>> 
>>> On 2020. Oct 25., at 18:07, Attila Szegedi  wrote:
>>> 
>>> Hi y’all,
>>> 
>>> trying to get into the habit of making these weekly updates until I have 
>>> something else to show.
>>> 
>>> * With Remi’s, Sundar’s and Mandy’s help I fixed anonymous code loading. 
>>> We’ll be using the sun.misc.Unsafe for now, with hope to transition to 
>>> Lookup.defineHiddenClass somewhere down the line.
>>> 
>>> * I started using Ivy as the dependency manager in our build.xml, and right 
>>> now I also have an Ant task that builds all the artifacts for Maven 
>>> publication. 
>>> 
>>> The first version of Maven artifacts (jar, javadoc, sources, Maven pom 
>>> file) is basically ready to go. All we’re waiting for is for Oracle to 
>>> create the openjdk/nashorn repository and approve its initial contents. I 
>>> started the relevant conversation about it 12 days ago… it is going slower 
>>> than I hoped for.
>>> 
>>> What do you all think of the version number? Nashorn never had its own 
>>> separate version number, but I’m thinking we could start the standalone 
>>> version at 15. I don’t expect we’ll remain in lockstep with OpenJDK (so 
>>> it’ll remain at 15 significantly longer), but it might be a good strategy 
>>> to at least retroactively be able to talk about it without confusion, e.g. 
>>> “Nashorn 11” is Nashorn-as-in-Java-11 and “Nashorn 14” is 
>>> Nashorn-as-in-Java-14. And “Nashorn 15” is then quite naturally the first 
>>> standalone version.
>>> 
>>> Attila.
>>> 
 On 2020. Oct 19., at 17:16, Attila Szegedi  wrote:
 
 Hi y’all,
 
 a quick update with regard of what’s been 

Re: Some Nashorn PRs need review love

[Attila Szegedi]

Thank you! I have since added testing for non-modular Nashorn (details on the 
PR.)

> On 2020. Dec 17., at 7:36, sundararajan.athijegannat...@oracle.com wrote:
> 
> Hi,
> 
> Approved 4 out of 5. Clarification sought for 1
> 
> Thanks,
> 
> -Sundar
> 
> On 17/12/20 2:40 am, Attila Szegedi wrote:
>> I have several Nashorn PRs up for review; I started working my way through 
>> the JBS bug tracker. If anyone with OpenJDK reviewer privileges feels like 
>> helping, you can contribute a review. Three of the five are quite trivial 
>> few-liners.
>> 
>> Thanks!
>> 
>> Attila.
>> 

Re: Some Nashorn PRs need review love

[sundararajan . athijegannathan]

Hi,

Approved 4 out of 5. Clarification sought for 1

Thanks,

-Sundar

On 17/12/20 2:40 am, Attila Szegedi wrote:

I have several Nashorn PRs up for review; I started working my way through the 
JBS bug tracker. If anyone with OpenJDK reviewer privileges feels like helping, 
you can contribute a review. Three of the five are quite trivial few-liners.

Thanks!

Attila.

Re: RFC: enable demodularized operation?

[Attila Szegedi]

> On 2020. Dec 16., at 11:58, Ben Evans  wrote:
> 
> Hi Attila,
> 
> This might be being pedantic - but for folks that want to use
> standalone Nashorn it is emphatically not the case that they "have not
> adopted JPMS": If they're using a Java 9+ runtime then they *have*
> adopted JPMS - they're just using a nasty compatibility mode of it to
> dump their classpath into UNNAMED.

They certainly took no conscious action to adopt JPMS, rather the runtime is 
providing them with nonintrusive compatibility behavior.
I don’t disagree with you, mind you. I’d rather everybody used --module-path 
and nobody used -classpath anymore, but pragmatically for lots of folks this 
might hinder adoption.

> 
> Having said that, if it's just a small amount of code, then maybe it
> does make sense to add the conditionals.

Done; I put it up for review: 

Modularity handling in Nashorn was never really essential functionality, it was 
rather necessary plumbing that made Nashorn operational under JPMS in the first 
place – since it itself had to be a module since Java 9 as it was code that 
shipped in the JDK, there was no escaping this.

> I think the bigger part is the SB module dependencies issue - and that
> probably does need someone from the SB side to help debug what's going
> wrong and where the problem actually comes from.

> 
> Thanks,
> 
> Ben
> 
> On Tue, 15 Dec 2020 at 14:35, Attila Szegedi  wrote:
>> 
>> Hi Ben,
>> 
>> funnily enough since I posted this I found this newly submitted issue: 
>>  The reporter there argues 
>> that lots of folks might still be using Nashorn in non-modular applications. 
>> I think all module handling is restricted to three source files and it’d be 
>> fairly easy to just add conditionals around it. OTOH I can also see the 
>> merit in driving people towards more widespread adoption of --module-path :-)
>> 
>> I also agree with you that SB should correctly handle module dependencies, 
>> but I’m familiar with Nashorn and not familiar with SB, so it’s definitely 
>> easier for me to take Nashorn from mandatory-JPMS to optionally-JPMS. That 
>> said, I’m still mulling it over and am open to further discussion.
>> 
>> Attila.
>> 
>>> On 2020. Dec 15., at 14:05, Ben Evans  wrote:
>>> 
>>> Hi Attila,
>>> 
>>> I'd like to put forward a counterargument: Why would this be a good
>>> use of time? Nashorn SO requires at least Java 15, so it will never
>>> need to run on a pre-modular runtime.
>>> 
>>> Rather than spending effort on making it run as a non-modular JAR, I
>>> would argue that getting to the bottom of why it's not working with
>>> Spring Boot (and potentially providing fixes, whether into Nashorn or
>>> SB) is a better use of limited resources - both now and in terms of
>>> ongoing maintenance.
>>> 
>>> Cheers,
>>> 
>>> Ben
>>> 
>>> On Tue, 15 Dec 2020 at 12:55, Attila Szegedi  wrote:
 
 I’ve been thinking about the issue where Spring Boot isn’t loading Nashorn 
 as a module, and was wondering if it’d make sense to put some effort into 
 allowing Nashorn to operate when loaded as a non-modular JAR. Thoughts?
 
 Attila.
 
>> 

Re: RFC: enable demodularized operation?

[Ben Evans]

Hi Attila,

This might be being pedantic - but for folks that want to use
standalone Nashorn it is emphatically not the case that they "have not
adopted JPMS": If they're using a Java 9+ runtime then they *have*
adopted JPMS - they're just using a nasty compatibility mode of it to
dump their classpath into UNNAMED.

Having said that, if it's just a small amount of code, then maybe it
does make sense to add the conditionals.

I think the bigger part is the SB module dependencies issue - and that
probably does need someone from the SB side to help debug what's going
wrong and where the problem actually comes from.

Thanks,

Ben

On Tue, 15 Dec 2020 at 14:35, Attila Szegedi  wrote:
>
> Hi Ben,
>
> funnily enough since I posted this I found this newly submitted issue: 
>  The reporter there argues 
> that lots of folks might still be using Nashorn in non-modular applications. 
> I think all module handling is restricted to three source files and it’d be 
> fairly easy to just add conditionals around it. OTOH I can also see the merit 
> in driving people towards more widespread adoption of --module-path :-)
>
> I also agree with you that SB should correctly handle module dependencies, 
> but I’m familiar with Nashorn and not familiar with SB, so it’s definitely 
> easier for me to take Nashorn from mandatory-JPMS to optionally-JPMS. That 
> said, I’m still mulling it over and am open to further discussion.
>
> Attila.
>
> > On 2020. Dec 15., at 14:05, Ben Evans  wrote:
> >
> > Hi Attila,
> >
> > I'd like to put forward a counterargument: Why would this be a good
> > use of time? Nashorn SO requires at least Java 15, so it will never
> > need to run on a pre-modular runtime.
> >
> > Rather than spending effort on making it run as a non-modular JAR, I
> > would argue that getting to the bottom of why it's not working with
> > Spring Boot (and potentially providing fixes, whether into Nashorn or
> > SB) is a better use of limited resources - both now and in terms of
> > ongoing maintenance.
> >
> > Cheers,
> >
> > Ben
> >
> > On Tue, 15 Dec 2020 at 12:55, Attila Szegedi  wrote:
> >>
> >> I’ve been thinking about the issue where Spring Boot isn’t loading Nashorn 
> >> as a module, and was wondering if it’d make sense to put some effort into 
> >> allowing Nashorn to operate when loaded as a non-modular JAR. Thoughts?
> >>
> >> Attila.
> >>
>

RE: Bug in extractVarNodesFromDeadCode. Variable "x" has already been declared

[?????????? ????? ?????????]

Hi.

Since Nashorn is in development again, perhaps this bug
(https://bugs.openjdk.java.net/browse/JDK-8233195) can be fixed instead of
"Won't Fix" resolution?

-Original Message-
From: nashorn-dev [mailto:nashorn-dev-boun...@openjdk.java.net] On Behalf Of
Hannes Wallnofer
Sent: Wednesday, October 30, 2019 1:31 PM
To: Nashorn-Dev
Subject: Re: Bug in extractVarNodesFromDeadCode. Variable "x" has already
been declared

Thanks for the report!

https://bugs.openjdk.java.net/browse/JDK-8233195

The provided patch looks reasonable so the chances to get this fixed are
quite good.

Hannes


> Am 28.10.2019 um 16:47 schrieb Jim Laskey :
> 
> Obviously, this wasn't intended for the list. To clarify, since Nashorn is
being deprecated, we are taking input such as this and recording it as a bug
in case someone adopts Nashorn in future.
> 
> Cheers,
> 
> -- Jim
> 
> 
>> On Oct 28, 2019, at 12:36 PM, Jim Laskey  wrote:
>> 
>> You want to take this on?  File a bug and put the e-mail (change set) in
it, then tell the user Nashorn is deprecated.
>> 
>>> On Oct 28, 2019, at 12:21 PM, Anton Mitrofanov 
wrote:
>>> 
>>> Hi.
>>> 
>>> We have encountered another bug in Nashorn. It can be reproduced by
evaluation of this script with "jjs --language=es6":
>>> 
>>> if (true) { throw "test"; } { let x = "1"; } { let x = 2; }
>>> 
>>> It results in compilation error:
>>> 
>>> ECMAScript Exception: SyntaxError: :1:34 Variable "x" has already
been declared if (true) { throw "test"; } { let x = "1"; } { let x = 2; }
>>>^
>>> While expected out was to get runtime exception "test".
>>> 
>>> Looks like the problem is in dead code elimination logic of
FoldConstants.extractVarNodesFromDeadCode function.
>>> 
>>> And here is the patch to fix it:
>>> 
>>> diff -r 6e287efa5fa3
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/FoldCon
stants.java
>>> ---
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/FoldC
onstants.java   Wed Oct 23 09:53:07 2019 +0200
>>> +++
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/FoldC
onstants.java   Wed Oct 23 14:23:48 2019 +0300
>>> @@ -195,7 +195,9 @@
>>>   deadCodeRoot.accept(new SimpleNodeVisitor() {
>>>   @Override
>>>   public boolean enterVarNode(final VarNode varNode) {
>>> -statements.add(varNode.setInit(null));
>>> +if (!varNode.isBlockScoped()) {
>>> +statements.add(varNode.setInit(null));
>>> +}
>>>   return false;
>>>   }
>>> 
>>> 
>> 
> 

Re: RFC: enable demodularized operation?

[Attila Szegedi]

Hi Ben,

funnily enough since I posted this I found this newly submitted issue: 
 The reporter there argues 
that lots of folks might still be using Nashorn in non-modular applications. I 
think all module handling is restricted to three source files and it’d be 
fairly easy to just add conditionals around it. OTOH I can also see the merit 
in driving people towards more widespread adoption of --module-path :-)

I also agree with you that SB should correctly handle module dependencies, but 
I’m familiar with Nashorn and not familiar with SB, so it’s definitely easier 
for me to take Nashorn from mandatory-JPMS to optionally-JPMS. That said, I’m 
still mulling it over and am open to further discussion.

Attila.

> On 2020. Dec 15., at 14:05, Ben Evans  wrote:
> 
> Hi Attila,
> 
> I'd like to put forward a counterargument: Why would this be a good
> use of time? Nashorn SO requires at least Java 15, so it will never
> need to run on a pre-modular runtime.
> 
> Rather than spending effort on making it run as a non-modular JAR, I
> would argue that getting to the bottom of why it's not working with
> Spring Boot (and potentially providing fixes, whether into Nashorn or
> SB) is a better use of limited resources - both now and in terms of
> ongoing maintenance.
> 
> Cheers,
> 
> Ben
> 
> On Tue, 15 Dec 2020 at 12:55, Attila Szegedi  wrote:
>> 
>> I’ve been thinking about the issue where Spring Boot isn’t loading Nashorn 
>> as a module, and was wondering if it’d make sense to put some effort into 
>> allowing Nashorn to operate when loaded as a non-modular JAR. Thoughts?
>> 
>> Attila.
>> 

Re: RFC: enable demodularized operation?

[Ben Evans]

Hi Attila,

I'd like to put forward a counterargument: Why would this be a good
use of time? Nashorn SO requires at least Java 15, so it will never
need to run on a pre-modular runtime.

Rather than spending effort on making it run as a non-modular JAR, I
would argue that getting to the bottom of why it's not working with
Spring Boot (and potentially providing fixes, whether into Nashorn or
SB) is a better use of limited resources - both now and in terms of
ongoing maintenance.

Cheers,

Ben

On Tue, 15 Dec 2020 at 12:55, Attila Szegedi  wrote:
>
> I’ve been thinking about the issue where Spring Boot isn’t loading Nashorn as 
> a module, and was wondering if it’d make sense to put some effort into 
> allowing Nashorn to operate when loaded as a non-modular JAR. Thoughts?
>
> Attila.
>

RE: RFC: enable demodularized operation?

[Houtman, Roland]

Dear Attila,

Nice to meet you.
I'm working for Yokogawa, and we're using JDK11 and Nashorn in one of our 
products.
Our code has not adopted the java module system. They probably do that for next 
release (I'm not sure).
We're not using spring-boot. We're using the script engine as part of 
customizable dynamics in a Swing based GUI.
JDK's change very rapidly, so i'm not demanding anything. I'm just presenting 
this from usage viewpoint.

Kind regards,
Roland

-Original Message-
From: nashorn-dev  On Behalf Of Attila 
Szegedi
Sent: Tuesday, December 15, 2020 12:54 PM
To: Nashorn-Dev 
Subject: RFC: enable demodularized operation?

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

I’ve been thinking about the issue where Spring Boot isn’t loading Nashorn as a 
module, and was wondering if it’d make sense to put some effort into allowing 
Nashorn to operate when loaded as a non-modular JAR. Thoughts?

Attila.

Re: Nashorn + Spring Boot; help appreciated

[Attila Szegedi]

Thanks Remi, although I don’t think that’s it.

To wit, if I write a minimal executable example:

---
import javax.script.*;

public class X {
public static void main(String[] args) throws ScriptException {
ScriptEngineManager factory = new ScriptEngineManager(); 
ScriptEngine engine = factory.getEngineByName("nashorn"); 
engine.eval("print('Hello, World!');");
}
}
---

then run it with from my Nashorn project directory after it downloaded 
dependencies and built the JAR (so they’re in the directories named on the 
command line):

$ java --module-path build/nashorn/dependencies:build/nashorn/dist X.java

it works, so seemingly service discovery is just fine with only the declaration 
in module-info.java.

 
Further, in my test app on GitHub I even switched to using 
NashornScriptEngineFactory directly, so that it doesn’t rely on the service 
discovery mechanism, and then it fails with:

java.lang.IllegalArgumentException: Null module name
at 
java.base/jdk.internal.module.Checks.requireModuleName(Checks.java:46) ~[na:na]
at 
java.base/java.lang.module.ModuleDescriptor$Builder.requires(ModuleDescriptor.java:1646)
 ~[na:na]
at 
java.base/java.lang.module.ModuleDescriptor$Builder.requires(ModuleDescriptor.java:1667)
 ~[na:na]
at 
org.openjdk.nashorn.internal.runtime.StructureLoader.createModule(StructureLoader.java:68)
 ~[nashorn-core-15.0.jar:na]
...

which is further evidence that Spring Boot is not loading Nashorn as a JPMS 
module.

Attila.


> On 2020. Dec 13., at 18:07, Remi Forax  wrote:
> 
> Hi Attila,
> for compatibility, you have to both use the new module-info descriptor and 
> the old META-INFO/services when you declare a service.
> 
> It's a shame that jar doesn't do that by itself, it was something we 
> (module/jigsaw EG) discussed but it was never implemented.
> 
> regards,
> Rémi
> 
> - Mail original -
>> De: "Attila Szegedi" 
>> À: "nashorn-dev" 
>> Envoyé: Dimanche 13 Décembre 2020 17:54:06
>> Objet: Nashorn + Spring Boot; help appreciated
> 
>> Hey folks,
>> 
>> seems like folks are trying to use standalone Nashorn with Spring Boot, and 
>> are
>> running into an issue where Boot doesn’t load Nashorn as a JPMS module. If
>> anyone has expertise with this (Spring Boot loading app dependencies as JPMS
>> modules) and can help it’d be most appreciated.
>> 
>> I outlined the problem (and I even have a very small reproducer Boot app) in 
>> a
>> comment on Stack Overflow[0], if you want to help, you’ll find the details
>> there.
>> 
>> Thank you,
>> Attila.
>> 
>> [0]
>> https://stackoverflow.com/questions/65265629/how-to-use-nashorn-in-java-15-or-later/65278158#65278158

Re: Nashorn + Spring Boot; help appreciated

[Remi Forax]

Hi Attila,
for compatibility, you have to both use the new module-info descriptor and the 
old META-INFO/services when you declare a service.

It's a shame that jar doesn't do that by itself, it was something we 
(module/jigsaw EG) discussed but it was never implemented.

regards,
Rémi

- Mail original -
> De: "Attila Szegedi" 
> À: "nashorn-dev" 
> Envoyé: Dimanche 13 Décembre 2020 17:54:06
> Objet: Nashorn + Spring Boot; help appreciated

> Hey folks,
> 
> seems like folks are trying to use standalone Nashorn with Spring Boot, and 
> are
> running into an issue where Boot doesn’t load Nashorn as a JPMS module. If
> anyone has expertise with this (Spring Boot loading app dependencies as JPMS
> modules) and can help it’d be most appreciated.
> 
> I outlined the problem (and I even have a very small reproducer Boot app) in a
> comment on Stack Overflow[0], if you want to help, you’ll find the details
> there.
> 
> Thank you,
>  Attila.
> 
> [0]
> https://stackoverflow.com/questions/65265629/how-to-use-nashorn-in-java-15-or-later/65278158#65278158

Re: Standalone Nashorn 15.0 is out!

[sundararajan . athijegannathan]

Congrats Attila!

-Sundar

On 28/11/20 12:06 am, Attila Szegedi wrote:

Hey everyone,

I’m happy to announce that the first standalone version of Nashorn, 15.0 is now 
available on Maven Central[0]!

This version of Nashorn requires minimum of Java 15 to run. If you want to use 
Nashorn on older Java version, just use the version bundled with the JDK, this 
version has no new features compared to the one in Java 14.

This has been quite a journey, from discussing the idea with OpenJDK 
stakeholders three months ago in August, taking over the Project Lead role, 
getting the project set up on GitHub, actually doing the work on code and the 
build system, and finally getting the artifact publishing set up with Sonatype 
today.

As usual, it takes a village, so I’d like to thank (in approximate 
chronological order of them showing up on this journey) Georges Saab, Mark 
Reinhold, Jim Laskey, Iris Clark, Vladimir Kozlov, Dalibor Topić, Erik 
Duveblad, Sundararajan Athijegannathan, Rémi Forax, Mandy Chung, and Aleksey 
Shipilev for help, support, and advice along the way.

Very excited to hear back from users!

Attila.
  
[0] https://search.maven.org/artifact/org.openjdk.nashorn/nashorn-core/15.0/jar

Re: Standalone Nashorn 15.0 is out!

[Tony Zakula]

Congrats and Thank you!

On Fri, Nov 27, 2020 at 4:28 PM Jamie Mansfield 
wrote:

> Hey Attila,
>
> Congrats to you and team, fab news to see Nashorn back! Great effort
> from you to get us here, and you have my thanks for that :)
>
> Best regards,
> Jamie
>
>
>

Re: Standalone Nashorn 15.0 is out!

[Jamie Mansfield]

Hey Attila,

Congrats to you and team, fab news to see Nashorn back! Great effort
from you to get us here, and you have my thanks for that :)

Best regards,
Jamie

Re: Standalone Nashorn 15.0 is out!

[Nils Kilden-Pedersen]

Congrats! 

On Fri, Nov 27, 2020 at 12:36 PM Attila Szegedi  wrote:

> Hey everyone,
>
> I’m happy to announce that the first standalone version of Nashorn, 15.0
> is now available on Maven Central[0]!
>
> This version of Nashorn requires minimum of Java 15 to run. If you want to
> use Nashorn on older Java version, just use the version bundled with the
> JDK, this version has no new features compared to the one in Java 14.
>
> This has been quite a journey, from discussing the idea with OpenJDK
> stakeholders three months ago in August, taking over the Project Lead role,
> getting the project set up on GitHub, actually doing the work on code and
> the build system, and finally getting the artifact publishing set up with
> Sonatype today.
>
> As usual, it takes a village, so I’d like to thank (in approximate
> chronological order of them showing up on this journey) Georges Saab, Mark
> Reinhold, Jim Laskey, Iris Clark, Vladimir Kozlov, Dalibor Topić, Erik
> Duveblad, Sundararajan Athijegannathan, Rémi Forax, Mandy Chung, and
> Aleksey Shipilev for help, support, and advice along the way.
>
> Very excited to hear back from users!
>
> Attila.
>
> [0]
> https://search.maven.org/artifact/org.openjdk.nashorn/nashorn-core/15.0/jar

Re: Standalone Nashorn bound to specific JVM flavors?

[Attila Szegedi]

I’m happy to expend some effort to make it compatible with other JVMs that 
people want to use. It’s also entirely possible that there’s nothing specific 
to do! There’s nothing in Nashorn that depends on HotSpot. Nashorn is written 
in Java, it generates bytecode, and uses invokedynamic and method handles, 
which are all part of the standard JVM specification. I’d suggest you try it on 
OpenJ9 and report back with your findings. As I said, I’m happy to address 
small snags, and I wouldn’t expect deeper issues.

Attila.

> On 2020. Nov 23., at 18:32, BURRIS Thomas  wrote:
> 
> Hi Attila -- Just to clarify to make sure I understand... So the target JVM 
> flavor for compatibility with Standalone Nashorn will be HotSpot? And -- at 
> least at the moment -- there are no explicit plans to make compatible with 
> (for example) OpenJ9 (aside from turning off anon-classes)?
> 
> As for your question: for our usage, we would not have a need for a lower 
> class version. Can't speak for others...
> 
> thanks for your time!
> 
> Best Regards,
> Thomas BURRIS
> RDF Modeling R Software Architecture Director
> 
> –––
> Office: +1 78 1810 3718
> Mobile: +1 61 7678 9158
> thomas.bur...@3ds.com
> http://www.3ds.com/enovia
> –––
> DS Americas Corp. | 175 Wyman Street | Waltham, MA 02451 | United States
> 
> 
> 
> -Original Message-
> From: Attila Szegedi 
> Sent: Monday, November 23, 2020 11:59 AM
> To: BURRIS Thomas 
> Cc: nashorn-dev@openjdk.java.net
> Subject: Re: Standalone Nashorn bound to specific JVM flavors?
> 
> EXTERNAL EMAIL : The sender of this email is external to 3DS. Be wary of the 
> content and do not open unexpected attachments or links. If you consider this 
> email as spam, you can click the following link 
> https://spam-report.3ds.com/?linktext=https://www.mailcontrol.com/sr/h1GaZGJOvGTGX2PQPOmvUjDF5G4QKHNhl082kiOTzADNbjc452RwRmfbAtROIo3aofl_zynrChD1JTd_1uc-_w==
>   (no login or additional action will be requested).
> 
> 
> It has exactly one dependency on sun.misc.Unsafe - a call to 
> defineAnonymousClass. I’m not aware if that’s available on other JVMs or not, 
> but that might be the only issue I’m aware of. FWIW, Nashorn can be used with 
> --anonymous-classes=false to turn this feature off (it’s a bit of an 
> optimization.)
> 
> As it is, I meant to publish the initial version with javac compiling for 
> Java 15, as I presumed nobody would be interested in using it on earlier Java 
> versions as 14 comes with Nashorn included. I have not released it _just yet_ 
> to Maven central (there’s some permission snags on Sonatype OSS). I’m 
> wondering if there’d be value in compiling with a lower target class version?
> 
> Attila.
> 
>> On 2020. Nov 23., at 17:32, BURRIS Thomas  wrote:
>> 
>> Hi Attila (et. al.) - is there a pre-requisite between the "standalone" 
>> Nashorn and the origin of the JVM ? For example, would it possible to run 
>> the future stand-alone Nashorn and AdoptOpenJDK with OpenJ9 (rather than 
>> HotSpot) ?
>> 
>> 
>> Best Regards,
>> 
>> Thomas BURRIS
>> 
>> RDF Modeling R Software Architecture Director
>> 
>> 
>> 
>> 
>> 
>> Office: +1 78 1810 3718
>> Mobile: +1 61 7678 9158
>> thomas.bur...@3ds.com<mailto:thomas.bur...@3ds.com>
>> 
>> [3DS Logo]
>> 
>> 3DS.COM/ENOVIA<http://www.3ds.com/ENOVIA>
>> 
>> 
>> DS Americas Corp. | 175 Wyman Street | Waltham, MA 02451 | United States
>> 
>> 
>> 
>> This email and any attachments are intended solely for the use of the 
>> individual or entity to whom it is addressed and may be confidential and/or 
>> privileged.
>> 
>> If you are not one of the named recipients or have received this email in 
>> error,
>> 
>> (i) you should not read, disclose, or copy it,
>> 
>> (ii) please notify sender of your receipt by reply email and delete this 
>> email and all attachments,
>> 
>> (iii) Dassault Syst?mes does not accept or assume any liability or 
>> responsibility for any use of or reliance on this email.
>> 
>> 
>> Please be informed that your personal data are processed according to our 
>> data privacy policy as described on our website. Should you have any 
>> questions related to personal data protection, please contact 3DS Data 
>> Protection Officer at 
>> 3ds.compliance-priv...@3ds.com<mailto:3ds.compliance-priv...@3ds.com>
>> 
>> 
>> For other languages, go to https://www.3ds.com/terms/email-disclaimer
> 
> This email and any attachments are intended solely for the use o

Re: Standalone Nashorn bound to specific JVM flavors?

[Remi Forax]

- Mail original -
> De: "BURRIS Thomas" 
> À: "Attila Szegedi" 
> Cc: "nashorn-dev" 
> Envoyé: Lundi 23 Novembre 2020 18:32:37
> Objet: RE: Standalone Nashorn bound to specific JVM flavors?

> Hi Attila -- Just to clarify to make sure I understand... So the target JVM
> flavor for compatibility with Standalone Nashorn will be HotSpot? And -- at
> least at the moment -- there are no explicit plans to make compatible with 
> (for
> example) OpenJ9 (aside from turning off anon-classes)?

OpenJ9 doesn't support constant pool patching of live objects, the last 
parameter of defineAnonymousClass.
Nashorn uses defineAnonymousClass with null as last argument so it should work 
with OpenJ9.

> 
> As for your question: for our usage, we would not have a need for a lower 
> class
> version. Can't speak for others...
> 
> thanks for your time!
> 
> Best Regards,
> Thomas BURRIS
> RDF Modeling R Software Architecture Director

regards,
Rémi

> 
> –––
> Office: +1 78 1810 3718
> Mobile: +1 61 7678 9158
> thomas.bur...@3ds.com
> http://www.3ds.com/enovia
> –––
> DS Americas Corp. | 175 Wyman Street | Waltham, MA 02451 | United States
> 
> 
> 
> -Original Message-
> From: Attila Szegedi 
> Sent: Monday, November 23, 2020 11:59 AM
> To: BURRIS Thomas 
> Cc: nashorn-dev@openjdk.java.net
> Subject: Re: Standalone Nashorn bound to specific JVM flavors?
> 
> EXTERNAL EMAIL : The sender of this email is external to 3DS. Be wary of the
> content and do not open unexpected attachments or links. If you consider this
> email as spam, you can click the following link
> https://spam-report.3ds.com/?linktext=https://www.mailcontrol.com/sr/h1GaZGJOvGTGX2PQPOmvUjDF5G4QKHNhl082kiOTzADNbjc452RwRmfbAtROIo3aofl_zynrChD1JTd_1uc-_w==
> (no login or additional action will be requested).
> 
> 
> It has exactly one dependency on sun.misc.Unsafe - a call to
> defineAnonymousClass. I’m not aware if that’s available on other JVMs or not,
> but that might be the only issue I’m aware of. FWIW, Nashorn can be used with
> --anonymous-classes=false to turn this feature off (it’s a bit of an
> optimization.)
> 
> As it is, I meant to publish the initial version with javac compiling for Java
> 15, as I presumed nobody would be interested in using it on earlier Java
> versions as 14 comes with Nashorn included. I have not released it _just yet_
> to Maven central (there’s some permission snags on Sonatype OSS). I’m 
> wondering
> if there’d be value in compiling with a lower target class version?
> 
> Attila.
> 
>> On 2020. Nov 23., at 17:32, BURRIS Thomas  wrote:
>>
>> Hi Attila (et. al.) - is there a pre-requisite between the "standalone" 
>> Nashorn
>> and the origin of the JVM ? For example, would it possible to run the future
>> stand-alone Nashorn and AdoptOpenJDK with OpenJ9 (rather than HotSpot) ?
>>
>>
>> Best Regards,
>>
>> Thomas BURRIS
>>
>> RDF Modeling R Software Architecture Director
>>
>>
>>
>>
>>
>> Office: +1 78 1810 3718
>> Mobile: +1 61 7678 9158
>> thomas.bur...@3ds.com<mailto:thomas.bur...@3ds.com>
>>
>> [3DS Logo]
>>
>> 3DS.COM/ENOVIA<http://www.3ds.com/ENOVIA>
>>
>>
>> DS Americas Corp. | 175 Wyman Street | Waltham, MA 02451 | United States
>>
>>
>>
>> This email and any attachments are intended solely for the use of the 
>> individual
>> or entity to whom it is addressed and may be confidential and/or privileged.
>>
>> If you are not one of the named recipients or have received this email in 
>> error,
>>
>> (i) you should not read, disclose, or copy it,
>>
>> (ii) please notify sender of your receipt by reply email and delete this 
>> email
>> and all attachments,
>>
>> (iii) Dassault Syst?mes does not accept or assume any liability or
>> responsibility for any use of or reliance on this email.
>>
>>
>> Please be informed that your personal data are processed according to our 
>> data
>> privacy policy as described on our website. Should you have any questions
>> related to personal data protection, please contact 3DS Data Protection 
>> Officer
>> at 3ds.compliance-priv...@3ds.com<mailto:3ds.compliance-priv...@3ds.com>
>>
>>
>> For other languages, go to https://www.3ds.com/terms/email-disclaimer
> 
> This email and any attachments are intended solely for the use of the 
> individual
> or entity to whom it is addressed and may be confidential and/or privileged.
> 
> If you are n

RE: Standalone Nashorn bound to specific JVM flavors?

[BURRIS Thomas]

Hi Attila -- Just to clarify to make sure I understand... So the target JVM 
flavor for compatibility with Standalone Nashorn will be HotSpot? And -- at 
least at the moment -- there are no explicit plans to make compatible with (for 
example) OpenJ9 (aside from turning off anon-classes)?

As for your question: for our usage, we would not have a need for a lower class 
version. Can't speak for others...

thanks for your time!

Best Regards,
Thomas BURRIS
RDF Modeling R Software Architecture Director

–––
Office: +1 78 1810 3718
Mobile: +1 61 7678 9158
thomas.bur...@3ds.com
http://www.3ds.com/enovia
–––
DS Americas Corp. | 175 Wyman Street | Waltham, MA 02451 | United States



-Original Message-
From: Attila Szegedi 
Sent: Monday, November 23, 2020 11:59 AM
To: BURRIS Thomas 
Cc: nashorn-dev@openjdk.java.net
Subject: Re: Standalone Nashorn bound to specific JVM flavors?

EXTERNAL EMAIL : The sender of this email is external to 3DS. Be wary of the 
content and do not open unexpected attachments or links. If you consider this 
email as spam, you can click the following link 
https://spam-report.3ds.com/?linktext=https://www.mailcontrol.com/sr/h1GaZGJOvGTGX2PQPOmvUjDF5G4QKHNhl082kiOTzADNbjc452RwRmfbAtROIo3aofl_zynrChD1JTd_1uc-_w==
  (no login or additional action will be requested).


It has exactly one dependency on sun.misc.Unsafe - a call to 
defineAnonymousClass. I’m not aware if that’s available on other JVMs or not, 
but that might be the only issue I’m aware of. FWIW, Nashorn can be used with 
--anonymous-classes=false to turn this feature off (it’s a bit of an 
optimization.)

As it is, I meant to publish the initial version with javac compiling for Java 
15, as I presumed nobody would be interested in using it on earlier Java 
versions as 14 comes with Nashorn included. I have not released it _just yet_ 
to Maven central (there’s some permission snags on Sonatype OSS). I’m wondering 
if there’d be value in compiling with a lower target class version?

Attila.

> On 2020. Nov 23., at 17:32, BURRIS Thomas  wrote:
>
> Hi Attila (et. al.) - is there a pre-requisite between the "standalone" 
> Nashorn and the origin of the JVM ? For example, would it possible to run the 
> future stand-alone Nashorn and AdoptOpenJDK with OpenJ9 (rather than HotSpot) 
> ?
>
>
> Best Regards,
>
> Thomas BURRIS
>
> RDF Modeling R Software Architecture Director
>
>
>
>
>
> Office: +1 78 1810 3718
> Mobile: +1 61 7678 9158
> thomas.bur...@3ds.com<mailto:thomas.bur...@3ds.com>
>
> [3DS Logo]
>
> 3DS.COM/ENOVIA<http://www.3ds.com/ENOVIA>
>
>
> DS Americas Corp. | 175 Wyman Street | Waltham, MA 02451 | United States
>
>
>
> This email and any attachments are intended solely for the use of the 
> individual or entity to whom it is addressed and may be confidential and/or 
> privileged.
>
> If you are not one of the named recipients or have received this email in 
> error,
>
> (i) you should not read, disclose, or copy it,
>
> (ii) please notify sender of your receipt by reply email and delete this 
> email and all attachments,
>
> (iii) Dassault Syst?mes does not accept or assume any liability or 
> responsibility for any use of or reliance on this email.
>
>
> Please be informed that your personal data are processed according to our 
> data privacy policy as described on our website. Should you have any 
> questions related to personal data protection, please contact 3DS Data 
> Protection Officer at 
> 3ds.compliance-priv...@3ds.com<mailto:3ds.compliance-priv...@3ds.com>
>
>
> For other languages, go to https://www.3ds.com/terms/email-disclaimer

This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
at 3ds.compliance-priv...@3ds.com<mailto:3ds.compliance-priv...@3ds.com>


For other languages, go to https://www.3ds.com/terms/email-disclaimer

Re: Standalone Nashorn bound to specific JVM flavors?

[Attila Szegedi]

It has exactly one dependency on sun.misc.Unsafe - a call to 
defineAnonymousClass. I’m not aware if that’s available on other JVMs or not, 
but that might be the only issue I’m aware of. FWIW, Nashorn can be used with 
--anonymous-classes=false to turn this feature off (it’s a bit of an 
optimization.) 

As it is, I meant to publish the initial version with javac compiling for Java 
15, as I presumed nobody would be interested in using it on earlier Java 
versions as 14 comes with Nashorn included. I have not released it _just yet_ 
to Maven central (there’s some permission snags on Sonatype OSS). I’m wondering 
if there’d be value in compiling with a lower target class version?

Attila.

> On 2020. Nov 23., at 17:32, BURRIS Thomas  wrote:
> 
> Hi Attila (et. al.) - is there a pre-requisite between the "standalone" 
> Nashorn and the origin of the JVM ? For example, would it possible to run the 
> future stand-alone Nashorn and AdoptOpenJDK with OpenJ9 (rather than HotSpot) 
> ?
> 
> 
> Best Regards,
> 
> Thomas BURRIS
> 
> RDF Modeling R Software Architecture Director
> 
> 
> 
> 
> 
> Office: +1 78 1810 3718
> Mobile: +1 61 7678 9158
> thomas.bur...@3ds.com
> 
> [3DS Logo]
> 
> 3DS.COM/ENOVIA
> 
> 
> DS Americas Corp. | 175 Wyman Street | Waltham, MA 02451 | United States
> 
> 
> 
> This email and any attachments are intended solely for the use of the 
> individual or entity to whom it is addressed and may be confidential and/or 
> privileged.
> 
> If you are not one of the named recipients or have received this email in 
> error,
> 
> (i) you should not read, disclose, or copy it,
> 
> (ii) please notify sender of your receipt by reply email and delete this 
> email and all attachments,
> 
> (iii) Dassault Syst?mes does not accept or assume any liability or 
> responsibility for any use of or reliance on this email.
> 
> 
> Please be informed that your personal data are processed according to our 
> data privacy policy as described on our website. Should you have any 
> questions related to personal data protection, please contact 3DS Data 
> Protection Officer at 
> 3ds.compliance-priv...@3ds.com
> 
> 
> For other languages, go to https://www.3ds.com/terms/email-disclaimer

Fix for NashornScriptEngineFactory.getOutputStatement(toDisplay) (Re: Standalone Nashorn is coming for Java 15+

[Rony G. Flatscher]

Hi there,

the NashornScriptEngineFactory.getOutputStatement() does not create a valid 
String from the
toDisplay argument. As a result it is not possible to create correct Javascript 
statements that
output strings created with that method (Nashorn creates an exception when 
running a statement it
created itself).

The input string toDisplay:

~~~
'hello world', this is "ECMAScript" speaking!
~~~

The current getOutputStatement(toDisplay) returns the syntaxtically wrong 
output statement (will
cause an exception):

~~~
print('hello world', this is "ECMAScript" speaking!)
~~~

The following git diff would apply double-quotes and escape double-quotes, if 
they are part of the
supplied toDisplay argument:

~~~

G:\dev\openjfx\nashorn\src\org.openjdk.nashorn\share\classes\org\openjdk\nashorn\api\scripting>git
 diff
diff --git 
a/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/api/scripting/NashornScriptEngineFactory.java
 
b/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/api/scripting/NashornScriptEngineFactory.java
index 8dc8895a..59d5d60b 100644
--- 
a/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/api/scripting/NashornScriptEngineFactory.java
+++ 
b/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/api/scripting/NashornScriptEngineFactory.java
@@ -104,7 +104,7 @@ public final class NashornScriptEngineFactory 
implements ScriptEngineFactory {

 @Override
 public String getOutputStatement(final String toDisplay) {
-return "print(" + toDisplay + ")";
+return "print(\"" + toDisplay.replace("\"","\\\"") + "\")";
 }

 @Override
~~~

The corrected getOutputStatement(toDisplay) with the change returns:

~~~
print("'hello world', this is \"ECMAScript\" speaking!")
~~~

Please advise how to best proceed in order to fix this long standing bug.

---rony

P.S.: If you want you can take that code directly as I signed the Oracle 
Contributor Agreement and
submitted changes in the OpenJFX project in the past.


On 15.11.2020 18:25, Attila Szegedi wrote:
> Hi y’all,
>
> openjdk/nashorn repo is up and its main branch is populated with the initial 
> copy of Nashorn as it existed in JDK 14. I added a fix for wrong/missing 
> licenses for two files (agreed with Oracle) and an initial project README on 
> top of it.
>
> An even better news is that I have the initial standalone Nashorn 15.0.0 PR 
> up ready for review. It is at:
>
> 
>
>
> The PR describes the steps to build the artifacts. I’d like to encourage 
> everyone here to try it out and report back with your experiences, and to 
> also give an earnest review of the PR. If it works out okay, we could merge 
> this into main in the next few days and then I can get the artifacts 
> published into Maven Central!
>
> Attila.
>
>> On 2020. Oct 25., at 18:07, Attila Szegedi  wrote:
>>
>> Hi y’all,
>>
>> trying to get into the habit of making these weekly updates until I have 
>> something else to show.
>>
>> * With Remi’s, Sundar’s and Mandy’s help I fixed anonymous code loading. 
>> We’ll be using the sun.misc.Unsafe for now, with hope to transition to 
>> Lookup.defineHiddenClass somewhere down the line.
>>
>> * I started using Ivy as the dependency manager in our build.xml, and right 
>> now I also have an Ant task that builds all the artifacts for Maven 
>> publication. 
>>
>> The first version of Maven artifacts (jar, javadoc, sources, Maven pom file) 
>> is basically ready to go. All we’re waiting for is for Oracle to create the 
>> openjdk/nashorn repository and approve its initial contents. I started the 
>> relevant conversation about it 12 days ago… it is going slower than I hoped 
>> for.
>>
>> What do you all think of the version number? Nashorn never had its own 
>> separate version number, but I’m thinking we could start the standalone 
>> version at 15. I don’t expect we’ll remain in lockstep with OpenJDK (so 
>> it’ll remain at 15 significantly longer), but it might be a good strategy to 
>> at least retroactively be able to talk about it without confusion, e.g. 
>> “Nashorn 11” is Nashorn-as-in-Java-11 and “Nashorn 14” is 
>> Nashorn-as-in-Java-14. And “Nashorn 15” is then quite naturally the first 
>> standalone version.
>>
>> Attila.
>>
>>> On 2020. Oct 19., at 17:16, Attila Szegedi  wrote:
>>>
>>> Hi y’all,
>>>
>>> a quick update with regard of what’s been happening since the last post.
>>>
>>> * I’m talking with folks at Oracle about setting up the openjdk/nashorn 
>>> repo. We’re hashing out what the initial content of the repo should be.
>>>
>>> * The licensing for the standalone Nashorn is confirmed to be 
>>> GPLv2+Classpath exception.
>>>
>>> * In anticipation of getting a public repo, I’ve been not sitting idle, but 
>>> rather I’m working in a private repo to get ahead with the necessary 
>>> adaptations. I have a version now that passes the 

Re: Standalone Nashorn is coming for Java 15+

[Jamie Mansfield]

Hey ;)

> I don’t know how does Gradle stack up against Maven when it comes to
> signing and publishing artifacts.

Gradle includes a 'signing' plugin [1] and a 'maven-publish' plugin [2]
that can be combined [3] to provide sufficient metadata for the Central
repository.

While I'm no expert, I'm happy to field questions related to Gradle -
or enquire those more knowledgeable than myself to answer :)

Regards,
Jamie

[1]: https://docs.gradle.org/current/userguide/signing_plugin.html
[2]: https://docs.gradle.org/current/userguide/publishing_maven.html
[3]: https://github.com/CadixDev/Lorenz/blob/
49be5233bff0adfaf59440ac37efdeccbb2893da/build.gradle.kts#L67-L140

Re: Standalone Nashorn is coming for Java 15+

[Attila Szegedi]

Thanks Ben, FWIW, I just gave up on using Ivy in the PR; the behavior between 
2.4.0 and 2.5.0 changed significantly and I decided the added value of Ivy is 
not proportional to the newly arisen headaches.

I absolutely want to move away from Ant; once 15.0 is out I’d like to switch to 
either Gradle or Maven. I don’t have a strong preference for either, although 
Gradle feels a bit more accessible to me. OTOH, I don’t know how does Gradle 
stack up against Maven when it comes to signing and publishing artifacts. (It’s 
probably fine.) 

Ideally, I’d like to attract someone to the project to do it as it will still 
be a bit involved, as Nashorn test running is fairly customized (we run one 
smaller suite of tests without a security manager, and a larger with a security 
manager, and we run them all both without and with optimistic typing.) There’s 
also the “nasgen” component, which is a separately-run annotation processor, 
which ideally could be moved into the javac step as a compiler-run annotation 
processor. So, there’s plenty of work to make it happen, but I’d like it to 
happen.

Attila.

> On 2020. Nov 17., at 12:53, Ben Evans  wrote:
> 
> Thanks Isaiah - I totally missed that point in the thread.
> 
> I'll hit up some Ivy folks I know and see if they're interested in
> helping with this.
> 
> Ben
> 
> On Tue, 17 Nov 2020 at 12:50, Isaiah Peng  wrote:
>> 
>> FYI, the reason for using Any is specified in the thread:
>> 
>>> I still need to figure out the minimal descriptive pom.xml (dependencies 
>>> etc., no build information) in order to be able to produce Maven artifacts. 
>>> Right now, Nashorn’s build and test process is highly customized set of Ant 
>>> build.xml files, so it can’t just be converted to “vanilla” Maven or 
>>> Gradle. It’s a long term goal though (to switch it from our custom Ant 
>>> build.xml to either one of these.) Initially, it might make sense to use 
>>> Apache Ivy within our Ant build to handle both dependencies and publication.
>> 
>> Ben Evans  于 2020年11月17日周二 上午10:37写道：
>>> 
>>> Thanks for all the work you've done on this, Attila.
>>> 
>>> Quick question: The project still seems to be using Ant. Is there a
>>> reason for that? Would you merge a PR that ported the build system to
>>> Maven or Gradle instead? (and if so, do you have a preference for
>>> either one?) IME, Ant is rather inaccessible as a tool these days, and
>>> so it might be a good idea to get off it early on.
>>> 
>>> Thanks,
>>> 
>>> Ben
>>> 
>>> On Sun, 15 Nov 2020 at 18:26, Attila Szegedi  wrote:
 
 Hi y’all,
 
 openjdk/nashorn repo is up and its main branch is populated with the 
 initial copy of Nashorn as it existed in JDK 14. I added a fix for 
 wrong/missing licenses for two files (agreed with Oracle) and an initial 
 project README on top of it.
 
 An even better news is that I have the initial standalone Nashorn 15.0.0 
 PR up ready for review. It is at:
 
 
 
 
 The PR describes the steps to build the artifacts. I’d like to encourage 
 everyone here to try it out and report back with your experiences, and to 
 also give an earnest review of the PR. If it works out okay, we could 
 merge this into main in the next few days and then I can get the artifacts 
 published into Maven Central!
 
 Attila.
 
> On 2020. Oct 25., at 18:07, Attila Szegedi  wrote:
> 
> Hi y’all,
> 
> trying to get into the habit of making these weekly updates until I have 
> something else to show.
> 
> * With Remi’s, Sundar’s and Mandy’s help I fixed anonymous code loading. 
> We’ll be using the sun.misc.Unsafe for now, with hope to transition to 
> Lookup.defineHiddenClass somewhere down the line.
> 
> * I started using Ivy as the dependency manager in our build.xml, and 
> right now I also have an Ant task that builds all the artifacts for Maven 
> publication.
> 
> The first version of Maven artifacts (jar, javadoc, sources, Maven pom 
> file) is basically ready to go. All we’re waiting for is for Oracle to 
> create the openjdk/nashorn repository and approve its initial contents. I 
> started the relevant conversation about it 12 days ago… it is going 
> slower than I hoped for.
> 
> What do you all think of the version number? Nashorn never had its own 
> separate version number, but I’m thinking we could start the standalone 
> version at 15. I don’t expect we’ll remain in lockstep with OpenJDK (so 
> it’ll remain at 15 significantly longer), but it might be a good strategy 
> to at least retroactively be able to talk about it without confusion, 
> e.g. “Nashorn 11” is Nashorn-as-in-Java-11 and “Nashorn 14” is 
> Nashorn-as-in-Java-14. And “Nashorn 15” is then quite naturally the first 
> standalone version.
> 
> Attila.
> 
>> On 2020. Oct 19., at 17:16, 

Re: Standalone Nashorn is coming for Java 15+

[Ben Evans]

Thanks Isaiah - I totally missed that point in the thread.

I'll hit up some Ivy folks I know and see if they're interested in
helping with this.

Ben

On Tue, 17 Nov 2020 at 12:50, Isaiah Peng  wrote:
>
> FYI, the reason for using Any is specified in the thread:
>
> > I still need to figure out the minimal descriptive pom.xml (dependencies 
> > etc., no build information) in order to be able to produce Maven artifacts. 
> > Right now, Nashorn’s build and test process is highly customized set of Ant 
> > build.xml files, so it can’t just be converted to “vanilla” Maven or 
> > Gradle. It’s a long term goal though (to switch it from our custom Ant 
> > build.xml to either one of these.) Initially, it might make sense to use 
> > Apache Ivy within our Ant build to handle both dependencies and publication.
>
> Ben Evans  于 2020年11月17日周二 上午10:37写道：
>>
>> Thanks for all the work you've done on this, Attila.
>>
>> Quick question: The project still seems to be using Ant. Is there a
>> reason for that? Would you merge a PR that ported the build system to
>> Maven or Gradle instead? (and if so, do you have a preference for
>> either one?) IME, Ant is rather inaccessible as a tool these days, and
>> so it might be a good idea to get off it early on.
>>
>> Thanks,
>>
>> Ben
>>
>> On Sun, 15 Nov 2020 at 18:26, Attila Szegedi  wrote:
>> >
>> > Hi y’all,
>> >
>> > openjdk/nashorn repo is up and its main branch is populated with the 
>> > initial copy of Nashorn as it existed in JDK 14. I added a fix for 
>> > wrong/missing licenses for two files (agreed with Oracle) and an initial 
>> > project README on top of it.
>> >
>> > An even better news is that I have the initial standalone Nashorn 15.0.0 
>> > PR up ready for review. It is at:
>> >
>> > 
>> >
>> >
>> > The PR describes the steps to build the artifacts. I’d like to encourage 
>> > everyone here to try it out and report back with your experiences, and to 
>> > also give an earnest review of the PR. If it works out okay, we could 
>> > merge this into main in the next few days and then I can get the artifacts 
>> > published into Maven Central!
>> >
>> > Attila.
>> >
>> > > On 2020. Oct 25., at 18:07, Attila Szegedi  wrote:
>> > >
>> > > Hi y’all,
>> > >
>> > > trying to get into the habit of making these weekly updates until I have 
>> > > something else to show.
>> > >
>> > > * With Remi’s, Sundar’s and Mandy’s help I fixed anonymous code loading. 
>> > > We’ll be using the sun.misc.Unsafe for now, with hope to transition to 
>> > > Lookup.defineHiddenClass somewhere down the line.
>> > >
>> > > * I started using Ivy as the dependency manager in our build.xml, and 
>> > > right now I also have an Ant task that builds all the artifacts for 
>> > > Maven publication.
>> > >
>> > > The first version of Maven artifacts (jar, javadoc, sources, Maven pom 
>> > > file) is basically ready to go. All we’re waiting for is for Oracle to 
>> > > create the openjdk/nashorn repository and approve its initial contents. 
>> > > I started the relevant conversation about it 12 days ago… it is going 
>> > > slower than I hoped for.
>> > >
>> > > What do you all think of the version number? Nashorn never had its own 
>> > > separate version number, but I’m thinking we could start the standalone 
>> > > version at 15. I don’t expect we’ll remain in lockstep with OpenJDK (so 
>> > > it’ll remain at 15 significantly longer), but it might be a good 
>> > > strategy to at least retroactively be able to talk about it without 
>> > > confusion, e.g. “Nashorn 11” is Nashorn-as-in-Java-11 and “Nashorn 14” 
>> > > is Nashorn-as-in-Java-14. And “Nashorn 15” is then quite naturally the 
>> > > first standalone version.
>> > >
>> > > Attila.
>> > >
>> > >> On 2020. Oct 19., at 17:16, Attila Szegedi  wrote:
>> > >>
>> > >> Hi y’all,
>> > >>
>> > >> a quick update with regard of what’s been happening since the last post.
>> > >>
>> > >> * I’m talking with folks at Oracle about setting up the openjdk/nashorn 
>> > >> repo. We’re hashing out what the initial content of the repo should be.
>> > >>
>> > >> * The licensing for the standalone Nashorn is confirmed to be 
>> > >> GPLv2+Classpath exception.
>> > >>
>> > >> * In anticipation of getting a public repo, I’ve been not sitting idle, 
>> > >> but rather I’m working in a private repo to get ahead with the 
>> > >> necessary adaptations. I have a version now that passes the internal 
>> > >> test suite (with an asterisk) and passes the whole test262[0] suite (no 
>> > >> asterisk there, it all passes.)
>> > >>
>> > >> * I still need to figure out the minimal descriptive pom.xml 
>> > >> (dependencies etc., no build information) in order to be able to 
>> > >> produce Maven artifacts. Right now, Nashorn’s build and test process is 
>> > >> highly customized set of Ant build.xml files, so it can’t just be 
>> > >> converted to “vanilla” Maven or Gradle. It’s a long term goal though 
>> > >> (to switch it 

Re: Standalone Nashorn is coming for Java 15+

[Isaiah Peng]

FYI, the reason for using Any is specified in the thread:

> I still need to figure out the minimal descriptive pom.xml (dependencies
etc., no build information) in order to be able to produce Maven artifacts.
Right now, Nashorn’s build and test process is highly customized set of Ant
build.xml files, so it can’t just be converted to “vanilla” Maven or
Gradle. It’s a long term goal though (to switch it from our custom Ant
build.xml to either one of these.) Initially, it might make sense to use
Apache Ivy within our Ant build to handle both dependencies and publication.

Ben Evans  于 2020年11月17日周二 上午10:37写道：

> Thanks for all the work you've done on this, Attila.
>
> Quick question: The project still seems to be using Ant. Is there a
> reason for that? Would you merge a PR that ported the build system to
> Maven or Gradle instead? (and if so, do you have a preference for
> either one?) IME, Ant is rather inaccessible as a tool these days, and
> so it might be a good idea to get off it early on.
>
> Thanks,
>
> Ben
>
> On Sun, 15 Nov 2020 at 18:26, Attila Szegedi  wrote:
> >
> > Hi y’all,
> >
> > openjdk/nashorn repo is up and its main branch is populated with the
> initial copy of Nashorn as it existed in JDK 14. I added a fix for
> wrong/missing licenses for two files (agreed with Oracle) and an initial
> project README on top of it.
> >
> > An even better news is that I have the initial standalone Nashorn 15.0.0
> PR up ready for review. It is at:
> >
> > 
> >
> >
> > The PR describes the steps to build the artifacts. I’d like to encourage
> everyone here to try it out and report back with your experiences, and to
> also give an earnest review of the PR. If it works out okay, we could merge
> this into main in the next few days and then I can get the artifacts
> published into Maven Central!
> >
> > Attila.
> >
> > > On 2020. Oct 25., at 18:07, Attila Szegedi  wrote:
> > >
> > > Hi y’all,
> > >
> > > trying to get into the habit of making these weekly updates until I
> have something else to show.
> > >
> > > * With Remi’s, Sundar’s and Mandy’s help I fixed anonymous code
> loading. We’ll be using the sun.misc.Unsafe for now, with hope to
> transition to Lookup.defineHiddenClass somewhere down the line.
> > >
> > > * I started using Ivy as the dependency manager in our build.xml, and
> right now I also have an Ant task that builds all the artifacts for Maven
> publication.
> > >
> > > The first version of Maven artifacts (jar, javadoc, sources, Maven pom
> file) is basically ready to go. All we’re waiting for is for Oracle to
> create the openjdk/nashorn repository and approve its initial contents. I
> started the relevant conversation about it 12 days ago… it is going slower
> than I hoped for.
> > >
> > > What do you all think of the version number? Nashorn never had its own
> separate version number, but I’m thinking we could start the standalone
> version at 15. I don’t expect we’ll remain in lockstep with OpenJDK (so
> it’ll remain at 15 significantly longer), but it might be a good strategy
> to at least retroactively be able to talk about it without confusion, e.g.
> “Nashorn 11” is Nashorn-as-in-Java-11 and “Nashorn 14” is
> Nashorn-as-in-Java-14. And “Nashorn 15” is then quite naturally the first
> standalone version.
> > >
> > > Attila.
> > >
> > >> On 2020. Oct 19., at 17:16, Attila Szegedi 
> wrote:
> > >>
> > >> Hi y’all,
> > >>
> > >> a quick update with regard of what’s been happening since the last
> post.
> > >>
> > >> * I’m talking with folks at Oracle about setting up the
> openjdk/nashorn repo. We’re hashing out what the initial content of the
> repo should be.
> > >>
> > >> * The licensing for the standalone Nashorn is confirmed to be
> GPLv2+Classpath exception.
> > >>
> > >> * In anticipation of getting a public repo, I’ve been not sitting
> idle, but rather I’m working in a private repo to get ahead with the
> necessary adaptations. I have a version now that passes the internal test
> suite (with an asterisk) and passes the whole test262[0] suite (no asterisk
> there, it all passes.)
> > >>
> > >> * I still need to figure out the minimal descriptive pom.xml
> (dependencies etc., no build information) in order to be able to produce
> Maven artifacts. Right now, Nashorn’s build and test process is highly
> customized set of Ant build.xml files, so it can’t just be converted to
> “vanilla” Maven or Gradle. It’s a long term goal though (to switch it from
> our custom Ant build.xml to either one of these.) Initially, it might make
> sense to use Apache Ivy within our Ant build to handle both dependencies
> and publication.
> > >>
> > >> As for test suite asterisks:
> > >>
> > >> * For now, I moved all the jjs related tests into “currently failing”
> directory as I did not have time to figure out how to build jjs. We can
> sort out later if/when/how we want to resurrect jjs.
> > >>
> > >> * sandbox/nashorninternals.js test is moved to 

Re: Standalone Nashorn is coming for Java 15+

[Ben Evans]

Thanks for all the work you've done on this, Attila.

Quick question: The project still seems to be using Ant. Is there a
reason for that? Would you merge a PR that ported the build system to
Maven or Gradle instead? (and if so, do you have a preference for
either one?) IME, Ant is rather inaccessible as a tool these days, and
so it might be a good idea to get off it early on.

Thanks,

Ben

On Sun, 15 Nov 2020 at 18:26, Attila Szegedi  wrote:
>
> Hi y’all,
>
> openjdk/nashorn repo is up and its main branch is populated with the initial 
> copy of Nashorn as it existed in JDK 14. I added a fix for wrong/missing 
> licenses for two files (agreed with Oracle) and an initial project README on 
> top of it.
>
> An even better news is that I have the initial standalone Nashorn 15.0.0 PR 
> up ready for review. It is at:
>
> 
>
>
> The PR describes the steps to build the artifacts. I’d like to encourage 
> everyone here to try it out and report back with your experiences, and to 
> also give an earnest review of the PR. If it works out okay, we could merge 
> this into main in the next few days and then I can get the artifacts 
> published into Maven Central!
>
> Attila.
>
> > On 2020. Oct 25., at 18:07, Attila Szegedi  wrote:
> >
> > Hi y’all,
> >
> > trying to get into the habit of making these weekly updates until I have 
> > something else to show.
> >
> > * With Remi’s, Sundar’s and Mandy’s help I fixed anonymous code loading. 
> > We’ll be using the sun.misc.Unsafe for now, with hope to transition to 
> > Lookup.defineHiddenClass somewhere down the line.
> >
> > * I started using Ivy as the dependency manager in our build.xml, and right 
> > now I also have an Ant task that builds all the artifacts for Maven 
> > publication.
> >
> > The first version of Maven artifacts (jar, javadoc, sources, Maven pom 
> > file) is basically ready to go. All we’re waiting for is for Oracle to 
> > create the openjdk/nashorn repository and approve its initial contents. I 
> > started the relevant conversation about it 12 days ago… it is going slower 
> > than I hoped for.
> >
> > What do you all think of the version number? Nashorn never had its own 
> > separate version number, but I’m thinking we could start the standalone 
> > version at 15. I don’t expect we’ll remain in lockstep with OpenJDK (so 
> > it’ll remain at 15 significantly longer), but it might be a good strategy 
> > to at least retroactively be able to talk about it without confusion, e.g. 
> > “Nashorn 11” is Nashorn-as-in-Java-11 and “Nashorn 14” is 
> > Nashorn-as-in-Java-14. And “Nashorn 15” is then quite naturally the first 
> > standalone version.
> >
> > Attila.
> >
> >> On 2020. Oct 19., at 17:16, Attila Szegedi  wrote:
> >>
> >> Hi y’all,
> >>
> >> a quick update with regard of what’s been happening since the last post.
> >>
> >> * I’m talking with folks at Oracle about setting up the openjdk/nashorn 
> >> repo. We’re hashing out what the initial content of the repo should be.
> >>
> >> * The licensing for the standalone Nashorn is confirmed to be 
> >> GPLv2+Classpath exception.
> >>
> >> * In anticipation of getting a public repo, I’ve been not sitting idle, 
> >> but rather I’m working in a private repo to get ahead with the necessary 
> >> adaptations. I have a version now that passes the internal test suite 
> >> (with an asterisk) and passes the whole test262[0] suite (no asterisk 
> >> there, it all passes.)
> >>
> >> * I still need to figure out the minimal descriptive pom.xml (dependencies 
> >> etc., no build information) in order to be able to produce Maven 
> >> artifacts. Right now, Nashorn’s build and test process is highly 
> >> customized set of Ant build.xml files, so it can’t just be converted to 
> >> “vanilla” Maven or Gradle. It’s a long term goal though (to switch it from 
> >> our custom Ant build.xml to either one of these.) Initially, it might make 
> >> sense to use Apache Ivy within our Ant build to handle both dependencies 
> >> and publication.
> >>
> >> As for test suite asterisks:
> >>
> >> * For now, I moved all the jjs related tests into “currently failing” 
> >> directory as I did not have time to figure out how to build jjs. We can 
> >> sort out later if/when/how we want to resurrect jjs.
> >>
> >> * sandbox/nashorninternals.js test is moved to “currently failing” too. 
> >> I’m pretty sure that what it’s been testing is no longer relevant. Tests 
> >> artificially are restricted from accessing internal Nashorn internal 
> >> packages and this is validated. Unfortunately, keeping Nashorn internals 
> >> in the list of access-checked packages causes lots of issues for Nashorn 
> >> itself in the tests, so I removed internal packages from the access-check 
> >> list. I separately kept a test package that’s used to assert scripts can’t 
> >> access such packages, and it works fine.
> >>
> >> * for now, I disabled anonymous code loading. It’s a funny one. Nashorn 
> >> 

Re: Standalone Nashorn is coming for Java 15+

[Attila Szegedi]

For anyone who doesn’t want to build this from sources themselves, but want to 
try it, I put a preliminary prebuilt version in my Dropbox at 


Attila.

> On 2020. Nov 15., at 18:25, Attila Szegedi  wrote:
> 
> Hi y’all,
> 
> openjdk/nashorn repo is up and its main branch is populated with the initial 
> copy of Nashorn as it existed in JDK 14. I added a fix for wrong/missing 
> licenses for two files (agreed with Oracle) and an initial project README on 
> top of it.
> 
> An even better news is that I have the initial standalone Nashorn 15.0.0 PR 
> up ready for review. It is at:
> 
> 
> 
> 
> The PR describes the steps to build the artifacts. I’d like to encourage 
> everyone here to try it out and report back with your experiences, and to 
> also give an earnest review of the PR. If it works out okay, we could merge 
> this into main in the next few days and then I can get the artifacts 
> published into Maven Central!
> 
> Attila.
> 
>> On 2020. Oct 25., at 18:07, Attila Szegedi  wrote:
>> 
>> Hi y’all,
>> 
>> trying to get into the habit of making these weekly updates until I have 
>> something else to show.
>> 
>> * With Remi’s, Sundar’s and Mandy’s help I fixed anonymous code loading. 
>> We’ll be using the sun.misc.Unsafe for now, with hope to transition to 
>> Lookup.defineHiddenClass somewhere down the line.
>> 
>> * I started using Ivy as the dependency manager in our build.xml, and right 
>> now I also have an Ant task that builds all the artifacts for Maven 
>> publication. 
>> 
>> The first version of Maven artifacts (jar, javadoc, sources, Maven pom file) 
>> is basically ready to go. All we’re waiting for is for Oracle to create the 
>> openjdk/nashorn repository and approve its initial contents. I started the 
>> relevant conversation about it 12 days ago… it is going slower than I hoped 
>> for.
>> 
>> What do you all think of the version number? Nashorn never had its own 
>> separate version number, but I’m thinking we could start the standalone 
>> version at 15. I don’t expect we’ll remain in lockstep with OpenJDK (so 
>> it’ll remain at 15 significantly longer), but it might be a good strategy to 
>> at least retroactively be able to talk about it without confusion, e.g. 
>> “Nashorn 11” is Nashorn-as-in-Java-11 and “Nashorn 14” is 
>> Nashorn-as-in-Java-14. And “Nashorn 15” is then quite naturally the first 
>> standalone version.
>> 
>> Attila.
>> 
>>> On 2020. Oct 19., at 17:16, Attila Szegedi  wrote:
>>> 
>>> Hi y’all,
>>> 
>>> a quick update with regard of what’s been happening since the last post.
>>> 
>>> * I’m talking with folks at Oracle about setting up the openjdk/nashorn 
>>> repo. We’re hashing out what the initial content of the repo should be.
>>> 
>>> * The licensing for the standalone Nashorn is confirmed to be 
>>> GPLv2+Classpath exception.
>>> 
>>> * In anticipation of getting a public repo, I’ve been not sitting idle, but 
>>> rather I’m working in a private repo to get ahead with the necessary 
>>> adaptations. I have a version now that passes the internal test suite (with 
>>> an asterisk) and passes the whole test262[0] suite (no asterisk there, it 
>>> all passes.)
>>> 
>>> * I still need to figure out the minimal descriptive pom.xml (dependencies 
>>> etc., no build information) in order to be able to produce Maven artifacts. 
>>> Right now, Nashorn’s build and test process is highly customized set of Ant 
>>> build.xml files, so it can’t just be converted to “vanilla” Maven or 
>>> Gradle. It’s a long term goal though (to switch it from our custom Ant 
>>> build.xml to either one of these.) Initially, it might make sense to use 
>>> Apache Ivy within our Ant build to handle both dependencies and publication.
>>> 
>>> As for test suite asterisks:
>>> 
>>> * For now, I moved all the jjs related tests into “currently failing” 
>>> directory as I did not have time to figure out how to build jjs. We can 
>>> sort out later if/when/how we want to resurrect jjs.
>>> 
>>> * sandbox/nashorninternals.js test is moved to “currently failing” too. I’m 
>>> pretty sure that what it’s been testing is no longer relevant. Tests 
>>> artificially are restricted from accessing internal Nashorn internal 
>>> packages and this is validated. Unfortunately, keeping Nashorn internals in 
>>> the list of access-checked packages causes lots of issues for Nashorn 
>>> itself in the tests, so I removed internal packages from the access-check 
>>> list. I separately kept a test package that’s used to assert scripts can’t 
>>> access such packages, and it works fine.
>>> 
>>> * for now, I disabled anonymous code loading. It’s a funny one. Nashorn has 
>>> a feature called “anonymous code loading” that it uses for somewhat 
>>> lighter-weight loading of code as it compiles JavaScript functions 
>>> one-by-one into bytecode classes. Unfortunately, it uses 
>>> 

Re: Standalone Nashorn is coming for Java 15+

[Attila Szegedi]

Hi y’all,

openjdk/nashorn repo is up and its main branch is populated with the initial 
copy of Nashorn as it existed in JDK 14. I added a fix for wrong/missing 
licenses for two files (agreed with Oracle) and an initial project README on 
top of it.

An even better news is that I have the initial standalone Nashorn 15.0.0 PR up 
ready for review. It is at:




The PR describes the steps to build the artifacts. I’d like to encourage 
everyone here to try it out and report back with your experiences, and to also 
give an earnest review of the PR. If it works out okay, we could merge this 
into main in the next few days and then I can get the artifacts published into 
Maven Central!

Attila.

> On 2020. Oct 25., at 18:07, Attila Szegedi  wrote:
> 
> Hi y’all,
> 
> trying to get into the habit of making these weekly updates until I have 
> something else to show.
> 
> * With Remi’s, Sundar’s and Mandy’s help I fixed anonymous code loading. 
> We’ll be using the sun.misc.Unsafe for now, with hope to transition to 
> Lookup.defineHiddenClass somewhere down the line.
> 
> * I started using Ivy as the dependency manager in our build.xml, and right 
> now I also have an Ant task that builds all the artifacts for Maven 
> publication. 
> 
> The first version of Maven artifacts (jar, javadoc, sources, Maven pom file) 
> is basically ready to go. All we’re waiting for is for Oracle to create the 
> openjdk/nashorn repository and approve its initial contents. I started the 
> relevant conversation about it 12 days ago… it is going slower than I hoped 
> for.
> 
> What do you all think of the version number? Nashorn never had its own 
> separate version number, but I’m thinking we could start the standalone 
> version at 15. I don’t expect we’ll remain in lockstep with OpenJDK (so it’ll 
> remain at 15 significantly longer), but it might be a good strategy to at 
> least retroactively be able to talk about it without confusion, e.g. “Nashorn 
> 11” is Nashorn-as-in-Java-11 and “Nashorn 14” is Nashorn-as-in-Java-14. And 
> “Nashorn 15” is then quite naturally the first standalone version.
> 
> Attila.
> 
>> On 2020. Oct 19., at 17:16, Attila Szegedi  wrote:
>> 
>> Hi y’all,
>> 
>> a quick update with regard of what’s been happening since the last post.
>> 
>> * I’m talking with folks at Oracle about setting up the openjdk/nashorn 
>> repo. We’re hashing out what the initial content of the repo should be.
>> 
>> * The licensing for the standalone Nashorn is confirmed to be 
>> GPLv2+Classpath exception.
>> 
>> * In anticipation of getting a public repo, I’ve been not sitting idle, but 
>> rather I’m working in a private repo to get ahead with the necessary 
>> adaptations. I have a version now that passes the internal test suite (with 
>> an asterisk) and passes the whole test262[0] suite (no asterisk there, it 
>> all passes.)
>> 
>> * I still need to figure out the minimal descriptive pom.xml (dependencies 
>> etc., no build information) in order to be able to produce Maven artifacts. 
>> Right now, Nashorn’s build and test process is highly customized set of Ant 
>> build.xml files, so it can’t just be converted to “vanilla” Maven or Gradle. 
>> It’s a long term goal though (to switch it from our custom Ant build.xml to 
>> either one of these.) Initially, it might make sense to use Apache Ivy 
>> within our Ant build to handle both dependencies and publication.
>> 
>> As for test suite asterisks:
>> 
>> * For now, I moved all the jjs related tests into “currently failing” 
>> directory as I did not have time to figure out how to build jjs. We can sort 
>> out later if/when/how we want to resurrect jjs.
>> 
>> * sandbox/nashorninternals.js test is moved to “currently failing” too. I’m 
>> pretty sure that what it’s been testing is no longer relevant. Tests 
>> artificially are restricted from accessing internal Nashorn internal 
>> packages and this is validated. Unfortunately, keeping Nashorn internals in 
>> the list of access-checked packages causes lots of issues for Nashorn itself 
>> in the tests, so I removed internal packages from the access-check list. I 
>> separately kept a test package that’s used to assert scripts can’t access 
>> such packages, and it works fine.
>> 
>> * for now, I disabled anonymous code loading. It’s a funny one. Nashorn has 
>> a feature called “anonymous code loading” that it uses for somewhat 
>> lighter-weight loading of code as it compiles JavaScript functions 
>> one-by-one into bytecode classes. Unfortunately, it uses 
>> Unsafe.defineAnonymousClass for that, and outside of JDK it can’t access 
>> Unsafe. So I switched to a new API,  luckily available from Java 15, 
>> MethodHandles.Lookup.defineHiddenClass. It seems to work as it should, 
>> except with it, eval’d expressions no longer report “” as their script 
>> name and anonymous functions no longer report “” but rather their 
>> callers names, script names, and line numbers are 

Re: Standalone Nashorn is coming for Java 15+

[Tony Zakula]

+1

On Sun, Oct 25, 2020 at 5:18 PM Peter Ansell  wrote:

> Hi Atilla,
>
> Nashorn-15 seems intuitive to me.
>
> Thanks for the regular updates!
>
> Peter
>
> On Mon, 26 Oct 2020 at 04:08, Attila Szegedi  wrote:
> >
> > Hi y’all,
> >
> > trying to get into the habit of making these weekly updates until I have
> something else to show.
> >
> > * With Remi’s, Sundar’s and Mandy’s help I fixed anonymous code loading.
> We’ll be using the sun.misc.Unsafe for now, with hope to transition to
> Lookup.defineHiddenClass somewhere down the line.
> >
> > * I started using Ivy as the dependency manager in our build.xml, and
> right now I also have an Ant task that builds all the artifacts for Maven
> publication.
> >
> > The first version of Maven artifacts (jar, javadoc, sources, Maven pom
> file) is basically ready to go. All we’re waiting for is for Oracle to
> create the openjdk/nashorn repository and approve its initial contents. I
> started the relevant conversation about it 12 days ago… it is going slower
> than I hoped for.
> >
> > What do you all think of the version number? Nashorn never had its own
> separate version number, but I’m thinking we could start the standalone
> version at 15. I don’t expect we’ll remain in lockstep with OpenJDK (so
> it’ll remain at 15 significantly longer), but it might be a good strategy
> to at least retroactively be able to talk about it without confusion, e.g.
> “Nashorn 11” is Nashorn-as-in-Java-11 and “Nashorn 14” is
> Nashorn-as-in-Java-14. And “Nashorn 15” is then quite naturally the first
> standalone version.
> >
> > Attila.
> >
> > > On 2020. Oct 19., at 17:16, Attila Szegedi  wrote:
> > >
> > > Hi y’all,
> > >
> > > a quick update with regard of what’s been happening since the last
> post.
> > >
> > > * I’m talking with folks at Oracle about setting up the
> openjdk/nashorn repo. We’re hashing out what the initial content of the
> repo should be.
> > >
> > > * The licensing for the standalone Nashorn is confirmed to be
> GPLv2+Classpath exception.
> > >
> > > * In anticipation of getting a public repo, I’ve been not sitting
> idle, but rather I’m working in a private repo to get ahead with the
> necessary adaptations. I have a version now that passes the internal test
> suite (with an asterisk) and passes the whole test262[0] suite (no asterisk
> there, it all passes.)
> > >
> > > * I still need to figure out the minimal descriptive pom.xml
> (dependencies etc., no build information) in order to be able to produce
> Maven artifacts. Right now, Nashorn’s build and test process is highly
> customized set of Ant build.xml files, so it can’t just be converted to
> “vanilla” Maven or Gradle. It’s a long term goal though (to switch it from
> our custom Ant build.xml to either one of these.) Initially, it might make
> sense to use Apache Ivy within our Ant build to handle both dependencies
> and publication.
> > >
> > > As for test suite asterisks:
> > >
> > > * For now, I moved all the jjs related tests into “currently failing”
> directory as I did not have time to figure out how to build jjs. We can
> sort out later if/when/how we want to resurrect jjs.
> > >
> > > * sandbox/nashorninternals.js test is moved to “currently failing”
> too. I’m pretty sure that what it’s been testing is no longer relevant.
> Tests artificially are restricted from accessing internal Nashorn internal
> packages and this is validated. Unfortunately, keeping Nashorn internals in
> the list of access-checked packages causes lots of issues for Nashorn
> itself in the tests, so I removed internal packages from the access-check
> list. I separately kept a test package that’s used to assert scripts can’t
> access such packages, and it works fine.
> > >
> > > * for now, I disabled anonymous code loading. It’s a funny one.
> Nashorn has a feature called “anonymous code loading” that it uses for
> somewhat lighter-weight loading of code as it compiles JavaScript functions
> one-by-one into bytecode classes. Unfortunately, it uses
> Unsafe.defineAnonymousClass for that, and outside of JDK it can’t access
> Unsafe. So I switched to a new API,  luckily available from Java 15,
> MethodHandles.Lookup.defineHiddenClass. It seems to work as it should,
> except with it, eval’d expressions no longer report “” as their
> script name and anonymous functions no longer report “” but
> rather their callers names, script names, and line numbers are reported.
> It’s quite maddening, and if I can’t get to the bottom of it in reasonable
> amount of time, I’ll just keep anonymous code loading switched off for
> initial release. There’s not many drawbacks to it, maybe a bit higher
> memory utilization if you don’t use optimistic types. With optimistic
> types, it would preclude obsolete code versions from clearing up from
> memory when functions are repeatedly recompiled until the whole script gets
> unloaded.
> > >
> > > Attila.
> > >
> > > [0] https://github.com/tc39/test262/tree/es5-tests
> > >
> > >> On 2020. Oct 

Re: Standalone Nashorn is coming for Java 15+

[Peter Ansell]

Hi Atilla,

Nashorn-15 seems intuitive to me.

Thanks for the regular updates!

Peter

On Mon, 26 Oct 2020 at 04:08, Attila Szegedi  wrote:
>
> Hi y’all,
>
> trying to get into the habit of making these weekly updates until I have 
> something else to show.
>
> * With Remi’s, Sundar’s and Mandy’s help I fixed anonymous code loading. 
> We’ll be using the sun.misc.Unsafe for now, with hope to transition to 
> Lookup.defineHiddenClass somewhere down the line.
>
> * I started using Ivy as the dependency manager in our build.xml, and right 
> now I also have an Ant task that builds all the artifacts for Maven 
> publication.
>
> The first version of Maven artifacts (jar, javadoc, sources, Maven pom file) 
> is basically ready to go. All we’re waiting for is for Oracle to create the 
> openjdk/nashorn repository and approve its initial contents. I started the 
> relevant conversation about it 12 days ago… it is going slower than I hoped 
> for.
>
> What do you all think of the version number? Nashorn never had its own 
> separate version number, but I’m thinking we could start the standalone 
> version at 15. I don’t expect we’ll remain in lockstep with OpenJDK (so it’ll 
> remain at 15 significantly longer), but it might be a good strategy to at 
> least retroactively be able to talk about it without confusion, e.g. “Nashorn 
> 11” is Nashorn-as-in-Java-11 and “Nashorn 14” is Nashorn-as-in-Java-14. And 
> “Nashorn 15” is then quite naturally the first standalone version.
>
> Attila.
>
> > On 2020. Oct 19., at 17:16, Attila Szegedi  wrote:
> >
> > Hi y’all,
> >
> > a quick update with regard of what’s been happening since the last post.
> >
> > * I’m talking with folks at Oracle about setting up the openjdk/nashorn 
> > repo. We’re hashing out what the initial content of the repo should be.
> >
> > * The licensing for the standalone Nashorn is confirmed to be 
> > GPLv2+Classpath exception.
> >
> > * In anticipation of getting a public repo, I’ve been not sitting idle, but 
> > rather I’m working in a private repo to get ahead with the necessary 
> > adaptations. I have a version now that passes the internal test suite (with 
> > an asterisk) and passes the whole test262[0] suite (no asterisk there, it 
> > all passes.)
> >
> > * I still need to figure out the minimal descriptive pom.xml (dependencies 
> > etc., no build information) in order to be able to produce Maven artifacts. 
> > Right now, Nashorn’s build and test process is highly customized set of Ant 
> > build.xml files, so it can’t just be converted to “vanilla” Maven or 
> > Gradle. It’s a long term goal though (to switch it from our custom Ant 
> > build.xml to either one of these.) Initially, it might make sense to use 
> > Apache Ivy within our Ant build to handle both dependencies and publication.
> >
> > As for test suite asterisks:
> >
> > * For now, I moved all the jjs related tests into “currently failing” 
> > directory as I did not have time to figure out how to build jjs. We can 
> > sort out later if/when/how we want to resurrect jjs.
> >
> > * sandbox/nashorninternals.js test is moved to “currently failing” too. I’m 
> > pretty sure that what it’s been testing is no longer relevant. Tests 
> > artificially are restricted from accessing internal Nashorn internal 
> > packages and this is validated. Unfortunately, keeping Nashorn internals in 
> > the list of access-checked packages causes lots of issues for Nashorn 
> > itself in the tests, so I removed internal packages from the access-check 
> > list. I separately kept a test package that’s used to assert scripts can’t 
> > access such packages, and it works fine.
> >
> > * for now, I disabled anonymous code loading. It’s a funny one. Nashorn has 
> > a feature called “anonymous code loading” that it uses for somewhat 
> > lighter-weight loading of code as it compiles JavaScript functions 
> > one-by-one into bytecode classes. Unfortunately, it uses 
> > Unsafe.defineAnonymousClass for that, and outside of JDK it can’t access 
> > Unsafe. So I switched to a new API,  luckily available from Java 15, 
> > MethodHandles.Lookup.defineHiddenClass. It seems to work as it should, 
> > except with it, eval’d expressions no longer report “” as their 
> > script name and anonymous functions no longer report “” but 
> > rather their callers names, script names, and line numbers are reported. 
> > It’s quite maddening, and if I can’t get to the bottom of it in reasonable 
> > amount of time, I’ll just keep anonymous code loading switched off for 
> > initial release. There’s not many drawbacks to it, maybe a bit higher 
> > memory utilization if you don’t use optimistic types. With optimistic 
> > types, it would preclude obsolete code versions from clearing up from 
> > memory when functions are repeatedly recompiled until the whole script gets 
> > unloaded.
> >
> > Attila.
> >
> > [0] https://github.com/tc39/test262/tree/es5-tests
> >
> >> On 2020. Oct 11., at 9:28, Attila Szegedi  wrote:
> 

Re: Standalone Nashorn is coming for Java 15+

[Attila Szegedi]

Hi y’all,

trying to get into the habit of making these weekly updates until I have 
something else to show.

* With Remi’s, Sundar’s and Mandy’s help I fixed anonymous code loading. We’ll 
be using the sun.misc.Unsafe for now, with hope to transition to 
Lookup.defineHiddenClass somewhere down the line.

* I started using Ivy as the dependency manager in our build.xml, and right now 
I also have an Ant task that builds all the artifacts for Maven publication. 

The first version of Maven artifacts (jar, javadoc, sources, Maven pom file) is 
basically ready to go. All we’re waiting for is for Oracle to create the 
openjdk/nashorn repository and approve its initial contents. I started the 
relevant conversation about it 12 days ago… it is going slower than I hoped for.

What do you all think of the version number? Nashorn never had its own separate 
version number, but I’m thinking we could start the standalone version at 15. I 
don’t expect we’ll remain in lockstep with OpenJDK (so it’ll remain at 15 
significantly longer), but it might be a good strategy to at least 
retroactively be able to talk about it without confusion, e.g. “Nashorn 11” is 
Nashorn-as-in-Java-11 and “Nashorn 14” is Nashorn-as-in-Java-14. And “Nashorn 
15” is then quite naturally the first standalone version.

Attila.

> On 2020. Oct 19., at 17:16, Attila Szegedi  wrote:
> 
> Hi y’all,
> 
> a quick update with regard of what’s been happening since the last post.
> 
> * I’m talking with folks at Oracle about setting up the openjdk/nashorn repo. 
> We’re hashing out what the initial content of the repo should be.
> 
> * The licensing for the standalone Nashorn is confirmed to be GPLv2+Classpath 
> exception.
> 
> * In anticipation of getting a public repo, I’ve been not sitting idle, but 
> rather I’m working in a private repo to get ahead with the necessary 
> adaptations. I have a version now that passes the internal test suite (with 
> an asterisk) and passes the whole test262[0] suite (no asterisk there, it all 
> passes.)
> 
> * I still need to figure out the minimal descriptive pom.xml (dependencies 
> etc., no build information) in order to be able to produce Maven artifacts. 
> Right now, Nashorn’s build and test process is highly customized set of Ant 
> build.xml files, so it can’t just be converted to “vanilla” Maven or Gradle. 
> It’s a long term goal though (to switch it from our custom Ant build.xml to 
> either one of these.) Initially, it might make sense to use Apache Ivy within 
> our Ant build to handle both dependencies and publication.
> 
> As for test suite asterisks:
> 
> * For now, I moved all the jjs related tests into “currently failing” 
> directory as I did not have time to figure out how to build jjs. We can sort 
> out later if/when/how we want to resurrect jjs.
> 
> * sandbox/nashorninternals.js test is moved to “currently failing” too. I’m 
> pretty sure that what it’s been testing is no longer relevant. Tests 
> artificially are restricted from accessing internal Nashorn internal packages 
> and this is validated. Unfortunately, keeping Nashorn internals in the list 
> of access-checked packages causes lots of issues for Nashorn itself in the 
> tests, so I removed internal packages from the access-check list. I 
> separately kept a test package that’s used to assert scripts can’t access 
> such packages, and it works fine.
> 
> * for now, I disabled anonymous code loading. It’s a funny one. Nashorn has a 
> feature called “anonymous code loading” that it uses for somewhat 
> lighter-weight loading of code as it compiles JavaScript functions one-by-one 
> into bytecode classes. Unfortunately, it uses Unsafe.defineAnonymousClass for 
> that, and outside of JDK it can’t access Unsafe. So I switched to a new API,  
> luckily available from Java 15, MethodHandles.Lookup.defineHiddenClass. It 
> seems to work as it should, except with it, eval’d expressions no longer 
> report “” as their script name and anonymous functions no longer report 
> “” but rather their callers names, script names, and line numbers 
> are reported. It’s quite maddening, and if I can’t get to the bottom of it in 
> reasonable amount of time, I’ll just keep anonymous code loading switched off 
> for initial release. There’s not many drawbacks to it, maybe a bit higher 
> memory utilization if you don’t use optimistic types. With optimistic types, 
> it would preclude obsolete code versions from clearing up from memory when 
> functions are repeatedly recompiled until the whole script gets unloaded.
> 
> Attila.
> 
> [0] https://github.com/tc39/test262/tree/es5-tests
> 
>> On 2020. Oct 11., at 9:28, Attila Szegedi  wrote:
>> 
>> Folks,
>> 
>> some good news for y'all (presumably you're on this mailing list because you 
>> are interested in Nashorn.)
>> 
>> Since Nashorn's removal from JDK starting with Java 15, numerous people have 
>> realized that they, in fact, rely on it. To remedy the situation, Nashorn 
>> will continue as a 

Re: Standalone Nashorn is coming for Java 15+

[sundararajan . athijegannathan]

Given that we use "anonymous class" for JS "evals",  a level of 
indirection won't hurt here. i.e., a Eval class instance (with instance 
would report name like "" ) that uses "hidden class" Lookup may work.


-Sundar

On 19/10/20 9:41 pm, fo...@univ-mlv.fr wrote:

- Mail original -

De: "Attila Szegedi" 
À: "nashorn-dev" 
Envoyé: Lundi 19 Octobre 2020 17:16:55
Objet: Re: Standalone Nashorn is coming for Java 15+
Hi y’all,


Hi Attila,


a quick update with regard of what’s been happening since the last post.

* I’m talking with folks at Oracle about setting up the openjdk/nashorn repo.
We’re hashing out what the initial content of the repo should be.

* The licensing for the standalone Nashorn is confirmed to be GPLv2+Classpath
exception.

* In anticipation of getting a public repo, I’ve been not sitting idle, but
rather I’m working in a private repo to get ahead with the necessary
adaptations. I have a version now that passes the internal test suite (with an
asterisk) and passes the whole test262[0] suite (no asterisk there, it all
passes.)

* I still need to figure out the minimal descriptive pom.xml (dependencies etc.,
no build information) in order to be able to produce Maven artifacts. Right
now, Nashorn’s build and test process is highly customized set of Ant build.xml
files, so it can’t just be converted to “vanilla” Maven or Gradle. It’s a long
term goal though (to switch it from our custom Ant build.xml to either one of
these.) Initially, it might make sense to use Apache Ivy within our Ant build
to handle both dependencies and publication.

As for test suite asterisks:

* For now, I moved all the jjs related tests into “currently failing” directory
as I did not have time to figure out how to build jjs. We can sort out later
if/when/how we want to resurrect jjs.

* sandbox/nashorninternals.js test is moved to “currently failing” too. I’m
pretty sure that what it’s been testing is no longer relevant. Tests
artificially are restricted from accessing internal Nashorn internal packages
and this is validated. Unfortunately, keeping Nashorn internals in the list of
access-checked packages causes lots of issues for Nashorn itself in the tests,
so I removed internal packages from the access-check list. I separately kept a
test package that’s used to assert scripts can’t access such packages, and it
works fine.

* for now, I disabled anonymous code loading. It’s a funny one. Nashorn has a
feature called “anonymous code loading” that it uses for somewhat
lighter-weight loading of code as it compiles JavaScript functions one-by-one
into bytecode classes. Unfortunately, it uses Unsafe.defineAnonymousClass for
that, and outside of JDK it can’t access Unsafe. So I switched to a new API,
luckily available from Java 15, MethodHandles.Lookup.defineHiddenClass. It
seems to work as it should, except with it, eval’d expressions no longer report
“” as their script name and anonymous functions no longer report
“” but rather their callers names, script names, and line numbers
are reported. It’s quite maddening, and if I can’t get to the bottom of it in
reasonable amount of time.

A hidden class is well, hidden, so it doesn't appear by default in the stack 
trace (You have a special configuation of the StackWalker that shows the hidden 
classes).
With an anonymous class, you can use the annotation @Hidden or not but with a 
hidden class, you have no choice, a hidden class is always hidden.

Also, you can still use Unsafe.defineAnonymous class with Java 15, but using 
sun.misc.Unsafe and not jdk.internal.misc.Unsafe.
But it's a short term solution given that sun.misc.Unsafe.defineAnonymous is 
now deprecated.


I’ll just keep anonymous code loading switched off
for initial release. There’s not many drawbacks to it, maybe a bit higher
memory utilization if you don’t use optimistic types. With optimistic types, it
would preclude obsolete code versions from clearing up from memory when
functions are repeatedly recompiled until the whole script gets unloaded.

I've added Mandy in CC, given you are not the first one to ask for a "visible" 
hidden class, so maybe, the ClassOption could be extended to had a VISIBLE option ?


Attila.

regards,
Rémi


[0] https://github.com/tc39/test262/tree/es5-tests


On 2020. Oct 11., at 9:28, Attila Szegedi  wrote:

Folks,

some good news for y'all (presumably you're on this mailing list because you are
interested in Nashorn.)

Since Nashorn's removal from JDK starting with Java 15, numerous people have
realized that they, in fact, rely on it. To remedy the situation, Nashorn will
continue as a standalone project within the OpenJDK organization.

You might ask, "But isn't Nashorn officially dead?", to which the answer is: no,
it isn’t. The project’s product is merely no longer shipped as part of the JDK
project. The Nashorn project in OpenJDK organization is still live[1], along
with all of its resource

Re: Standalone Nashorn is coming for Java 15+

[Mandy Chung]

On 10/19/20 11:44 AM, Remi Forax wrote:






Hi Attila,


* for now, I disabled anonymous code loading. It’s a funny
one. Nashorn has a
feature called “anonymous code loading” that it uses for
somewhat
lighter-weight loading of code as it compiles JavaScript
functions one-by-one
into bytecode classes. Unfortunately, it uses
Unsafe.defineAnonymousClass for
that, and outside of JDK it can’t access Unsafe. So I
switched to a new API,
luckily available from Java 15,
MethodHandles.Lookup.defineHiddenClass. It
seems to work as it should, except with it, eval’d
expressions no longer report
“” as their script name and anonymous functions no
longer report
“” but rather their callers names, script
names, and line numbers
are reported. It’s quite maddening, and if I can’t get to
the bottom of it in
reasonable amount of time.



I also had converted to use `Lookup::defineHiddenClass` but I missed 
this stack trace issue.


http://hg.openjdk.java.net/valhalla/valhalla/file/fb5c34c883b5/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java#l321

How does the engine walk the stack frame and report "" as their 
script name and anonymous functions?  I wonder if StackWalker can help 
here (as Remi mentions).





A hidden class is well, hidden, so it doesn't appear by
default in the stack trace (You have a special configuation of
the StackWalker that shows the hidden classes).
With an anonymous class, you can use the annotation @Hidden or
not but with a hidden class, you have no choice, a hidden
class is always hidden.


Thanks for chiming in, Remi! I just came back from an evening
walk, and around halfway into it I actually had this lightbulb go
on thinking “y’know, this feels like the the stack frames are hidden…”

Also, you can still use Unsafe.defineAnonymous class with Java
15, but using sun.misc.Unsafe and not jdk.internal.misc.Unsafe.
But it's a short term solution given that
sun.misc.Unsafe.defineAnonymous is now deprecated.


I gave it a brief try, but the compiler complained that the
package sun.misc is not visible. And anyway I was hoping for using
a supported public API :-) I might give it _another_ try. I’m not
sure what else do I need to do, but I hope it can be done without
users needing to screw around with JVM flags such as --add-exports
etc.


you may not be able to access it directly, but you can still write
  Class unsafe = Class.forName("sun.misc.unsafe");



jdk.unsupported exports and opens `sun.misc` and so `sun.misc.Unsafe` 
should be accessible as in JDK 8.



also, if you are modular, you need to requires jdk.unsupported, 
sun.misc.Unsafe is not in java.base.





That might be the cause of the issue.





I’ll just keep anonymous code loading switched off
for initial release. There’s not many drawbacks to it,
maybe a bit higher
memory utilization if you don’t use optimistic types. With
optimistic types, it
would preclude obsolete code versions from clearing up
from memory when
functions are repeatedly recompiled until the whole script
gets unloaded.


I've added Mandy in CC, given you are not the first one to ask
for a "visible" hidden class, so maybe, the ClassOption could
be extended to had a VISIBLE option ?


That’d be awesome! By the way, Mandy, it is already awesome that
we have Lookup.defineHiddenClass !


yep, +1



Thank you.

My apology that I haven't had time to consider JDK-8212620 more.  I 
still think VISIBLE option is option while it is relevant to JDK-8212620 
as well.  It's better to consider them together.


As I ask above, would StackWalker with SHOW_HIDDEN_FRAMES option help to 
find the stack frame with hidden class?


Mandy

Re: Standalone Nashorn is coming for Java 15+

[Remi Forax]

> De: "Attila Szegedi" 
> À: "remi forax" 
> Cc: "nashorn-dev" , "mandy chung"
> 
> Envoyé: Lundi 19 Octobre 2020 20:28:53
> Objet: Re: Standalone Nashorn is coming for Java 15+

>> On 2020. Oct 19., at 18:06, Remi Forax < [ mailto:remi.fo...@univ-eiffel.fr |
>> remi.fo...@univ-eiffel.fr ] > wrote:

>> - Mail original -

>>> De: "Attila Szegedi" < [ mailto:szege...@gmail.com | szege...@gmail.com ] >
>>> À: "nashorn-dev" < [ mailto:nashorn-dev@openjdk.java.net |
>>> nashorn-dev@openjdk.java.net ] >
>>> Envoyé: Lundi 19 Octobre 2020 17:16:55
>>> Objet: Re: Standalone Nashorn is coming for Java 15+

>>> Hi y’all,

>> Hi Attila,

>>> * for now, I disabled anonymous code loading. It’s a funny one. Nashorn has 
>>> a
>>> feature called “anonymous code loading” that it uses for somewhat
>>> lighter-weight loading of code as it compiles JavaScript functions 
>>> one-by-one
>>> into bytecode classes. Unfortunately, it uses Unsafe.defineAnonymousClass 
>>> for
>>> that, and outside of JDK it can’t access Unsafe. So I switched to a new API,
>>> luckily available from Java 15, MethodHandles.Lookup.defineHiddenClass. It
>>> seems to work as it should, except with it, eval’d expressions no longer 
>>> report
>>> “” as their script name and anonymous functions no longer report
>>> “” but rather their callers names, script names, and line numbers
>>> are reported. It’s quite maddening, and if I can’t get to the bottom of it 
>>> in
>>> reasonable amount of time.

>> A hidden class is well, hidden, so it doesn't appear by default in the stack
>> trace (You have a special configuation of the StackWalker that shows the 
>> hidden
>> classes).
>> With an anonymous class, you can use the annotation @Hidden or not but with a
>> hidden class, you have no choice, a hidden class is always hidden.

> Thanks for chiming in, Remi! I just came back from an evening walk, and around
> halfway into it I actually had this lightbulb go on thinking “y’know, this
> feels like the the stack frames are hidden…”

>> Also, you can still use Unsafe.defineAnonymous class with Java 15, but using
>> sun.misc.Unsafe and not jdk.internal.misc.Unsafe.
>> But it's a short term solution given that sun.misc.Unsafe.defineAnonymous is 
>> now
>> deprecated.

> I gave it a brief try, but the compiler complained that the package sun.misc 
> is
> not visible. And anyway I was hoping for using a supported public API :-) I
> might give it _another_ try. I’m not sure what else do I need to do, but I 
> hope
> it can be done without users needing to screw around with JVM flags such as
> --add-exports etc.

you may not be able to access it directly, but you can still write 
Class unsafe = Class.forName("sun.misc.unsafe"); 

also, if you are modular, you need to requires jdk.unsupported, sun.misc.Unsafe 
is not in java.base. 

>>> I’ll just keep anonymous code loading switched off
>>> for initial release. There’s not many drawbacks to it, maybe a bit higher
>>> memory utilization if you don’t use optimistic types. With optimistic 
>>> types, it
>>> would preclude obsolete code versions from clearing up from memory when
>>> functions are repeatedly recompiled until the whole script gets unloaded.

>> I've added Mandy in CC, given you are not the first one to ask for a 
>> "visible"
>> hidden class, so maybe, the ClassOption could be extended to had a VISIBLE
>> option ?

> That’d be awesome! By the way, Mandy, it is already awesome that we have
> Lookup.defineHiddenClass !

yep, +1 

> Attila.

Rémi 

Re: Standalone Nashorn is coming for Java 15+

[Attila Szegedi]

> On 2020. Oct 19., at 18:06, Remi Forax  wrote:
> 
> - Mail original -
>> De: "Attila Szegedi" mailto:szege...@gmail.com>>
>> À: "nashorn-dev" > <mailto:nashorn-dev@openjdk.java.net>>
>> Envoyé: Lundi 19 Octobre 2020 17:16:55
>> Objet: Re: Standalone Nashorn is coming for Java 15+
> 
>> Hi y’all,
> 
> 
> Hi Attila,
> 
>> 
>> * for now, I disabled anonymous code loading. It’s a funny one. Nashorn has a
>> feature called “anonymous code loading” that it uses for somewhat
>> lighter-weight loading of code as it compiles JavaScript functions one-by-one
>> into bytecode classes. Unfortunately, it uses Unsafe.defineAnonymousClass for
>> that, and outside of JDK it can’t access Unsafe. So I switched to a new API,
>> luckily available from Java 15, MethodHandles.Lookup.defineHiddenClass. It
>> seems to work as it should, except with it, eval’d expressions no longer 
>> report
>> “” as their script name and anonymous functions no longer report
>> “” but rather their callers names, script names, and line numbers
>> are reported. It’s quite maddening, and if I can’t get to the bottom of it in
>> reasonable amount of time.
> 
> A hidden class is well, hidden, so it doesn't appear by default in the stack 
> trace (You have a special configuation of the StackWalker that shows the 
> hidden classes).
> With an anonymous class, you can use the annotation @Hidden or not but with a 
> hidden class, you have no choice, a hidden class is always hidden.

Thanks for chiming in, Remi! I just came back from an evening walk, and around 
halfway into it I actually had this lightbulb go on thinking “y’know, this 
feels like the the stack frames are hidden…”

> Also, you can still use Unsafe.defineAnonymous class with Java 15, but using 
> sun.misc.Unsafe and not jdk.internal.misc.Unsafe.
> But it's a short term solution given that sun.misc.Unsafe.defineAnonymous is 
> now deprecated.

I gave it a brief try, but the compiler complained that the package sun.misc is 
not visible. And anyway I was hoping for using a supported public API :-) I 
might give it _another_ try. I’m not sure what else do I need to do, but I hope 
it can be done without users needing to screw around with JVM flags such as 
--add-exports etc.

> 
>> I’ll just keep anonymous code loading switched off
>> for initial release. There’s not many drawbacks to it, maybe a bit higher
>> memory utilization if you don’t use optimistic types. With optimistic types, 
>> it
>> would preclude obsolete code versions from clearing up from memory when
>> functions are repeatedly recompiled until the whole script gets unloaded.
> 
> I've added Mandy in CC, given you are not the first one to ask for a 
> "visible" hidden class, so maybe, the ClassOption could be extended to had a 
> VISIBLE option ?

That’d be awesome! By the way, Mandy, it is already awesome that we have 
Lookup.defineHiddenClass!

Attila.

Re: Standalone Nashorn is coming for Java 15+

[forax]

- Mail original -
> De: "Attila Szegedi" 
> À: "nashorn-dev" 
> Envoyé: Lundi 19 Octobre 2020 17:16:55
> Objet: Re: Standalone Nashorn is coming for Java 15+

> Hi y’all,


Hi Attila,

>
> a quick update with regard of what’s been happening since the last post.
>
> * I’m talking with folks at Oracle about setting up the openjdk/nashorn repo.
> We’re hashing out what the initial content of the repo should be.
>
> * The licensing for the standalone Nashorn is confirmed to be GPLv2+Classpath
> exception.
>
> * In anticipation of getting a public repo, I’ve been not sitting idle, but
> rather I’m working in a private repo to get ahead with the necessary
> adaptations. I have a version now that passes the internal test suite (with an
> asterisk) and passes the whole test262[0] suite (no asterisk there, it all
> passes.)
>
> * I still need to figure out the minimal descriptive pom.xml (dependencies 
> etc.,
> no build information) in order to be able to produce Maven artifacts. Right
> now, Nashorn’s build and test process is highly customized set of Ant 
> build.xml
> files, so it can’t just be converted to “vanilla” Maven or Gradle. It’s a long
> term goal though (to switch it from our custom Ant build.xml to either one of
> these.) Initially, it might make sense to use Apache Ivy within our Ant build
> to handle both dependencies and publication.
>
> As for test suite asterisks:
>
> * For now, I moved all the jjs related tests into “currently failing” 
> directory
> as I did not have time to figure out how to build jjs. We can sort out later
> if/when/how we want to resurrect jjs.
>
> * sandbox/nashorninternals.js test is moved to “currently failing” too. I’m
> pretty sure that what it’s been testing is no longer relevant. Tests
> artificially are restricted from accessing internal Nashorn internal packages
> and this is validated. Unfortunately, keeping Nashorn internals in the list of
> access-checked packages causes lots of issues for Nashorn itself in the tests,
> so I removed internal packages from the access-check list. I separately kept a
> test package that’s used to assert scripts can’t access such packages, and it
> works fine.
>
> * for now, I disabled anonymous code loading. It’s a funny one. Nashorn has a
> feature called “anonymous code loading” that it uses for somewhat
> lighter-weight loading of code as it compiles JavaScript functions one-by-one
> into bytecode classes. Unfortunately, it uses Unsafe.defineAnonymousClass for
> that, and outside of JDK it can’t access Unsafe. So I switched to a new API,
> luckily available from Java 15, MethodHandles.Lookup.defineHiddenClass. It
> seems to work as it should, except with it, eval’d expressions no longer 
> report
> “” as their script name and anonymous functions no longer report
> “” but rather their callers names, script names, and line numbers
> are reported. It’s quite maddening, and if I can’t get to the bottom of it in
> reasonable amount of time.

A hidden class is well, hidden, so it doesn't appear by default in the stack 
trace (You have a special configuation of the StackWalker that shows the hidden 
classes).
With an anonymous class, you can use the annotation @Hidden or not but with a 
hidden class, you have no choice, a hidden class is always hidden.

Also, you can still use Unsafe.defineAnonymous class with Java 15, but using 
sun.misc.Unsafe and not jdk.internal.misc.Unsafe.
But it's a short term solution given that sun.misc.Unsafe.defineAnonymous is 
now deprecated.

> I’ll just keep anonymous code loading switched off
> for initial release. There’s not many drawbacks to it, maybe a bit higher
> memory utilization if you don’t use optimistic types. With optimistic types, 
> it
> would preclude obsolete code versions from clearing up from memory when
> functions are repeatedly recompiled until the whole script gets unloaded.

I've added Mandy in CC, given you are not the first one to ask for a "visible" 
hidden class, so maybe, the ClassOption could be extended to had a VISIBLE 
option ?

>
> Attila.

regards,
Rémi

>
> [0] https://github.com/tc39/test262/tree/es5-tests
>
>> On 2020. Oct 11., at 9:28, Attila Szegedi  wrote:
>>
>> Folks,
>>
>> some good news for y'all (presumably you're on this mailing list because you 
>> are
>> interested in Nashorn.)
>>
>> Since Nashorn's removal from JDK starting with Java 15, numerous people have
>> realized that they, in fact, rely on it. To remedy the situation, Nashorn 
>> will
>> continue as a standalone project within the OpenJDK organization.
>>
>> You might ask, "But isn't Nashorn officially dead?", to which the answer is: 
>> no,
>> it 

Re: Standalone Nashorn is coming for Java 15+

[Attila Szegedi]

Hi y’all,

a quick update with regard of what’s been happening since the last post.

* I’m talking with folks at Oracle about setting up the openjdk/nashorn repo. 
We’re hashing out what the initial content of the repo should be.

* The licensing for the standalone Nashorn is confirmed to be GPLv2+Classpath 
exception.

* In anticipation of getting a public repo, I’ve been not sitting idle, but 
rather I’m working in a private repo to get ahead with the necessary 
adaptations. I have a version now that passes the internal test suite (with an 
asterisk) and passes the whole test262[0] suite (no asterisk there, it all 
passes.)

* I still need to figure out the minimal descriptive pom.xml (dependencies 
etc., no build information) in order to be able to produce Maven artifacts. 
Right now, Nashorn’s build and test process is highly customized set of Ant 
build.xml files, so it can’t just be converted to “vanilla” Maven or Gradle. 
It’s a long term goal though (to switch it from our custom Ant build.xml to 
either one of these.) Initially, it might make sense to use Apache Ivy within 
our Ant build to handle both dependencies and publication.

As for test suite asterisks:

* For now, I moved all the jjs related tests into “currently failing” directory 
as I did not have time to figure out how to build jjs. We can sort out later 
if/when/how we want to resurrect jjs.

* sandbox/nashorninternals.js test is moved to “currently failing” too. I’m 
pretty sure that what it’s been testing is no longer relevant. Tests 
artificially are restricted from accessing internal Nashorn internal packages 
and this is validated. Unfortunately, keeping Nashorn internals in the list of 
access-checked packages causes lots of issues for Nashorn itself in the tests, 
so I removed internal packages from the access-check list. I separately kept a 
test package that’s used to assert scripts can’t access such packages, and it 
works fine.

* for now, I disabled anonymous code loading. It’s a funny one. Nashorn has a 
feature called “anonymous code loading” that it uses for somewhat 
lighter-weight loading of code as it compiles JavaScript functions one-by-one 
into bytecode classes. Unfortunately, it uses Unsafe.defineAnonymousClass for 
that, and outside of JDK it can’t access Unsafe. So I switched to a new API,  
luckily available from Java 15, MethodHandles.Lookup.defineHiddenClass. It 
seems to work as it should, except with it, eval’d expressions no longer report 
“” as their script name and anonymous functions no longer report 
“” but rather their callers names, script names, and line numbers 
are reported. It’s quite maddening, and if I can’t get to the bottom of it in 
reasonable amount of time, I’ll just keep anonymous code loading switched off 
for initial release. There’s not many drawbacks to it, maybe a bit higher 
memory utilization if you don’t use optimistic types. With optimistic types, it 
would preclude obsolete code versions from clearing up from memory when 
functions are repeatedly recompiled until the whole script gets unloaded.

Attila.

[0] https://github.com/tc39/test262/tree/es5-tests

> On 2020. Oct 11., at 9:28, Attila Szegedi  wrote:
> 
> Folks,
> 
> some good news for y'all (presumably you're on this mailing list because you 
> are interested in Nashorn.)
> 
> Since Nashorn's removal from JDK starting with Java 15, numerous people have 
> realized that they, in fact, rely on it. To remedy the situation, Nashorn 
> will continue as a standalone project within the OpenJDK organization.
> 
> You might ask, "But isn't Nashorn officially dead?", to which the answer is: 
> no, it isn’t. The project’s product is merely no longer shipped as part of 
> the JDK project. The Nashorn project in OpenJDK organization is still 
> live[1], along with all of its resources including the mailing list this 
> message is posted on. It was merely not active for a while, until now.
> 
> What does this mean in practical terms? The following will happen or are 
> happening:
> 
> * Project communication will continue on this mailing list 
> ().
> 
> * A GitHub project openjdk/nashorn will be set up. It will be populated by a 
> clone of the openjdk/jdk14u repo that has been filtered for  Nashorn-only 
> commits. (Thanks, git-filter-repo[2], you are awesome!) There will be no 
> synchronization back to jdk14u afterwards, it won't act as an upstream. 
> openjdk/nashorn proceeds independently from that point on.
> 
> * The project will change the module and package names as it can't keep 
> living within the top-level "jdk." package. In accordance with other 
> independently-developed OpenJDK projects, it will transition to module and 
> package names within the "org.openjdk." package. Fortunately for Nashorn, it 
> is mostly used through the "javax.script.*" APIs so people that use it 
> through those APIs won't have to adapt their code. Creating the engine by 
> name as described in Nashorn’s last (JDK 14) API docs[3] will 

Re: Stand-alone Nashorn licensing

[Attila Szegedi]

I am not considering moving Nashorn to Apache.

As to the why: I believe OpenJDK is a very robust open source organization with 
a good governance model. Nashorn already exists as a project in OpenJDK, and it 
was a natural choice to continue its development within its existing 
organization. Setting it up within ASF, or Eclipse, or some other software 
organization would’ve incurred significantly more work (and by implication 
time.)

I don’t see any clear benefits from transferring the project to a different 
org. If the OpenJDK organization would not have been open to continuing hosting 
Nashorn, it would’ve made sense to try to find a different host organization. 

Attila.

> On 2020. Oct 14., at 15:49, Colby Russell  
> wrote:
> 
> My last probe about moving to Apache got derailed.  Is that going to be given 
> any serious consideration, and if not, why?
> 
> -- 
> Colby Russell
> 
> On 10/14/20 7:27 AM, Attila Szegedi wrote:
>> I’m talking with folks within Oracle about this topic. My assumption is that 
>> the code being lifted out of the jdk project doesn’t change its licensing, 
>> so it should continue to be GPL Version 2 with Classpath exception. A past 
>> example of a project similarly spun off from jdk was JavaFX and that appears 
>> to also be under GPLv2 + Classpath.
>> 
>> As soon as I have a definitive word from Oracle, I’ll let the mailing list 
>> know.
>> 
>> Attila.
>> 
>>> On 2020. Oct 13., at 14:43, BURRIS Thomas  wrote:
>>> 
>>> Hi Attila (et. al.) - This is, indeed, good news. What specific license do 
>>> you intend to release the stand-alone Nashorn under?
>>> 
>>> After having been burnt by Oracle with the removal, it'd be very useful to 
>>> know the targeted license.
>>> 
>>> Best Regards,
>>> 
>>> Thomas BURRIS
>>> 
>>> RDF Modeling R Software Architecture Director
>>> 
>>> 
>>> 
>>> 
>>> This email and any attachments are intended solely for the use of the 
>>> individual or entity to whom it is addressed and may be confidential and/or 
>>> privileged.
>>> 
>>> If you are not one of the named recipients or have received this email in 
>>> error,
>>> 
>>> (i) you should not read, disclose, or copy it,
>>> 
>>> (ii) please notify sender of your receipt by reply email and delete this 
>>> email and all attachments,
>>> 
>>> (iii) Dassault Syst?mes does not accept or assume any liability or 
>>> responsibility for any use of or reliance on this email.
>>> 
>>> 
>>> Please be informed that your personal data are processed according to our 
>>> data privacy policy as described on our website. Should you have any 
>>> questions related to personal data protection, please contact 3DS Data 
>>> Protection Officer at 
>>> 3ds.compliance-priv...@3ds.com
>>> 
>>> 
>>> For other languages, go to https://www.3ds.com/terms/email-disclaimer
> 
> 

Re: Stand-alone Nashorn licensing

[Attila Szegedi]

Not sure what you mean by “derailed probe.” Are you saying in the past you 
tried to move Nashorn to the Apache Software Foundation? Or you tried to get 
Nashorn to be licensed under the Apache license? In any case, I’m not aware of 
any such past efforts.

Attila.

> On 2020. Oct 14., at 15:49, Colby Russell  
> wrote:
> 
> My last probe about moving to Apache got derailed.  Is that going to be given 
> any serious consideration, and if not, why?
> 
> -- 
> Colby Russell
> 
> On 10/14/20 7:27 AM, Attila Szegedi wrote:
>> I’m talking with folks within Oracle about this topic. My assumption is that 
>> the code being lifted out of the jdk project doesn’t change its licensing, 
>> so it should continue to be GPL Version 2 with Classpath exception. A past 
>> example of a project similarly spun off from jdk was JavaFX and that appears 
>> to also be under GPLv2 + Classpath.
>> 
>> As soon as I have a definitive word from Oracle, I’ll let the mailing list 
>> know.
>> 
>> Attila.
>> 
>>> On 2020. Oct 13., at 14:43, BURRIS Thomas  wrote:
>>> 
>>> Hi Attila (et. al.) - This is, indeed, good news. What specific license do 
>>> you intend to release the stand-alone Nashorn under?
>>> 
>>> After having been burnt by Oracle with the removal, it'd be very useful to 
>>> know the targeted license.
>>> 
>>> Best Regards,
>>> 
>>> Thomas BURRIS
>>> 
>>> RDF Modeling R Software Architecture Director
>>> 
>>> 
>>> 
>>> 
>>> This email and any attachments are intended solely for the use of the 
>>> individual or entity to whom it is addressed and may be confidential and/or 
>>> privileged.
>>> 
>>> If you are not one of the named recipients or have received this email in 
>>> error,
>>> 
>>> (i) you should not read, disclose, or copy it,
>>> 
>>> (ii) please notify sender of your receipt by reply email and delete this 
>>> email and all attachments,
>>> 
>>> (iii) Dassault Syst?mes does not accept or assume any liability or 
>>> responsibility for any use of or reliance on this email.
>>> 
>>> 
>>> Please be informed that your personal data are processed according to our 
>>> data privacy policy as described on our website. Should you have any 
>>> questions related to personal data protection, please contact 3DS Data 
>>> Protection Officer at 
>>> 3ds.compliance-priv...@3ds.com
>>> 
>>> 
>>> For other languages, go to https://www.3ds.com/terms/email-disclaimer
> 
> 

Re: Stand-alone Nashorn licensing

[Attila Szegedi]

I’m talking with folks within Oracle about this topic. My assumption is that 
the code being lifted out of the jdk project doesn’t change its licensing, so 
it should continue to be GPL Version 2 with Classpath exception. A past example 
of a project similarly spun off from jdk was JavaFX and that appears to also be 
under GPLv2 + Classpath.

As soon as I have a definitive word from Oracle, I’ll let the mailing list know.

Attila.

> On 2020. Oct 13., at 14:43, BURRIS Thomas  wrote:
> 
> Hi Attila (et. al.) - This is, indeed, good news. What specific license do 
> you intend to release the stand-alone Nashorn under?
> 
> After having been burnt by Oracle with the removal, it'd be very useful to 
> know the targeted license.
> 
> Best Regards,
> 
> Thomas BURRIS
> 
> RDF Modeling R Software Architecture Director
> 
> 
> 
> 
> This email and any attachments are intended solely for the use of the 
> individual or entity to whom it is addressed and may be confidential and/or 
> privileged.
> 
> If you are not one of the named recipients or have received this email in 
> error,
> 
> (i) you should not read, disclose, or copy it,
> 
> (ii) please notify sender of your receipt by reply email and delete this 
> email and all attachments,
> 
> (iii) Dassault Syst?mes does not accept or assume any liability or 
> responsibility for any use of or reliance on this email.
> 
> 
> Please be informed that your personal data are processed according to our 
> data privacy policy as described on our website. Should you have any 
> questions related to personal data protection, please contact 3DS Data 
> Protection Officer at 
> 3ds.compliance-priv...@3ds.com
> 
> 
> For other languages, go to https://www.3ds.com/terms/email-disclaimer

Re: Standalone Nashorn is coming for Java 15+

[Tony Zakula]

Thank you for working on Nashorn Attila.  We use it extensively.  Not sure
what exactly we can contribute, but willing to help if we can.

Thanks,

Tony


On Mon, Oct 12, 2020 at 9:05 AM Attila Szegedi  wrote:

> Hi Anamitra,
>
> yes, that is the exact intent of this initial standalone Nashorn release
> work.
>
> A minor point though where you mention “java application path": Nashorn
> used to be a JDK module, and it only works properly when put on the module
> path. But as long as you put it in the --module-path, it should Just Work
> as it did before.
>
> Attila.
>
> > On 2020. Oct 12., at 2:53, Anamitra Bhattacharyya <
> abhattachar...@us.ibm.com> wrote:
> >
> > Hi Attila
> > We use Nashorn as a JSR 223 language and do not use any internal Nashorn
> api - just the standard exposed using the JSR 223 interfaces. Are you
> saying that Nashorn would be available as a separately downloadable jar
> that we can put in our java application path and it will show up as a
> jsr223 language? That would be extremely helpful for all our customers who
> have developed thousands of JVM bases Nashorn scripts.
> > thanks
> > Anamitra Bhattacharyya
> > STSM, Maximo, IoT
> > IBM Master Inventor
> >
> >
> >
> > - Original message -
> > From: Attila Szegedi 
> > Sent by: "nashorn-dev" 
> > To: Nashorn-Dev 
> > Cc:
> > Subject: [EXTERNAL] Standalone Nashorn is coming for Java 15+
> > Date: Sun, Oct 11, 2020 3:29 AM
> >
> > Folks,
> >
> > some good news for y'all (presumably you're on this mailing list because
> you are interested in Nashorn.)
> >
> > Since Nashorn's removal from JDK starting with Java 15, numerous people
> have realized that they, in fact, rely on it. To remedy the situation,
> Nashorn will continue as a standalone project within the OpenJDK
> organization.
> >
> > You might ask, "But isn't Nashorn officially dead?", to which the answer
> is: no, it isn’t. The project’s product is merely no longer shipped as part
> of the JDK project. The Nashorn project in OpenJDK organization is still
> live[1], along with all of its resources including the mailing list this
> message is posted on. It was merely not active for a while, until now.
> >
> > What does this mean in practical terms? The following will happen or are
> happening:
> >
> > * Project communication will continue on this mailing list (<
> nashorn-dev@openjdk.java.net>).
> >
> > * A GitHub project openjdk/nashorn will be set up. It will be populated
> by a clone of the openjdk/jdk14u repo that has been filtered for
> Nashorn-only commits. (Thanks, git-filter-repo[2], you are awesome!) There
> will be no synchronization back to jdk14u afterwards, it won't act as an
> upstream. openjdk/nashorn proceeds independently from that point on.
> >
> > * The project will change the module and package names as it can't keep
> living within the top-level "jdk." package. In accordance with other
> independently-developed OpenJDK projects, it will transition to module and
> package names within the "org.openjdk." package. Fortunately for Nashorn,
> it is mostly used through the "javax.script.*" APIs so people that use it
> through those APIs won't have to adapt their code. Creating the engine by
> name as described in Nashorn’s last (JDK 14) API docs[3] will continue to
> work. People that used to use the Nashorn-specific API (typically,
> AbstractJSObject and ScriptObjectMirror) will need to adapt their code for
> new package names, though.
> >
> > * Project artifacts (in plain English: JAR file to be used with Maven
> etc.) will be published on SonaType under the "org.openjdk" organization,
> again similar to other independently-developed OpenJDK projects.
> >
> > The goal for the initial release is to ship a standalone Nashorn with
> identical functionality to that in JDK 14, with the only changes being:
> >
> > * reversing of deprecation and “scheduled for removal” notices,
> > * enacting the package and module name changes,
> > * replacing or removing dependencies on various jdk.internal.* packages
> since those are no longer exported from JDK modules to the Nashorn module.
> >
> > It is possible for expediency that we will decide to ship Nashorn as a
> library first, and separately ship the initial version of the jjs shell
> sometime later.
> >
> > I’m personally undertaking these initial tasks. I will let you know here
> on the list about the progress, and once the repo is set up the work will
> also start appearing on a branch.
> >
> > There are some other aspects of the project that need to be worked out:
> contribution and review guidelines, publication location of the
> accompanying documentation (that will no longer be part of the JDK
> documentation) and so on. I will post discussion-initiating e-mails for
> these as well as time comes and will absolutely welcome feedback on them,
> just as I welcome feedback on this plan too.
> >
> > Attila.
> >
> > --
> > [1] https://openjdk.java.net/projects/nashorn/ <
> 

Re: Standalone Nashorn is coming for Java 15+

[Attila Szegedi]

> On 2020. Oct 12., at 19:19, Gustavo Lopes  wrote:
> 
> On Mon, Oct 12, 2020 at 5:54 PM Attila Szegedi  wrote:
>> 
>> On 2020. Oct 12., at 18:41, Gustavo Lopes  wrote:
>>> 
>>> * Half a dozen sandboxing tests don't pass because they require that 
>>> nashorn be loaded on the platform classloader. More precisly, when running 
>>> with a security manager and with -Djava.security.properties= pointing to a 
>>> file restricting class loading with package.access, it seems to rely on the 
>>> fact that the platform classloader doesn't have the call to 
>>> SecurityManager::checkPackageAccess that the app classloader has
>> 
>> I have maybe 9 test failures in my current working copy, but yeah, the 
>> checkPackageAccess issue exists. It also can just be a red herring of there 
>> being an explicit addition of Nashorn internal packages to access-checked 
>> list. I’ve been trying to figure out what to do about that.
> 
> To be clear, the failing tests are just these four:
> 
> https://github.com/sqreen/nashorn/tree/master/test/nashorn/script/failing-sandboxing

That’s funny, I re-checked and I also only have exactly those same 4 :-) 9 was 
probably an older number from early this weekend.

> I'm not sure what to do with these. I think what's going on that when
> Nashorn classes attempt to load classes from the internal package
> (after limiting access in the internal package via package.access=),
> they are not blocked because nashorn is loaded on the platform
> classloader (but when a script attempts to explicitly load internal
> classes it is blocked, because the scripts use a different
> classloader). Check the definitions of the Platform and App
> classloaders in Classloaders.java — only the AppClassloader calls
> SecurityManager::checkPackageAccess. But Java only loads on the
> platform classloader a hardcoded list of modules, so we go to the app
> classloader now. Maybe this can be worked around by tuning the policy
> file with extra accessClassInPackage permissions but I didn't manage
> to get it working in the alloted time.

Yeah, I’ve been wondering if we need that “package.access=“ It used to be there 
to ensure in code that client code can’t access Nashorn internals. Now that 
Nashorn is no longer running as privileged JDK code, this might not even be 
needed. I actually asked Sundar earlier today about this, we’ll keep thinking 
about what would be the valid way forward.

It’s great that you’ve gotten to this point too!

Attila.

Re: Standalone Nashorn is coming for Java 15+

[Gustavo Lopes]

On Mon, Oct 12, 2020 at 5:54 PM Attila Szegedi  wrote:
>
> On 2020. Oct 12., at 18:41, Gustavo Lopes  wrote:
> >
> > * Half a dozen sandboxing tests don't pass because they require that 
> > nashorn be loaded on the platform classloader. More precisly, when running 
> > with a security manager and with -Djava.security.properties= pointing to a 
> > file restricting class loading with package.access, it seems to rely on the 
> > fact that the platform classloader doesn't have the call to 
> > SecurityManager::checkPackageAccess that the app classloader has
>
> I have maybe 9 test failures in my current working copy, but yeah, the 
> checkPackageAccess issue exists. It also can just be a red herring of there 
> being an explicit addition of Nashorn internal packages to access-checked 
> list. I’ve been trying to figure out what to do about that.

To be clear, the failing tests are just these four:

https://github.com/sqreen/nashorn/tree/master/test/nashorn/script/failing-sandboxing

I'm not sure what to do with these. I think what's going on that when
Nashorn classes attempt to load classes from the internal package
(after limiting access in the internal package via package.access=),
they are not blocked because nashorn is loaded on the platform
classloader (but when a script attempts to explicitly load internal
classes it is blocked, because the scripts use a different
classloader). Check the definitions of the Platform and App
classloaders in Classloaders.java — only the AppClassloader calls
SecurityManager::checkPackageAccess. But Java only loads on the
platform classloader a hardcoded list of modules, so we go to the app
classloader now. Maybe this can be worked around by tuning the policy
file with extra accessClassInPackage permissions but I didn't manage
to get it working in the alloted time.

> > Most of the work was moving to gradle. I didn't have to make a lot of 
> > changes to the codebase. I had to change to the Unsafe in sun.misc rather 
> > than the internal one, to change the parent module layer for the scripting 
> > JPMS module created at runtime for when nashorn isn't loaded on the boot 
> > layer, then some tests required small tweaks but I don't remember much else.
>
> Hm. It seems to be working fine for me when I put it on --module-path without 
> modifications but I’d be curious as to what are your changes.

Yes, it works fine then. It doesn't if you load it on a different
module layer (i.e, not on the boot layer). The change is very simple,
though: 
https://github.com/sqreen/nashorn/commit/2ae4d7f1f352146e5eae5e00e9947791906841c8#diff-842711a2a0d4c5b3748032280ea00b2eL70

> > As to the jjs executable, that was not a problem, and some tests require it 
> > anyway, which is why I worked on it. The only difficult was that when built 
> > separately from openjdk, the -J-XXX option is not available, but this can 
> > be worked around with the JDK_JAVA_OPTIONS environment variable.
>
> I’ll be curious about that, as I for now haven’t really devoted time to jjs 
> and in fact planned to initially ship the nashorn library without paying much 
> attention to jjs.

I separated jjs in this subproject:
https://github.com/sqreen/nashorn/tree/master/jjs

It's a straightforward jlink task, the only difficulty being the
launcher having to open up some internals classes in the JDK. See
here:
https://github.com/sqreen/nashorn/blob/master/jjs/build.gradle#L21 .
Again, maybe this can be changed to non-jdk implementations of these
libraries.

The nashorn module also needs to export some internal classes to jjs,
but this was already the case before. Exporting those packages
unconditionally is undesirable, if for no other reason  that they
aren't subject to the classpath exception to the GPL.

> Do you already have, or can you maybe sign an Oracle Contributor 
> Agreement[1]? That would allow me (and all other OpenJDK projects) to accept 
> contributions from you.
>

Not yet, but I'll sort that out with Sqreen's management.

-- 
Gustavo Lopes

Re: Standalone Nashorn is coming for Java 15+

[Attila Szegedi]

> On 2020. Oct 12., at 18:41, Gustavo Lopes  wrote:
> 
> I had to change to the Unsafe in sun.misc rather than the internal one

Yeah, forgot to address this one… So that is used for “anonymous code loading” 
which is an optional feature and I think for the first cut, I might just 
disable it. It is somewhat (not much) faster as I believe those classes bypass 
the verifier and the class might probably use marginally less memory. I’m 
thinking of replacing it with MethodHandles.Lookup.defineHiddenClass[1] and 
thus completely avoid reliance on any internal APIs. I’m sure this public API 
doesn’t bypass the verifier, but is otherwise a fine choice as it also allows 
granular unloading of no longer used code and is in general lighter than 
ordinary class definition. 

Of course, it’ll make this Nashorn usable on Java15+ only as 
Lookup.defineHiddenClass debuts in Java 15, but I reckon that’s probably fine 
(we can discuss this issue separately.)

Attila.

[1] 
https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte%5B%5D,boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)

Re: Standalone Nashorn is coming for Java 15+

[Attila Szegedi]

Hi Gustavo!

On 2020. Oct 12., at 18:41, Gustavo Lopes  wrote:
> 
> I've incidentally been working on this lately.
> 
> The results of my efforts are here: https://github.com/sqreen/nashorn

Yeah, Sqreen was one of the businesses that indicated they’d need this.


> The tests that don't require external js libraries all pass, with some 
> exceptions:
> 
> * I couldn't get the tests requiring jemmy to pass. IIRC, the original ant 
> files pointed to some urls of jars that don't exist anymore and I couldn't 
> find the exact jemmy and jemmyjfx versions expected.

Maybe that’s gone for good…
> 
> * Half a dozen sandboxing tests don't pass because they require that nashorn 
> be loaded on the platform classloader. More precisly, when running with a 
> security manager and with -Djava.security.properties= pointing to a file 
> restricting class loading with package.access, it seems to rely on the fact 
> that the platform classloader doesn't have the call to 
> SecurityManager::checkPackageAccess that the app classloader has

I have maybe 9 test failures in my current working copy, but yeah, the 
checkPackageAccess issue exists. It also can just be a red herring of there 
being an explicit addition of Nashorn internal packages to access-checked list. 
I’ve been trying to figure out what to do about that.

> 
> I haven't worked on the benchmarks.
> 
> Most of the work was moving to gradle. I didn't have to make a lot of changes 
> to the codebase. I had to change to the Unsafe in sun.misc rather than the 
> internal one, to change the parent module layer for the scripting JPMS module 
> created at runtime for when nashorn isn't loaded on the boot layer, then some 
> tests required small tweaks but I don't remember much else.

Hm. It seems to be working fine for me when I put it on --module-path without 
modifications but I’d be curious as to what are your changes.

> I also copied the asm library to avoid having to --add-exports the internal 
> one, but maybe this can be changed to the mainline asm library.

I changed it to mainline ASM, it’ll just declare it as a dependency.

> As to the jjs executable, that was not a problem, and some tests require it 
> anyway, which is why I worked on it. The only difficult was that when built 
> separately from openjdk, the -J-XXX option is not available, but this can be 
> worked around with the JDK_JAVA_OPTIONS environment variable.

I’ll be curious about that, as I for now haven’t really devoted time to jjs and 
in fact planned to initially ship the nashorn library without paying much 
attention to jjs. 

Do you already have, or can you maybe sign an Oracle Contributor Agreement[1]? 
That would allow me (and all other OpenJDK projects) to accept contributions 
from you. 

Attila.

[1] https://www.oracle.com/technical-resources/oracle-contributor-agreement.html

Re: Standalone Nashorn is coming for Java 15+

[Gustavo Lopes]

I've incidentally been working on this lately.

The results of my efforts are here: https://github.com/sqreen/nashorn

The tests that don't require external js libraries all pass, with some 
exceptions:


* I couldn't get the tests requiring jemmy to pass. IIRC, the original 
ant files pointed to some urls of jars that don't exist anymore and I 
couldn't find the exact jemmy and jemmyjfx versions expected.


* Half a dozen sandboxing tests don't pass because they require that 
nashorn be loaded on the platform classloader. More precisly, when 
running with a security manager and 
with -Djava.security.properties= pointing to a file restricting class 
loading with package.access, it seems to rely on the fact that the 
platform classloader doesn't have the call 
to SecurityManager::checkPackageAccess that the app classloader has


I haven't worked on the benchmarks.

Most of the work was moving to gradle. I didn't have to make a lot of 
changes to the codebase. I had to change to the Unsafe in sun.misc 
rather than the internal one, to change the parent module layer for the 
scripting JPMS module created at runtime for when nashorn isn't loaded 
on the boot layer, then some tests required small tweaks but I don't 
remember much else.


I also copied the asm library to avoid having to --add-exports the 
internal one, but maybe this can be changed to the mainline asm library.


As to the jjs executable, that was not a problem, and some tests require 
it anyway, which is why I worked on it. The only difficult was that when 
built separately from openjdk, the -J-XXX option is not available, but 
this can be worked around with the JDK_JAVA_OPTIONS environment variable.

Re: Standalone Nashorn is coming for Java 15+

[Attila Szegedi]

Hi Anamitra,

yes, that is the exact intent of this initial standalone Nashorn release work. 

A minor point though where you mention “java application path": Nashorn used to 
be a JDK module, and it only works properly when put on the module path. But as 
long as you put it in the --module-path, it should Just Work as it did before.

Attila.

> On 2020. Oct 12., at 2:53, Anamitra Bhattacharyya  
> wrote:
> 
> Hi Attila
> We use Nashorn as a JSR 223 language and do not use any internal Nashorn api 
> - just the standard exposed using the JSR 223 interfaces. Are you saying that 
> Nashorn would be available as a separately downloadable jar that we can put 
> in our java application path and it will show up as a jsr223 language? That 
> would be extremely helpful for all our customers who have developed thousands 
> of JVM bases Nashorn scripts. 
> thanks
> Anamitra Bhattacharyya
> STSM, Maximo, IoT
> IBM Master Inventor
>  
>  
>  
> - Original message -
> From: Attila Szegedi 
> Sent by: "nashorn-dev" 
> To: Nashorn-Dev 
> Cc:
> Subject: [EXTERNAL] Standalone Nashorn is coming for Java 15+
> Date: Sun, Oct 11, 2020 3:29 AM
>  
> Folks,
> 
> some good news for y'all (presumably you're on this mailing list because you 
> are interested in Nashorn.)
> 
> Since Nashorn's removal from JDK starting with Java 15, numerous people have 
> realized that they, in fact, rely on it. To remedy the situation, Nashorn 
> will continue as a standalone project within the OpenJDK organization.
> 
> You might ask, "But isn't Nashorn officially dead?", to which the answer is: 
> no, it isn’t. The project’s product is merely no longer shipped as part of 
> the JDK project. The Nashorn project in OpenJDK organization is still 
> live[1], along with all of its resources including the mailing list this 
> message is posted on. It was merely not active for a while, until now.
> 
> What does this mean in practical terms? The following will happen or are 
> happening:
> 
> * Project communication will continue on this mailing list 
> ().
> 
> * A GitHub project openjdk/nashorn will be set up. It will be populated by a 
> clone of the openjdk/jdk14u repo that has been filtered for  Nashorn-only 
> commits. (Thanks, git-filter-repo[2], you are awesome!) There will be no 
> synchronization back to jdk14u afterwards, it won't act as an upstream. 
> openjdk/nashorn proceeds independently from that point on.
> 
> * The project will change the module and package names as it can't keep 
> living within the top-level "jdk." package. In accordance with other 
> independently-developed OpenJDK projects, it will transition to module and 
> package names within the "org.openjdk." package. Fortunately for Nashorn, it 
> is mostly used through the "javax.script.*" APIs so people that use it 
> through those APIs won't have to adapt their code. Creating the engine by 
> name as described in Nashorn’s last (JDK 14) API docs[3] will continue to 
> work. People that used to use the Nashorn-specific API (typically, 
> AbstractJSObject and ScriptObjectMirror) will need to adapt their code for 
> new package names, though.
> 
> * Project artifacts (in plain English: JAR file to be used with Maven etc.) 
> will be published on SonaType under the "org.openjdk" organization, again 
> similar to other independently-developed OpenJDK projects.
> 
> The goal for the initial release is to ship a standalone Nashorn with 
> identical functionality to that in JDK 14, with the only changes being:
> 
> * reversing of deprecation and “scheduled for removal” notices,
> * enacting the package and module name changes,
> * replacing or removing dependencies on various jdk.internal.* packages since 
> those are no longer exported from JDK modules to the Nashorn module.
> 
> It is possible for expediency that we will decide to ship Nashorn as a 
> library first, and separately ship the initial version of the jjs shell 
> sometime later.
> 
> I’m personally undertaking these initial tasks. I will let you know here on 
> the list about the progress, and once the repo is set up the work will also 
> start appearing on a branch.
> 
> There are some other aspects of the project that need to be worked out: 
> contribution and review guidelines, publication location of the accompanying 
> documentation (that will no longer be part of the JDK documentation) and so 
> on. I will post discussion-initiating e-mails for these as well as time comes 
> and will absolutely welcome feedback on them, just as I welcome feedback on 
> this plan too.
> 
> Attila.
> 
> --
> [1] https://openjdk.java.net/projects/nashorn/ 
>  
> [2] https://github.com/newren/git-filter-repo 
>  
> [3] 
> https://docs.oracle.com/en/java/javase/14/docs/api/jdk.scripting.nashorn/module-summary.html
>  
> 
>  
>  
> 

Re: New Nashorn Project Lead: Attila Szegedi

[Marcus Lagergren]

+100 from me as well. Thank you, Attilla, for picking up the torch.

> On 12 Oct 2020, at 11:46, sundararajan.athijegannat...@oracle.com wrote:
> 
> +100 :) Congrats Attila!
> 
> -Sundar
> 
> On 12/10/20 3:10 pm, Hannes Wallnoefer wrote:
>> Excellent news, Attila!
>> 
>> I couldn’t think of a better person for this task than you. I’m glad there 
>> is a future for Nashorn, and I hope I’ll be able to contribute something to 
>> the project somewhere down the road.
>> 
>> Hannes
>> 
>> 
>>> Am 11.10.2020 um 09:26 schrieb Attila Szegedi :
>>> 
>>> Thank you, Vladimir!
>>> 
>>> I accept the nomination[1].
>>> 
>>> Attila.
>>> 
>>> [1] I read the Bylaws and they do not seem to require the candidate to 
>>> declare whether they accept – or even agree with – the nomination. While I 
>>> wouldn’t think anyone would ever nominate a candidate without their 
>>> consent, I still think it’s good to have a public record of it.
>>> 
 On 2020. Oct 10., at 1:15, Vladimir Kozlov  
 wrote:
 
 I hereby nominate Attila Szegedi [1] as new Nashorn Project Lead.
 
 Attila was a significant contributor to Nashorn, beginning with the 
 introduction of the dynalink library[2].
 
 According to the Bylaws [3] after current Project Lead resign [4] new 
 Project lead should be nominated.
 
 As Group Lead of Sponsoring Group [5] I approve this nomination.
 
 According to the Bylaws definition of Three-Vote Consensus [6], this is 
 sufficient to approve the nomination.
 
 Thanks,
 Vladimir Kozlov
 
 [1] https://github.com/szegedi
 [2] https://openjdk.java.net/jeps/276
 [3] https://openjdk.java.net/bylaws#project-lead
 [4] 
 https://mail.openjdk.java.net/pipermail/nashorn-dev/2020-October/007549.html
 [5] https://openjdk.java.net/census#nashorn
 [6] https://openjdk.java.net/bylaws#three-vote-consensus

Re: New Nashorn Project Lead: Attila Szegedi

[sundararajan . athijegannathan]

+100 :) Congrats Attila!

-Sundar

On 12/10/20 3:10 pm, Hannes Wallnoefer wrote:

Excellent news, Attila!

I couldn’t think of a better person for this task than you. I’m glad there is a 
future for Nashorn, and I hope I’ll be able to contribute something to the 
project somewhere down the road.

Hannes



Am 11.10.2020 um 09:26 schrieb Attila Szegedi :

Thank you, Vladimir!

I accept the nomination[1].

Attila.

[1] I read the Bylaws and they do not seem to require the candidate to declare 
whether they accept – or even agree with – the nomination. While I wouldn’t 
think anyone would ever nominate a candidate without their consent, I still 
think it’s good to have a public record of it.


On 2020. Oct 10., at 1:15, Vladimir Kozlov  wrote:

I hereby nominate Attila Szegedi [1] as new Nashorn Project Lead.

Attila was a significant contributor to Nashorn, beginning with the 
introduction of the dynalink library[2].

According to the Bylaws [3] after current Project Lead resign [4] new Project 
lead should be nominated.

As Group Lead of Sponsoring Group [5] I approve this nomination.

According to the Bylaws definition of Three-Vote Consensus [6], this is 
sufficient to approve the nomination.

Thanks,
Vladimir Kozlov

[1] https://github.com/szegedi
[2] https://openjdk.java.net/jeps/276
[3] https://openjdk.java.net/bylaws#project-lead
[4] https://mail.openjdk.java.net/pipermail/nashorn-dev/2020-October/007549.html
[5] https://openjdk.java.net/census#nashorn
[6] https://openjdk.java.net/bylaws#three-vote-consensus

Re: New Nashorn Project Lead: Attila Szegedi

[Hannes Wallnoefer]

Excellent news, Attila! 

I couldn’t think of a better person for this task than you. I’m glad there is a 
future for Nashorn, and I hope I’ll be able to contribute something to the 
project somewhere down the road.

Hannes


> Am 11.10.2020 um 09:26 schrieb Attila Szegedi :
> 
> Thank you, Vladimir!
> 
> I accept the nomination[1].
> 
> Attila.
> 
> [1] I read the Bylaws and they do not seem to require the candidate to 
> declare whether they accept – or even agree with – the nomination. While I 
> wouldn’t think anyone would ever nominate a candidate without their consent, 
> I still think it’s good to have a public record of it.
> 
>> On 2020. Oct 10., at 1:15, Vladimir Kozlov  
>> wrote:
>> 
>> I hereby nominate Attila Szegedi [1] as new Nashorn Project Lead.
>> 
>> Attila was a significant contributor to Nashorn, beginning with the 
>> introduction of the dynalink library[2].
>> 
>> According to the Bylaws [3] after current Project Lead resign [4] new 
>> Project lead should be nominated.
>> 
>> As Group Lead of Sponsoring Group [5] I approve this nomination.
>> 
>> According to the Bylaws definition of Three-Vote Consensus [6], this is 
>> sufficient to approve the nomination.
>> 
>> Thanks,
>> Vladimir Kozlov
>> 
>> [1] https://github.com/szegedi
>> [2] https://openjdk.java.net/jeps/276
>> [3] https://openjdk.java.net/bylaws#project-lead
>> [4] 
>> https://mail.openjdk.java.net/pipermail/nashorn-dev/2020-October/007549.html
>> [5] https://openjdk.java.net/census#nashorn
>> [6] https://openjdk.java.net/bylaws#three-vote-consensus
> 

Re: New Nashorn Project Lead: Attila Szegedi

[Attila Szegedi]

Thank you, Vladimir!

I accept the nomination[1].

Attila.

[1] I read the Bylaws and they do not seem to require the candidate to declare 
whether they accept – or even agree with – the nomination. While I wouldn’t 
think anyone would ever nominate a candidate without their consent, I still 
think it’s good to have a public record of it.

> On 2020. Oct 10., at 1:15, Vladimir Kozlov  wrote:
> 
> I hereby nominate Attila Szegedi [1] as new Nashorn Project Lead.
> 
> Attila was a significant contributor to Nashorn, beginning with the 
> introduction of the dynalink library[2].
> 
> According to the Bylaws [3] after current Project Lead resign [4] new Project 
> lead should be nominated.
> 
> As Group Lead of Sponsoring Group [5] I approve this nomination.
> 
> According to the Bylaws definition of Three-Vote Consensus [6], this is 
> sufficient to approve the nomination.
> 
> Thanks,
> Vladimir Kozlov
> 
> [1] https://github.com/szegedi
> [2] https://openjdk.java.net/jeps/276
> [3] https://openjdk.java.net/bylaws#project-lead
> [4] 
> https://mail.openjdk.java.net/pipermail/nashorn-dev/2020-October/007549.html
> [5] https://openjdk.java.net/census#nashorn
> [6] https://openjdk.java.net/bylaws#three-vote-consensus

Re: Resigning as OpenJDK Nashorn Project Lead

[Attila Szegedi]

Thank you Jim for creating Nashorn and shepherding it through the years. I 
remember when I joined the project that I was impressed with the quality of the 
original code I found there, as well as your eagerness to always help us get up 
to speed on it. Thanks in big part to you, it was very easy to hit the ground 
running and start working on it.

Working on Nashorn and Dynalink was indeed my full time job during 4 years of 
working at Oracle between 2012-15. At times I couldn’t believe my luck: I was 
being paid to work on an open source project that was also immensely fun to 
work at and people enjoyed using a lot!

Attila.

> On 2020. Oct 5., at 20:11, Jim Laskey  wrote:
> 
> I hereby resign as Nashorn Project Lead.
> 
> Nashorn [1] started in 2010 as a small JavaScript prototype to fill in for 
> the discontinued JavaFX compiler project [2] and as a testing ground for 
> Java's "new" invoke dynamic instructions [3]. Though Nashorn became somewhat 
> a niche tool, it found itself playing important roles in many important 
> projects [4]. Nashorn was deprecated in JDK 11 [5] was removed from the 
> OpenJDK in JDK 15 [6]. Moving forward, it is hoped that Nashorn may continue 
> on as a standalone library in maven central.
> 
> According to the bylaws, the lead of the sponsoring group (Vladimir Kozlov 
> from the HotSpot group) needs to assign a new project lead [7]. I recommend 
> the nomination of Attila Szegedi [8] for this role. Attila was a significant 
> contributor to Nashorn, beginning with the introduction of the dynalink 
> library[9], through to the introduction of optimistic typing. Nashorn will be 
> in good hands. I can't recommend him enough. 
> 
> Thank you.
> 
> -- JIm
> 
> [1] http://openjdk.java.net/jeps/174 
> [2] https://www.infoworld.com/article/2077746/javafx-compiler-released.html 
> 
> [3] https://www.jcp.org/en/jsr/detail?id=292
> [4] https://www.infoq.com/news/2015/01/nashorn-at-netflix/
> [5] https://openjdk.java.net/jeps/335
> [6] https://openjdk.java.net/jeps/372 
> [7] http://openjdk.java.net/bylaws#project-lead 
> 
> [8] https://github.com/szegedi
> [9] https://openjdk.java.net/jeps/276 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

Re: Resigning as OpenJDK Nashorn Project Lead

[Attila Szegedi]

Could you elaborate? I worked on both Rhino and Nashorn and have been a project 
admin for Rhino for a while. So did Hannes. And yet us having worked on both is 
the only relation between the two I can see. They certainly don’t share code 
and I don’t think Rhino is in any form an “original” of Nashorn. Is there some 
other relation you’re thinking of?

Sent from my iPhone

> On Oct 6, 2020, at 05:24, nash...@x.colbyrussell.com wrote:
> 
> On 10/5/20 10:17 PM, sundararajan.athijegannat...@oracle.com wrote:
>> Nashorn is not related to Rhino project at all. Nashorn is a different
>> implementation of ES 5.1 and select few features of ES6 .
> 
> 
> Although the second sentence is true, the first is not.
> 
> -- 
> Colby Russell
> 

Re: Resigning as OpenJDK Nashorn Project Lead

[nashorn]

On 10/5/20 10:17 PM, sundararajan.athijegannat...@oracle.com wrote:

Nashorn is not related to Rhino project at all. Nashorn is a different
implementation of ES 5.1 and select few features of ES6 .



Although the second sentence is true, the first is not.

--
Colby Russell

Re: Resigning as OpenJDK Nashorn Project Lead

[sundararajan . athijegannathan]

Just a clarification. You said "the original Rhino project" - which 
seems to suggest that Nashorn is related to Rhino. Nashorn is not 
related to Rhino project at all. Nashorn is a different implementation 
of ES 5.1 and select few features of ES6 .


-Sundar

On 05/10/20 11:50 pm, nash...@x.colbyrussell.com wrote:

On 10/5/20 1:11 PM, Jim Laskey wrote:

Nashorn was deprecated in JDK 11 [5] was removed from the OpenJDK in
JDK 15 [6]. Moving forward, it is hoped that Nashorn may continue on
as a standalone library in maven central.


Any chance Nashorn ownership would be transferred to either the Apache
Foundation and licensed appropriately, or donated to the the original
Rhino project?

Re: Resigning as OpenJDK Nashorn Project Lead

[nashorn]

On 10/5/20 1:11 PM, Jim Laskey wrote:

Nashorn was deprecated in JDK 11 [5] was removed from the OpenJDK in
JDK 15 [6]. Moving forward, it is hoped that Nashorn may continue on
as a standalone library in maven central.


Any chance Nashorn ownership would be transferred to either the Apache
Foundation and licensed appropriately, or donated to the the original
Rhino project?

--
Colby Russell

Re: RFR 8246113: re-visit javax/script test that still requires jdk.scripting.nashorn module

[Jim Laskey]

+1

> On Jul 15, 2020, at 12:58 PM, sundararajan.athijegannat...@oracle.com wrote:
> 
> Hi,
> 
> Please review - removing these tests.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8246113
> 
> Webrev: http://cr.openjdk.java.net/~sundar/8246113/webrev.00/
> 
> Thanks
> 
> -Sundar
> 

RFR 8246113: re-visit javax/script test that still requires jdk.scripting.nashorn module

[sundararajan . athijegannathan]

Hi,

Please review - removing these tests.

Bug: https://bugs.openjdk.java.net/browse/JDK-8246113

Webrev: http://cr.openjdk.java.net/~sundar/8246113/webrev.00/

Thanks

-Sundar

Re: RFR jdk15 8247956: remove scripts under bin/nashorn and doc/nashorn/source

[Magnus Ihse Bursie]

On 2020-06-23 08:32, sundararajan.athijegannat...@oracle.com wrote:

Please review

Bug: https://bugs.openjdk.java.net/browse/JDK-8247956

Webrev: http://cr.openjdk.java.net/~sundar/8247956/webrev.00/

Looks good to me.

Thank you for cleaning out these remnants.

/Magnus


Thanks

-Sundar

Re: RFR jdk15 8247956: remove scripts under bin/nashorn and doc/nashorn/source

[James Laskey]

+1



> On Jun 23, 2020, at 3:37 AM, sundararajan.athijegannat...@oracle.com wrote:
> 
> Please review
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8247956
> 
> Webrev: http://cr.openjdk.java.net/~sundar/8247956/webrev.00/
> 
> Thanks
> 
> -Sundar
> 

Re: JDK-8229011: Workaround?

[Jim Laskey]

Not sure if it will help but you could try the "--optimistic-types=false" 
option.


> On Jun 9, 2020, at 6:22 AM, STAMPF Lukas  wrote:
> 
> Hello,
> 
> I wanted to ask if there is any workaround for the memory leak described in
> https://bugs.openjdk.java.net/browse/JDK-8229011
> 
> Unfortunatly downgrading back to JDK8 is not an option for us.
> 
> Kind regards

Re: Questions about nashorn

[Hannes Wallnoefer]

Hello,

Answers inline below.

> Am 18.05.2020 um 05:40 schrieb 阮智 <1655362...@qq.com>:
> 
> Hello, I have some questions about using nashorn in the project
> 
> The first question: what is the usage scenario of 
> nashorn.option.class.cache.size, and what benefits can be brought by 
> modifying (increasing or decreasing) this value
> 

Nashorn compiles JS scripts to Java classes. The class cache size property 
defines the number of compiled script classes that are cached for reuse. So if 
you compile and evaluate a lot of scripts and use some scripts repeatedly, 
tweaking this option may improve performance by avoiding recompilation of 
scripts. 

> 
> The second question: why is it very slow to execute the evel function and 
> invokeFunction function for the first time. I understand that the first time 
> evel takes time is mainly to compile the script, but why the invokeFunction 
> function is also slow for the first and second time, and tends to be stable 
> for the third time and later, and the performance reaches the best

The first run of Java code on a VM with adaptive optimizations is always slow. 
In the case of Nashorn, this affects the parser and compiler, the runtime 
libraries and the compiled script itself, so the effect is quite noticeable.

Hannes

Re: RFR 8241749

[Nils Kilden-Pedersen]

On Mon, Apr 20, 2020 at 1:35 PM Abhay Kulkarni 
wrote:

> Hi,
>
> I don't know if this question was asked earlier. Is there any other
> javascript engine which can be used instead of nashorn in JDK 11? Also,
> exactly in which version/release of openJDK 11 is this removal taking
> effect?
>
> Also, to reiterate others' concerns, this breaks backward compatibility for
> my application. I hope this removal does not happen!
>
> Abhay
>

Take a look at this:
https://github.com/flier/jav8

Re: RFR 8241749

[Abhay Kulkarni]

Hi,

I don't know if this question was asked earlier. Is there any other
javascript engine which can be used instead of nashorn in JDK 11? Also,
exactly in which version/release of openJDK 11 is this removal taking
effect?

Also, to reiterate others' concerns, this breaks backward compatibility for
my application. I hope this removal does not happen!

Abhay

Re: RFR 8241749: Remove the Nashorn JavaScript Engine

[sundararajan . athijegannathan]

Thanks Mandy. I'll add bug id next to @ignore before push.

Thanks,

-Sundar

On 16/04/20 2:50 am, Mandy Chung wrote:

This looks okay to me.

Can you add the bug ID next to @ignore that will make it easier to 
find the JBS issue?   These test bugs are filed with P4 but I think 
they should be fixed in 15.


Mandy

On 4/15/20 8:56 AM, sundararajan.athijegannat...@oracle.com wrote:

Please review.

Nashorn script engine modules (jdk.scripting.nashorn, 
jdk.scripting.nashorn.shell) and jjs tool are removed.


Bug: https://bugs.openjdk.java.net/browse/JDK-8241749

JEP: https://openjdk.java.net/jeps/372

CSR: https://bugs.openjdk.java.net/browse/JDK-8241751

Webrev: http://cr.openjdk.java.net/~sundar/8241749/webrev.00/index.html

Few tests that use nashorn are worked around by @ignore or deleting 
relevant nashorn test sections. Separate test bugs have been filed to 
handle these.


https://bugs.openjdk.java.net/browse/JDK-8242860

https://bugs.openjdk.java.net/browse/JDK-8242859

https://bugs.openjdk.java.net/browse/JDK-8242858

https://bugs.openjdk.java.net/browse/JDK-8241982

https://bugs.openjdk.java.net/browse/JDK-8235594

Thanks,

-Sundar

Re: RFR 8241749: Remove the Nashorn JavaScript Engine

[sundararajan . athijegannathan]

Thanks for spotting this Magnus! I'll fix this before push.

Thanks.

-Sundar

On 15/04/20 10:44 pm, Magnus Ihse Bursie wrote:

On 2020-04-15 17:56, sundararajan.athijegannat...@oracle.com wrote:

Please review.

Nashorn script engine modules (jdk.scripting.nashorn, 
jdk.scripting.nashorn.shell) and jjs tool are removed.


Bug: https://bugs.openjdk.java.net/browse/JDK-8241749

JEP: https://openjdk.java.net/jeps/372

CSR: https://bugs.openjdk.java.net/browse/JDK-8241751

Webrev: http://cr.openjdk.java.net/~sundar/8241749/webrev.00/index.html
Build changes look almost OK. However, in make/RunTests.gmk, you have 
removed this:
-hotspot_JTREG_PROBLEM_LIST += 
$(TOPDIR)/test/hotspot/jtreg/ProblemList.txt

which should stay.

/Magnus

Few tests that use nashorn are worked around by @ignore or deleting 
relevant nashorn test sections. Separate test bugs have been filed to 
handle these.


https://bugs.openjdk.java.net/browse/JDK-8242860

https://bugs.openjdk.java.net/browse/JDK-8242859

https://bugs.openjdk.java.net/browse/JDK-8242858

https://bugs.openjdk.java.net/browse/JDK-8241982

https://bugs.openjdk.java.net/browse/JDK-8235594

Thanks,

-Sundar

Re: RFR 8241749: Remove the Nashorn JavaScript Engine

[Mandy Chung]

This looks okay to me.

Can you add the bug ID next to @ignore that will make it easier to find 
the JBS issue?   These test bugs are filed with P4 but I think they 
should be fixed in 15.


Mandy

On 4/15/20 8:56 AM, sundararajan.athijegannat...@oracle.com wrote:

Please review.

Nashorn script engine modules (jdk.scripting.nashorn, 
jdk.scripting.nashorn.shell) and jjs tool are removed.


Bug: https://bugs.openjdk.java.net/browse/JDK-8241749

JEP: https://openjdk.java.net/jeps/372

CSR: https://bugs.openjdk.java.net/browse/JDK-8241751

Webrev: http://cr.openjdk.java.net/~sundar/8241749/webrev.00/index.html

Few tests that use nashorn are worked around by @ignore or deleting 
relevant nashorn test sections. Separate test bugs have been filed to 
handle these.


https://bugs.openjdk.java.net/browse/JDK-8242860

https://bugs.openjdk.java.net/browse/JDK-8242859

https://bugs.openjdk.java.net/browse/JDK-8242858

https://bugs.openjdk.java.net/browse/JDK-8241982

https://bugs.openjdk.java.net/browse/JDK-8235594

Thanks,

-Sundar

Re: RFR 8241749: Remove the Nashorn JavaScript Engine

[Magnus Ihse Bursie]

On 2020-04-15 17:56, sundararajan.athijegannat...@oracle.com wrote:

Please review.

Nashorn script engine modules (jdk.scripting.nashorn, 
jdk.scripting.nashorn.shell) and jjs tool are removed.


Bug: https://bugs.openjdk.java.net/browse/JDK-8241749

JEP: https://openjdk.java.net/jeps/372

CSR: https://bugs.openjdk.java.net/browse/JDK-8241751

Webrev: http://cr.openjdk.java.net/~sundar/8241749/webrev.00/index.html
Build changes look almost OK. However, in make/RunTests.gmk, you have 
removed this:


-hotspot_JTREG_PROBLEM_LIST += $(TOPDIR)/test/hotspot/jtreg/ProblemList.txt

which should stay.

/Magnus

Few tests that use nashorn are worked around by @ignore or deleting 
relevant nashorn test sections. Separate test bugs have been filed to 
handle these.


https://bugs.openjdk.java.net/browse/JDK-8242860

https://bugs.openjdk.java.net/browse/JDK-8242859

https://bugs.openjdk.java.net/browse/JDK-8242858

https://bugs.openjdk.java.net/browse/JDK-8241982

https://bugs.openjdk.java.net/browse/JDK-8235594

Thanks,

-Sundar

Re: Nashorn future

[colby]

On 9/14/19 4:29 AM, eric.vergnaud at wanadoo.fr (Eric Vergnaud) wrote:

I was wondering if some options had been considered:

There is, of course, the familiar path of transferring it to the Apache
Foundation, which would require a license change (from GPL to Apache
2.0).

So long as a license change are being discussed, though, why not
consider donating the developers of Nashorn's predecessor and namesake:
Rhino. .  Latest commit was less than
two days ago, and they did a release earlier this year (May 2019).

--
Colby Russell

Re: Bug in NashornScriptEngineFactory.getOutputStatement(...) with a possible fix (Re: Nashorn's javax.script.ScriptEngineFactory produces wrong code

[Rony G. Flatscher]

Hmm, the formatting of the offered fix was mangled (had used a format which was 
obviously not o.k.).
So here another attempt to present the code in a way that makes it hopefully 
easy to copy and paste
(in a fixed pitch the ".replace(...)" invocations are aligned to the same 
column):

- code 
@Override   // enquote string in double-quotes and escape the characters '\', 
'\n', '"' in the string
    public String getOutputStatement(final String toDisplay)
    {
    return "print(\"" + toDisplay.replace("\\", "")
 .replace("\n", "\\n" )
 .replace("\"", "\\\"")
  + "\")";
    }
- code 

---rony


On 05.11.2019 12:09, Rony G. Flatscher wrote:
> Almost two years ago I brought up a bug in 
> NashornScriptEngineFactory.getOutputStatement(String).
> Further attention obviously stopped with the question where an appropriate 
> place would be to file a
> bug.
>
> The bug is caused by not quoting and escaping the passed string such that a 
> proper JavaScript
> statement gets created, if the string contains e.g. comma or wrong characters 
> because they do not
> get escaped. Currently
>
>     nashornFractory.getOutputStatement("'hello world', this is \"Nashorn"\ 
> speaking! ")
>
> will yield
>
>       print('hello world', this is "Nashorn" speaking! )
>
> which is syntactically wrong and causes a ScriptException if executed by 
> Nashorn.
>
> Rather the returned statement in this case should be
>
>     print("'hello world', this is \"Nashorn"\ speaking! ")
>
> ---
>
> Although I signed the OCA I have no rights to open a bug, so I kindly ask 
> someone with the power to
> do so.
>
> Also, a possible, simple fix for getOutputStatement() in
> jdk.nashorn.api.scripting.NashornScriptEngineFactory would be:
>
> @Override // enquote string in double-quotes and escape the characters 
> '\', '\n', '"' in the
> string public String getOutputStatement(final String toDisplay) { return 
> "print(\"" +
> toDisplay.replace("\\", "") .replace("\n", "\\n" ) .replace("\"", 
> "\\\"") + "\")"; }
>
> Again, having signed the OCA it should be o.k. to use this code directly to 
> fix the bug.
>
> If you prefer a patch, then please point me to the exact mercurial repository 
> I should check out in
> order to produce the patch. (The original code is merely a one-liner: return 
> "print(" + toDisplay +
> ")";  so it should be easy and safe to apply the above code directly.)
>
> ---rony
... cut ...

Bug in NashornScriptEngineFactory.getOutputStatement(...) with a possible fix (Re: Nashorn's javax.script.ScriptEngineFactory produces wrong code

[Rony G. Flatscher]

Almost two years ago I brought up a bug in 
NashornScriptEngineFactory.getOutputStatement(String).
Further attention obviously stopped with the question where an appropriate 
place would be to file a
bug.

The bug is caused by not quoting and escaping the passed string such that a 
proper JavaScript
statement gets created, if the string contains e.g. comma or wrong characters 
because they do not
get escaped. Currently

    nashornFractory.getOutputStatement("'hello world', this is \"Nashorn"\ 
speaking! ")

will yield

      print('hello world', this is "Nashorn" speaking! )

which is syntactically wrong and causes a ScriptException if executed by 
Nashorn.

Rather the returned statement in this case should be

    print("'hello world', this is \"Nashorn"\ speaking! ")

---

Although I signed the OCA I have no rights to open a bug, so I kindly ask 
someone with the power to
do so.

Also, a possible, simple fix for getOutputStatement() in
jdk.nashorn.api.scripting.NashornScriptEngineFactory would be:

@Override // enquote string in double-quotes and escape the characters '\', 
'\n', '"' in the
string public String getOutputStatement(final String toDisplay) { return 
"print(\"" +
toDisplay.replace("\\", "") .replace("\n", "\\n" ) .replace("\"", 
"\\\"") + "\")"; }

Again, having signed the OCA it should be o.k. to use this code directly to fix 
the bug.

If you prefer a patch, then please point me to the exact mercurial repository I 
should check out in
order to produce the patch. (The original code is merely a one-liner: return 
"print(" + toDisplay +
")";  so it should be easy and safe to apply the above code directly.)

---rony



On 07.01.2017 15:54, Rony G. Flatscher wrote:
> On 07.01.2017 15:02, Edmond Kemokai wrote:
>> Ah, I see your point. 
>>
>> I'll say file a bug. If you look at the NashornScriptEngineFactory.java, 
>> you'll see that it simply
>> concatenates the supplied string between a print statement, the current 
>> implementation requires
>> proper escaping of input.
> Where would be the appropriate place to file a bug for Nashorn? Would you 
> have an URL by any chance?
>
> ---rony
>
>
>>
>> On Jan 7, 2017 8:52 AM, "Rony G. Flatscher" > > wrote:
>>
>> Hi Ed,
>>
>>
>> On 06.01.2017 17:49, Edmond Kemokai wrote:
>>> The issue seems to go away after I quote the string.
>> If you supplied a Javascript encoded string to the Nashorn
>> ScriptEngineFactory.getOutputStatement() you removed the cause of 
>> demonstrating that Nashorn
>> ScriptEngineFactory creates wrong output statements!
>>
>> The problem is that Nashorn's ScriptEngineFactory.getOutputStatement() 
>> does not analyze the
>> received string (which may be any sequence of characters) to see whether 
>> escaping needs to
>> take place (e.g. containing quotes or backslashes) and finally enquoting 
>> the received (maybe
>> escape processed) string to make it acceptable as an argument to its 
>> print() function!
>>
>> The task at hand is to create an output statement that will be able to 
>> output the received
>> string as is (no matter what the string contains), character by 
>> character!
>>
>> ---
>>
>> Background: the JSR-223/javax.script package was *not* created with a 
>> specific scripting
>> language in mind. A scripting factory cannot assume that a supplied 
>> string adheres to the
>> specific rules of that particular scripting language. The 
>> getOutputStatement() method is there
>> to get an output statement adhering to the syntax rules of the script 
>> language that outputs
>> (shows) the string exactly as received, character by character! Each 
>> script language may have
>> different syntax, escaping rules etc., therefore the ScriptEngineFactory 
>> knowing its
>> ScriptEngines syntax and rules is asked to create a proper output 
>> statement.
>>
>> It is the script factory's responsibility to analyze the received string 
>> and to escape
>> characters in order to have the script engine output the string exactly 
>> as received, character
>> by character.
>>
>> To test this, my test program feeds any available javax.script language 
>> with a string
>> containing quotes around the script engine name (to test quote escaping) 
>> and has the script
>> engine take its own medicine by executing the returned output statement.
>>
>> In the case of Nashorn the script engine is not able to reliably run the 
>> output statement
>> generated by its own ScriptEngineFactory!
>>
>> So, if getOutputStatement() receives the following string value to 
>> output:
>>
>> abc "def" ghi
>>
>> it needs to analyze and in this case escape the string first to match 
>> the rules of JavaScript:
>>
>> abc \"def\" ghi
>>
>> and then produce the output statement by enquoting the escaped string:
>>
>> print("abc \"def\" ghi")
>>
>> This way, this 

Re: Bug report: can't call static methods on a Java class instance

[Matt Zand]

 Hey guys,

How I can un-subscribe from this mailing list

Thx,

On Wed, Oct 30, 2019 at 9:33 AM tibetty  wrote:

> t works and many thanks for your timely response, Joao!  However,
> personally
> I think it's problematic for Nashorn not to support the static method
> invocation from an extended class.  Any design consideration under the
> hood?
>
>
>
> --
> Sent from: http://nashorn.36665.n7.nabble.com/
>


-- 
Cheers,

Matt Zand
Cell: 202-420-9192
Work: 240-200-6131
High School Technology Services 
DC Web Makers 
Coding Bootcamps 

Re: Bug in extractVarNodesFromDeadCode. Variable "x" has already been declared

[Matt Zand]

 Hey guys,

How I can un-subscribe from this mailing list

Thx,

On Wed, Oct 30, 2019 at 6:33 AM Hannes Wallnöfer <
hannes.wallnoe...@oracle.com> wrote:

> Thanks for the report!
>
> https://bugs.openjdk.java.net/browse/JDK-8233195
>
> The provided patch looks reasonable so the chances to get this fixed are
> quite good.
>
> Hannes
>
>
> > Am 28.10.2019 um 16:47 schrieb Jim Laskey :
> >
> > Obviously, this wasn't intended for the list. To clarify, since Nashorn
> is being deprecated, we are taking input such as this and recording it as a
> bug in case someone adopts Nashorn in future.
> >
> > Cheers,
> >
> > -- Jim
> >
> >
> >> On Oct 28, 2019, at 12:36 PM, Jim Laskey 
> wrote:
> >>
> >> You want to take this on?  File a bug and put the e-mail (change set)
> in it, then tell the user Nashorn is deprecated.
> >>
> >>> On Oct 28, 2019, at 12:21 PM, Anton Mitrofanov 
> wrote:
> >>>
> >>> Hi.
> >>>
> >>> We have encountered another bug in Nashorn. It can be reproduced by
> evaluation of this script with "jjs --language=es6":
> >>>
> >>> if (true) { throw "test"; } { let x = "1"; } { let x = 2; }
> >>>
> >>> It results in compilation error:
> >>>
> >>> ECMAScript Exception: SyntaxError: :1:34 Variable "x" has
> already been declared if (true) { throw "test"; } { let x = "1"; } { let x
> = 2; }
> >>>^
> >>> While expected out was to get runtime exception "test".
> >>>
> >>> Looks like the problem is in dead code elimination logic of
> FoldConstants.extractVarNodesFromDeadCode function.
> >>>
> >>> And here is the patch to fix it:
> >>>
> >>> diff -r 6e287efa5fa3
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/FoldConstants.java
> >>> ---
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/FoldConstants.java
>  Wed Oct 23 09:53:07 2019 +0200
> >>> +++
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/FoldConstants.java
>  Wed Oct 23 14:23:48 2019 +0300
> >>> @@ -195,7 +195,9 @@
> >>>   deadCodeRoot.accept(new SimpleNodeVisitor() {
> >>>   @Override
> >>>   public boolean enterVarNode(final VarNode varNode) {
> >>> -statements.add(varNode.setInit(null));
> >>> +if (!varNode.isBlockScoped()) {
> >>> +statements.add(varNode.setInit(null));
> >>> +}
> >>>   return false;
> >>>   }
> >>>
> >>>
> >>
> >
>
>

-- 
Cheers,

Matt Zand
Cell: 202-420-9192
Work: 240-200-6131
High School Technology Services 
DC Web Makers 
Coding Bootcamps 

Re: Bug report: can't call static methods on a Java class instance

[tibetty]

It works and many thanks for your timely response, Joao!  However,
personally I think it's problematic for Nashorn not to support the static
method invocation from an extended class.  Any design consideration under
the hood?

On Wed, Oct 30, 2019 at 8:27 PM João Paulo Varandas 
wrote:

> Call parseObject directly from the class that contains the static method,
> not from the extended one.
>
> var jso = Java.type('com.alibaba.fastjson.JSON').parseObject(json);
>
>
>
> https://github.com/alibaba/fastjson/blob/master/src/main/java/com/alibaba/fastjson/JSON.java
>
>
>
>
>
> On Wed, Oct 30, 2019 at 9:22 AM tibetty  wrote:
>
>> I used your method, but it stills failed calling a static method of a 3rd
>> party class (com.alibaba.fastjson.JSONObject):
>> Nashorn (JS) code:
>> var jso = Java.type('com.alibaba.fastjson.JSONObject').parseObject(json);
>>
>> Error Message:
>> Exception in thread "main" javax.script.ScriptException: TypeError:
>> Java.type("com.alibaba.fastjson.JSONObject").parseObject is not a function
>> in  at line number 1
>>
>> How to overcome this kind of problem?
>>
>>
>>
>>
>> --
>> Sent from: http://nashorn.36665.n7.nabble.com/
>>
>
> " This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they are
> addressed. If you have received this email in error please notify the
> system manager. This message contains confidential information and is
> intended only for the individual named. If you are not the named addressee
> you should not disseminate, distribute or copy this e-mail. Please notify
> the sender immediately by e-mail if you have received this e-mail by
> mistake and delete this e-mail from your system. If you are not the
> intended recipient you are notified that disclosing, copying, distributing
> or taking any action in reliance on the contents of this information is
> strictly prohibited. "
>

Re: Bug report: can't call static methods on a Java class instance

[João Paulo Varandas]

Call parseObject directly from the class that contains the static method,
not from the extended one.

var jso = Java.type('com.alibaba.fastjson.JSON').parseObject(json);


https://github.com/alibaba/fastjson/blob/master/src/main/java/com/alibaba/fastjson/JSON.java





On Wed, Oct 30, 2019 at 9:22 AM tibetty  wrote:

> I used your method, but it stills failed calling a static method of a 3rd
> party class (com.alibaba.fastjson.JSONObject):
> Nashorn (JS) code:
> var jso = Java.type('com.alibaba.fastjson.JSONObject').parseObject(json);
>
> Error Message:
> Exception in thread "main" javax.script.ScriptException: TypeError:
> Java.type("com.alibaba.fastjson.JSONObject").parseObject is not a function
> in  at line number 1
>
> How to overcome this kind of problem?
>
>
>
>
> --
> Sent from: http://nashorn.36665.n7.nabble.com/
>

-- 
" This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error please notify the 
system manager. This message contains confidential information and is 
intended only for the individual named. If you are not the named addressee 
you should not disseminate, distribute or copy this e-mail. Please notify 
the sender immediately by e-mail if you have received this e-mail by 
mistake and delete this e-mail from your system. If you are not the 
intended recipient you are notified that disclosing, copying, distributing 
or taking any action in reliance on the contents of this information is 
strictly prohibited. "

Re: Bug report: can't call static methods on a Java class instance

[tibetty]

I used your method, but it stills failed calling a static method of a 3rd
party class (com.alibaba.fastjson.JSONObject):
Nashorn (JS) code:
var jso = Java.type('com.alibaba.fastjson.JSONObject').parseObject(json);

Error Message:
Exception in thread "main" javax.script.ScriptException: TypeError:
Java.type("com.alibaba.fastjson.JSONObject").parseObject is not a function
in  at line number 1

How to overcome this kind of problem?




--
Sent from: http://nashorn.36665.n7.nabble.com/

Re: Bug in extractVarNodesFromDeadCode. Variable "x" has already been declared

[Jim Laskey]

Obviously, this wasn't intended for the list. To clarify, since Nashorn is 
being deprecated, we are taking input such as this and recording it as a bug in 
case someone adopts Nashorn in future.

Cheers,

-- Jim


> On Oct 28, 2019, at 12:36 PM, Jim Laskey  wrote:
> 
> You want to take this on?  File a bug and put the e-mail (change set) in it, 
> then tell the user Nashorn is deprecated.
> 
>> On Oct 28, 2019, at 12:21 PM, Anton Mitrofanov  wrote:
>> 
>> Hi.
>> 
>> We have encountered another bug in Nashorn. It can be reproduced by 
>> evaluation of this script with "jjs --language=es6":
>> 
>> if (true) { throw "test"; } { let x = "1"; } { let x = 2; }
>> 
>> It results in compilation error:
>> 
>> ECMAScript Exception: SyntaxError: :1:34 Variable "x" has already 
>> been declared if (true) { throw "test"; } { let x = "1"; } { let x = 2; }
>> ^
>> While expected out was to get runtime exception "test".
>> 
>> Looks like the problem is in dead code elimination logic of 
>> FoldConstants.extractVarNodesFromDeadCode function.
>> 
>> And here is the patch to fix it:
>> 
>> diff -r 6e287efa5fa3 
>> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/FoldConstants.java
>> --- 
>> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/FoldConstants.java
>> Wed Oct 23 09:53:07 2019 +0200
>> +++ 
>> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/FoldConstants.java
>> Wed Oct 23 14:23:48 2019 +0300
>> @@ -195,7 +195,9 @@
>>deadCodeRoot.accept(new SimpleNodeVisitor() {
>>@Override
>>public boolean enterVarNode(final VarNode varNode) {
>> -statements.add(varNode.setInit(null));
>> +if (!varNode.isBlockScoped()) {
>> +statements.add(varNode.setInit(null));
>> +}
>>return false;
>>}
>> 
>> 
> 

Re: Bug in extractVarNodesFromDeadCode. Variable "x" has already been declared

[Jim Laskey]

You want to take this on?  File a bug and put the e-mail (change set) in it, 
then tell the user Nashorn is deprecated.

> On Oct 28, 2019, at 12:21 PM, Anton Mitrofanov  wrote:
> 
> Hi.
> 
> We have encountered another bug in Nashorn. It can be reproduced by 
> evaluation of this script with "jjs --language=es6":
> 
> if (true) { throw "test"; } { let x = "1"; } { let x = 2; }
> 
> It results in compilation error:
> 
> ECMAScript Exception: SyntaxError: :1:34 Variable "x" has already been 
> declared if (true) { throw "test"; } { let x = "1"; } { let x = 2; }
>  ^
> While expected out was to get runtime exception "test".
> 
> Looks like the problem is in dead code elimination logic of 
> FoldConstants.extractVarNodesFromDeadCode function.
> 
> And here is the patch to fix it:
> 
> diff -r 6e287efa5fa3 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/FoldConstants.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/FoldConstants.java
>  Wed Oct 23 09:53:07 2019 +0200
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/FoldConstants.java
>  Wed Oct 23 14:23:48 2019 +0300
> @@ -195,7 +195,9 @@
> deadCodeRoot.accept(new SimpleNodeVisitor() {
> @Override
> public boolean enterVarNode(final VarNode varNode) {
> -statements.add(varNode.setInit(null));
> +if (!varNode.isBlockScoped()) {
> +statements.add(varNode.setInit(null));
> +}
> return false;
> }
> 
> 

Re: JDK 14 RFR of JDK-8231557: Suppress warnings on non-serializable instance fields in jdk.scripting.nashorn module

[Jim Laskey]

+1

> On Sep 26, 2019, at 7:45 PM, Joe Darcy  wrote:
> 
> Hello,
> 
> Another part of an on-going cleanup of library serialization usage ahead of 
> augmented javac -Xlint warnings (JDK-8160675), the non-serializable instance 
> fields of serializable types in the jdk.scripting.nashorn module should have 
> their serial warnings suppressed. The analogous issue in core libs is 
> JDK-8231202.
> 
> Please review:
> 
> JDK-8231557: Suppress warnings on non-serializable instance fields in 
> jdk.scripting.nashorn module
> http://cr.openjdk.java.net/~darcy/8231557.0/
> 
> Patch below. I'll update copyright years before a push.
> 
> Thanks,
> 
> -Joe
> 
> --- 
> old/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Property.java
>  2019-09-26 15:28:51.76461 -0700
> +++ 
> new/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Property.java
>  2019-09-26 15:28:51.572514000 -0700
> @@ -103,6 +103,7 @@
>  public static final int IS_ACCESSOR_PROPERTY= 1 << 12;
> 
>  /** Property key. */
> +@SuppressWarnings("serial") // Not statically typed as Serializable
>  private final Object key;
> 
>  /** Property flags. */
> --- 
> old/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java
>  2019-09-26 15:28:52.300877999 -0700
> +++ 
> new/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java
>  2019-09-26 15:28:52.108782000 -0700
> @@ -118,11 +118,13 @@
>   * Opaque object representing parser state at the end of the function. 
> Used when reparsing outer function
>   * to help with skipping parsing inner functions.
>   */
> +@SuppressWarnings("serial") // Not statically typed as Serializable
>  private final Object endParserState;
> 
>  /** Code installer used for all further recompilation/specialization of 
> this ScriptFunction */
>  private transient CodeInstaller installer;
> 
> +@SuppressWarnings("serial") // Not statically typed as Serializable
>  private final Map 
> nestedFunctions;
> 
>  /** Id to parent function if one exists */
> @@ -135,8 +137,10 @@
> 
>  private transient DebugLogger log;
> 
> +@SuppressWarnings("serial") // Not statically typed as Serializable
>  private final Map externalScopeDepths;
> 
> +@SuppressWarnings("serial") // Not statically typed as Serializable
>  private final Set internalSymbols;
> 
>  private static final int GET_SET_PREFIX_LENGTH = "*et ".length();
> --- 
> old/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/SharedPropertyMap.java
>  2019-09-26 15:28:52.861157999 -0700
> +++ 
> new/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/SharedPropertyMap.java
>  2019-09-26 15:28:52.657056000 -0700
> @@ -40,6 +40,7 @@
>   */
>  public final class SharedPropertyMap extends PropertyMap {
> 
> +@SuppressWarnings("serial") // Not statically typed as Serializable
>  private SwitchPoint switchPoint;
> 
>  private static final long serialVersionUID = 2166297719721778876L;
> --- 
> old/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/StoredScript.java
>  2019-09-26 15:28:53.357406000 -0700
> +++ 
> new/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/StoredScript.java
>  2019-09-26 15:28:53.157306000 -0700
> @@ -42,12 +42,15 @@
>  private final String mainClassName;
> 
>  /** Map of class names to class bytes. */
> +@SuppressWarnings("serial") // Not statically typed as Serializable
>  private final Map classBytes;
> 
>  /** Constants array. */
> +@SuppressWarnings("serial") // Not statically typed as Serializable
>  private final Object[] constants;
> 
>  /** Function initializers */
> +@SuppressWarnings("serial") // Not statically typed as Serializable
>  private final Map initializers;
> 
>  private static final long serialVersionUID = 2958227232195298340L;
> 

Re: RFR: 8230709: Array index out of bounds in ES6 mode

[Hannes Wallnöfer]

Am 09.09.2019 um 16:50 schrieb Attila Szegedi :
> 
> +1. Ugh. I guess our default lexical context stack is 16 deep.
> 

It is indeed :) Thanks for reviewing.

Hannes


>> On 2019. Sep 9., at 16:38, Hannes Wallnöfer  
>> wrote:
>> 
>> Please review this off-by-one array index fix that was recently reported on 
>> this list:
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8230709
>> Webrev: http://cr.openjdk.java.net/~hannesw/8230709/webrev.00/
>> 
>> Thanks,
>> Hannes
> 

Re: RFR: 8230709: Array index out of bounds in ES6 mode

[Attila Szegedi]

+1. Ugh. I guess our default lexical context stack is 16 deep.

> On 2019. Sep 9., at 16:38, Hannes Wallnöfer  
> wrote:
> 
> Please review this off-by-one array index fix that was recently reported on 
> this list:
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8230709
> Webrev: http://cr.openjdk.java.net/~hannesw/8230709/webrev.00/
> 
> Thanks,
> Hannes