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

Nashorn 15.3 is out

[Attila Szegedi]

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

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?

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

ECMAScript 6 through the ScriptEngineManager

[Attila Szegedi]

Hi folks,

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. 

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

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

Lowering minimum runtime requirement to Java 11

[Attila Szegedi]

Hey folks,

for uniformity, some users would prefer to be able to ship standalone Nashorn 
with earlier Java versions. Now, I’ve known for some time now that the code 
compiles cleanly and all tests pass on Java 11 – that’s as far in the past we 
can reasonably go. Java 8 is unfortunately a no-go, there’s several APIs 
missing there (most notably, both Dynalink and JPMS debut in Java 9, but 
there’s dependence on some other smaller API changes.)

It also looks like if standalone Nashorn is present in the system, it is picked 
up by javax.script.* system when a JavaScript runtime is requested, to wit, 
here’s my results with jrunscript on Java 11:

jrunscript -q   

Language ECMAScript ECMA - 262 Edition 5.1 implementation "Oracle Nashorn" 
11.0.10

$ jrunscript -J--module-path 
-J../../build/nashorn/dist:../../build/nashorn/dependencies -q
Language ECMAScript ECMA - 262 Edition 5.1 implementation "Oracle Nashorn" 
15.1.1

As you can see, putting the location of Nashorn and its dependencies on the 
module path selects it – the version number it prints is 15.1.1. Unfortunately, 
the same doesn’t seem to work for classpath, but… shrug, at this point I’d 
settle for providing one path for backwards compatibility.

So… I’m thinking of putting a 15.2 that’d functionally be identical to 15.1.1 
just compiled for Java 11.

There’s one minor point to consider: should it be compiled with Java 15 
compiler, but targeting 11, or should it simply be compiled with Java 11 
compiler? Is there any advantage in using javac from 15 targeting 11?

Attila.

Nashorn 15.1 is out

[Attila Szegedi]

Hey all,

I just released Nashorn 15.1[0]. We also have a change log[1] now where you can 
easily see what’s new.

The biggest change is that Nashorn can now function when loaded through 
classpath instead of module path. I could confirm with my little test 
application that this solves the issue with it being used in Spring Boot 
applications. Aside from that, I incorporated few smaller bug fixes mostly 
scoured from JBS. I still have some PRs outstanding, so it’s entirely possible 
this will soon be followed up with a 15.1.1, but wanted to get the classpath 
compatibility out there as soon as possible.

Attila.

[0] https://search.maven.org/artifact/org.openjdk.nashorn/nashorn-core/15.1/jar
[1] https://github.com/openjdk/nashorn/blob/main/CHANGELOG.md

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:
>> 
>> <https://github.com/openjdk/nashorn/pull/3>
>> 
>> 
>> 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

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: 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: <https://github.com/openjdk/nashorn/pull/9>

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: 
>> <https://bugs.openjdk.java.net/browse/JDK-8258216> 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.
>>>> 
>> 

Some Nashorn PRs need review love

[Attila Szegedi]

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]

Hi Ben,

funnily enough since I posted this I found this newly submitted issue: 
<https://bugs.openjdk.java.net/browse/JDK-8258216> 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.
>> 

RFC: enable demodularized operation?

[Attila Szegedi]

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.
 

RFR: 8258147: Modernize Nashorn code

[Attila Szegedi]

Hey folks, 

the openjdk bot for sending automated RFR emails based on PRs doesn’t work yet 
(Skara folks should be looking into it) so in the meantime I’ll just post PR 
links here for awareness:

I have a PR that’s essentially code modernization from Nashorn’s mostly Java 
7(!!) compliant source code to Java 11 style + misc cleanups. If someone can 
give it a sanity check, it’d be appreciated.



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

Nashorn + Spring Boot; help appreciated

[Attila Szegedi]

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

Standalone Nashorn 15.0 is out!

[Attila Szegedi]

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?

[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

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:
>>>> 
>>>> <https://github.com/openjdk/nashorn/pull/3>
>>>> 
>>>> 
>>>> 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 repo

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 
<https://www.dropbox.com/s/pfiq6z8d4g0hrq1/nashorn-core-15.0.jar>

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:
> 
> <https://github.com/openjdk/nashorn/pull/3>
> 
> 
> 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, kee

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:

<https://github.com/openjdk/nashorn/pull/3>


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

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 yo

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+

[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 

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<mailto: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<mailto: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+

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

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

[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/ 
> <https://openjdk.java.net/projects/nashorn/> 
> [2] https://github.com/newren/git-filter-repo 
> <https://github.com/newren/git-filter-repo> 
> [3] 
> https://docs.oracle.com/en/java/javase/14/docs/api/jdk.scripting.nashorn/module-summary.html
>  
> <https://docs.oracle.com/en/java/javase/14/docs/api/jdk.scripting.nashorn/module-summary.html>
>  
>  
> 

Standalone Nashorn is coming for Java 15+

[Attila Szegedi]

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

[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 <http://openjdk.java.net/jeps/174>
> [2] https://www.infoworld.com/article/2077746/javafx-compiler-released.html 
> <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 <https://openjdk.java.net/jeps/372>
> [7] http://openjdk.java.net/bylaws#project-lead 
> <https://openjdk.java.net/bylaws#project-lead>
> [8] https://github.com/szegedi
> [9] https://openjdk.java.net/jeps/276 <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: 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

Re: RFR: 8230766: Changed message in IllegalMonitorStateException

[Attila Szegedi]

+1

> On 2019. Sep 9., at 16:41, Hannes Wallnöfer  
> wrote:
> 
> Please review this fix for a test failing because of a changed exception 
> message in java.lang.Object.wait():
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8230766
> Webrev: http://cr.openjdk.java.net/~hannesw/8230766/webrev.00/
> 
> Thanks,
> Hannes

Re: RFR: Update double-conversion to version 3.1.5

[Attila Szegedi]

+1. This is really a refreshingly small change :-)

Attila.

> On 2019. Jul 9., at 15:23, Hannes Wallnöfer  
> wrote:
> 
> Please review the update of the Java port of the V8 double conversion library 
> to the most recent release.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8227391
> Webrev: http://cr.openjdk.java.net/~hannesw/8227391/webrev.00/
> 
> Although the commit log between the two releases is very long [1] (I’m not 
> sure the list is totally accurate since they are on different branches) the 
> actual changes to the code are quite limited. The majority of changes either 
> pertains to the code layout, build system, or are C++ specific and do not 
> apply to the Java port. In the end it amounts to two fixes plus tests along 
> with some code cleanup.
> 
> [1]: https://github.com/google/double-conversion/compare/57b1e09...5fa81e8
> 
> This will go into 13 or 14, depending on whether the late enhancement is 
> allowed.
> 
> Thanks,
> Hannes

Re: RFR: 8214795: Add safety check to dynalink inner class lookup

[Attila Szegedi]

+1

> On 2018. Dec 5., at 15:33, Hannes Wallnöfer  
> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8214795
> Webrev: http://cr.openjdk.java.net/~hannesw/8214795/webrev.00/
> 
> This is to make sure we use the right inner classes regardless of the order 
> of classes returned by Class.getClasses().
> 
> Thanks,
> Hannes

Re: RFR: 8214795: Add safety check to dynalink inner class lookup

[Attila Szegedi]

This code is ultimately invoked from BeanLinker constructor, so always on a 
single thread; there’s no race here. putIfAbsent was used here previously 
solely for its effect of not replacing existing mappings, not because of its 
atomicity.

Attila.

> On 2018. Dec 5., at 15:45, Jim Laskey  wrote:
> 
> Wouldn’t you still use innerClasses.putIfAbsent in case there is a race?
> 
>> On Dec 5, 2018, at 10:33 AM, Hannes Wallnöfer  
>> wrote:
>> 
>> Please review:
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214795
>> Webrev: http://cr.openjdk.java.net/~hannesw/8214795/webrev.00/
>> 
>> This is to make sure we use the right inner classes regardless of the order 
>> of classes returned by Class.getClasses().
>> 
>> Thanks,
>> Hannes
> 

Re: RFR: 8210943: Hiding of inner classes not resolved properly

[Attila Szegedi]

Huh… so even within the single array returned from a single call to 
Classes.getClasses() we can have two classes of the same short name? I 
foolishly presumed this wouldn’t be the case. I guess in this case the full 
solution would indeed to provide an ordering on the classes, first on the name, 
then on whether one’s declaring class is a subclass of the other (I guess the 
number of superclasses is also a good proxy for that.)

Attila.

> On 2018. Dec 1., at 19:12, Hannes Wallnöfer  
> wrote:
> 
> Attila, the subclass-to-superclass traversal is actually not done in dynalink 
> but directly in java.lang.Class.getClasses(). So Sundar has a point in that 
> my code relies on implementation rather than specified behaviour of 
> Class.getClasses().
> 
> Now I do think it is highly unlikely that the order of classes returned by 
> Classes.getClasses() would change in a future release. That would certainly 
> break a lot of other code. Furthermore, if the order was reversed 
> (superclasses to subclasses) that change would be caught by the test. The 
> only change that could go unnoticed would be classes returned in random 
> order, which I don’t think is a real concern. But of course we could choose 
> to be defensive and add code that guards against it.
> 
> Hannes
> 
> 
>> Am 01.12.2018 um 13:05 schrieb Attila Szegedi :
>> 
>> The relevant Dynalink algorithm processes the class before moving on to 
>> superclass, so Hannes fix is correct in that we won’t stomp over a subclass’ 
>> inner class (inserted into the map earlier) with the superclass’ inner class 
>> (encountered later by the algorithm). So yeah, getClasses() doesn’t specify 
>> an order, but the Dynalink code has a subclass-towards-superclass traversal 
>> order.
>> 
>> Attila.
>> 
>>> On 2018. Dec 1., at 7:13, Sundararajan Athijegannathan 
>>>  wrote:
>>> 
>>> Class.getClasses() javadoc does not mention anything about order of classes 
>>> returned.
>>> 
>>> https://docs.oracle.com/javase/10/docs/api/java/lang/Class.html#getClasses()
>>> 
>>> Do we need a check using Class.getDeclaringClass() or do I something here?
>>> 
>>> Thanks,
>>> -Sundar
>>> 
>>> On 30/11/18, 4:44 PM, Attila Szegedi wrote:
>>>> +1. Thanks for fixing this.
>>>> 
>>>>> On 2018. Nov 29., at 18:01, Hannes 
>>>>> Wallnöfer  wrote:
>>>>> 
>>>>> Please review:
>>>>> 
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210943
>>>>> Webrev: http://cr.openjdk.java.net/~hannesw/8210943/webrev.00/
>>>>> 
>>>>> AccessibleMembersLookup#lookupAccessibleMembers adds all nested classes 
>>>>> returned by Class.getClasses(), but these may contain inherited classes 
>>>>> that are shadowed and thus not visible from the current class. The 
>>>>> solution is to make sure we use the first inner class with any given name.
>>>>> 
>>>>> Thanks,
>>>>> Hannes
>> 
> 

Re: RFR: 8210943: Hiding of inner classes not resolved properly

[Attila Szegedi]

The relevant Dynalink algorithm processes the class before moving on to 
superclass, so Hannes fix is correct in that we won’t stomp over a subclass’ 
inner class (inserted into the map earlier) with the superclass’ inner class 
(encountered later by the algorithm). So yeah, getClasses() doesn’t specify an 
order, but the Dynalink code has a subclass-towards-superclass traversal order.

Attila.

> On 2018. Dec 1., at 7:13, Sundararajan Athijegannathan 
>  wrote:
> 
> Class.getClasses() javadoc does not mention anything about order of classes 
> returned.
> 
> https://docs.oracle.com/javase/10/docs/api/java/lang/Class.html#getClasses()
> 
> Do we need a check using Class.getDeclaringClass() or do I something here?
> 
> Thanks,
> -Sundar
> 
> On 30/11/18, 4:44 PM, Attila Szegedi wrote:
>> +1. Thanks for fixing this.
>> 
>>> On 2018. Nov 29., at 18:01, Hannes Wallnöfer  
>>> wrote:
>>> 
>>> Please review:
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210943
>>> Webrev: http://cr.openjdk.java.net/~hannesw/8210943/webrev.00/
>>> 
>>> AccessibleMembersLookup#lookupAccessibleMembers adds all nested classes 
>>> returned by Class.getClasses(), but these may contain inherited classes 
>>> that are shadowed and thus not visible from the current class. The solution 
>>> is to make sure we use the first inner class with any given name.
>>> 
>>> Thanks,
>>> Hannes

Re: RFR: 8214525: Bit rot in Nashorn Ant script

[Attila Szegedi]

+1


> On 2018. Nov 30., at 11:58, Hannes Wallnöfer  
> wrote:
> 
> Please review: 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8214525
> Webrev: http://cr.openjdk.java.net/~hannesw/8214525/webrev.00/
> 
> This enables gzip encoding for the YUI download and switches javadoc tasks to 
> modularized version of -linkoffline.
> 
> Thanks,
> Hannes

Re: RFR: 8210943: Hiding of inner classes not resolved properly

[Attila Szegedi]

+1. Thanks for fixing this.

> On 2018. Nov 29., at 18:01, Hannes Wallnöfer  
> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210943
> Webrev: http://cr.openjdk.java.net/~hannesw/8210943/webrev.00/
> 
> AccessibleMembersLookup#lookupAccessibleMembers adds all nested classes 
> returned by Class.getClasses(), but these may contain inherited classes that 
> are shadowed and thus not visible from the current class. The solution is to 
> make sure we use the first inner class with any given name.
> 
> Thanks,
> Hannes

Re: Nashorn deprecation

[Attila Szegedi]

Subscribe first, then go to that mailing list archive link, and click on the 
message author link (first link on the top of the page). It’s actually a 
mailto: link that should open your mail client with an empty e-mail message 
accordingly configured as a thread response.

Attila.

> On 2018. Jun 11., at 23:26, Jesus Luzon  wrote:
> 
> Is there any way to reply to a thread before I was subscribed? I'm pretty 
> much a noob when it comes to this mailing list process.
> 
> As for the deprecation, we use Nashorn heavily for our Edge transformation 
> layers and would need to find something that's at least backwards compatible 
> with our use case. Our use case is actually quite simple so I think it would 
> be easy to get functionality again, but would rather find something that will 
> last more than a few years without heavy maintenance.
> 
> On Mon, Jun 11, 2018 at 1:56 PM, Attila Szegedi  <mailto:szege...@gmail.com>> wrote:
> Hey folks,
> 
> the best thing you can do is answer to this thread on jdk-dev mailing list: 
> <http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001338.html 
> <http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001338.html>>. The 
> JEP is a candidate, and they’re gathering feedback there. If there’s a lot of 
> community feedback saying people use and depend on Nashorn, it’ll be taken 
> into consideration. Lots of people have already chimed in on that thread 
> already saying they rely on Nashorn. If you can re-post your below messages 
> in that thread, it’d be the best. If you are not subscribed to jdk-dev, you 
> can do so at <http://mail.openjdk.java.net/mailman/listinfo/jdk-dev 
> <http://mail.openjdk.java.net/mailman/listinfo/jdk-dev>>.
> 
> Paulo, your specific experience of already having tried to replace Nashorn 
> with GraalVM.js might be particularly significant.
> 
> Best regards,
>   Attila.
> 
> 
> > On 2018. Jun 11., at 21:35, Paulo Lopes  > <mailto:pmart...@redhat.com>> wrote:
> > 
> > Hi,
> > As the "core" developer of JS support for Vert.x this is quite some
> > shocking news as the project really relies on Nashorn for JS support.
> > I've been spending many hours to get GraalVM.js working and to some
> > extent we can run some unmodified application with it, but we're not
> > there yet. For example Nashorn dynalink and Multi threading support are
> > not there yet.
> > It would be nice to hear what's the ETA for the removal, will project
> > Detroit provide a JS script engine (ala Nashorn and will it be
> > available as a replacement?)...
> > Cheers,Paulo
> > On Mon, 2018-06-11 at 14:50 -0300, João Paulo Varandas wrote:
> >> Hello Yikes. Well pointed... that is a drag indeed.
> >> Any news on those questions?
> >> 
> >> We are completely reliant to this feature in our platform, a lot
> >> ofsoftware customization is made using ECMAScript and runs on top
> >> ofNashorn/JDK8 currently. I was surprised and scared when I saw
> >> that.Hopefully, Jim will bring us good news.
> >> 
> >> 
> >> 
> >> 
> >> 
> >> On Thu, Jun 7, 2018 at 9:31 AM, yikes aroni  >> <mailto:yikesar...@gmail.com>>
> >> wrote:
> >> Hi i just read that Nashorn is being deprecated (JEP 335<http://openj 
> >> <http://openj/>
> >> dk.java.net/jeps/335 <http://dk.java.net/jeps/335>>). First of all, that 
> >> is a drag. Two(ish)
> >> questions:
> >> 1) So what is the last planned release of Nashorn? J9? It wasnt'
> >> clear fromthe JEP.
> >> 2) Is this deprecation specifically to make room for GraalJS? That
> >> is, isit the Oracle plan to sideline Nashorn and push forward GraalJS
> >> afully-supported, not-just-for-research GraalJS?
> >> Thanks. Important stuff to know for planning for projects dependent
> >> onNashorn / JS support in the JVM!
> >> 
> >> 
> 
> 

Re: Nashorn deprecation

[Attila Szegedi]

Hey folks,

the best thing you can do is answer to this thread on jdk-dev mailing list: 
. The JEP 
is a candidate, and they’re gathering feedback there. If there’s a lot of 
community feedback saying people use and depend on Nashorn, it’ll be taken into 
consideration. Lots of people have already chimed in on that thread already 
saying they rely on Nashorn. If you can re-post your below messages in that 
thread, it’d be the best. If you are not subscribed to jdk-dev, you can do so 
at .

Paulo, your specific experience of already having tried to replace Nashorn with 
GraalVM.js might be particularly significant.

Best regards,
  Attila.


> On 2018. Jun 11., at 21:35, Paulo Lopes  wrote:
> 
> Hi,
> As the "core" developer of JS support for Vert.x this is quite some
> shocking news as the project really relies on Nashorn for JS support.
> I've been spending many hours to get GraalVM.js working and to some
> extent we can run some unmodified application with it, but we're not
> there yet. For example Nashorn dynalink and Multi threading support are
> not there yet.
> It would be nice to hear what's the ETA for the removal, will project
> Detroit provide a JS script engine (ala Nashorn and will it be
> available as a replacement?)...
> Cheers,Paulo
> On Mon, 2018-06-11 at 14:50 -0300, João Paulo Varandas wrote:
>> Hello Yikes. Well pointed... that is a drag indeed.
>> Any news on those questions?
>> 
>> We are completely reliant to this feature in our platform, a lot
>> ofsoftware customization is made using ECMAScript and runs on top
>> ofNashorn/JDK8 currently. I was surprised and scared when I saw
>> that.Hopefully, Jim will bring us good news.
>> 
>> 
>> 
>> 
>> 
>> On Thu, Jun 7, 2018 at 9:31 AM, yikes aroni 
>> wrote:
>> Hi i just read that Nashorn is being deprecated (JEP 335> dk.java.net/jeps/335>). First of all, that is a drag. Two(ish)
>> questions:
>> 1) So what is the last planned release of Nashorn? J9? It wasnt'
>> clear fromthe JEP.
>> 2) Is this deprecation specifically to make room for GraalJS? That
>> is, isit the Oracle plan to sideline Nashorn and push forward GraalJS
>> afully-supported, not-just-for-research GraalJS?
>> Thanks. Important stuff to know for planning for projects dependent
>> onNashorn / JS support in the JVM!
>> 
>> 

Re: Nashorn StackOverflowError

[Attila Szegedi]

This is because the parser is recursively processing the if-else branches. This 
is one huge if statement. It's basically equivalent to

if (true) { 
  print(x);
} else { 
  if (true) { 
print(x);
  } else {
if (true) {
  print(x);
} else {
  …
}
  }

so the parser code eventually exhausts the call stack. Try increasing -Xss 
setting on the JVM.

> On 2018. May 30., at 8:01, Richard Tolbert  wrote:
> 
> Nashorn throws a StackOverflowError if there are a few hundred if else
> statements in a function.
> 
> 
> function whyDoesThisThrowStackOverflowError(x) {
>  if (true) { print(x); }
>  else if (true) { print(x); }
>  else if (true) { print(x); }
>  else if (true) { print(x); }
>  else if (true) { print(x); }
>  else if (true) { print(x); }
>  else if (true) { print(x); }
>  else if (true) { print(x); }
>  else if (true) { print(x); }
>  else if (true) { print(x); }
> 
>  else if (true) { print(x); }
> }
> 
> whyDoesThisThrowStackOverflowError(1);
> 
> 
> java.lang.StackOverflowError
>at jdk.nashorn.internal.parser.Lexer.valueOfIdent(Lexer.java:756)
>at jdk.nashorn.internal.parser.Lexer.getValueOf(Lexer.java:1661)
>at
> jdk.nashorn.internal.parser.AbstractParser.getValue(AbstractParser.java:391)
>at
> jdk.nashorn.internal.parser.AbstractParser.getValue(AbstractParser.java:379)
>at
> jdk.nashorn.internal.parser.AbstractParser.expectValue(AbstractParser.java:366)
>at
> jdk.nashorn.internal.parser.AbstractParser.getIdent(AbstractParser.java:431)
>at
> jdk.nashorn.internal.parser.Parser.primaryExpression(Parser.java:1956)
>at jdk.nashorn.internal.parser.Parser.memberExpression(Parser.java:2511)
>at
> jdk.nashorn.internal.parser.Parser.leftHandSideExpression(Parser.java:2372)
>at jdk.nashorn.internal.parser.Parser.unaryExpression(Parser.java:3147)
>at
> jdk.nashorn.internal.parser.Parser.assignmentExpression(Parser.java:3353)
>at jdk.nashorn.internal.parser.Parser.argumentList(Parser.java:2588)
>at
> jdk.nashorn.internal.parser.Parser.leftHandSideExpression(Parser.java:2375)
>at jdk.nashorn.internal.parser.Parser.unaryExpression(Parser.java:3147)
>at jdk.nashorn.internal.parser.Parser.expression(Parser.java:3282)
>at
> jdk.nashorn.internal.parser.Parser.expressionStatement(Parser.java:1150)
>at jdk.nashorn.internal.parser.Parser.statement(Parser.java:967)
>at jdk.nashorn.internal.parser.Parser.statement(Parser.java:863)
>at jdk.nashorn.internal.parser.Parser.statementList(Parser.java:1013)
>at jdk.nashorn.internal.parser.Parser.getBlock(Parser.java:531)
>at jdk.nashorn.internal.parser.Parser.getStatement(Parser.java:555)
>at jdk.nashorn.internal.parser.Parser.ifStatement(Parser.java:1187)
>at jdk.nashorn.internal.parser.Parser.statement(Parser.java:890)
>at jdk.nashorn.internal.parser.Parser.getStatement(Parser.java:560)
>at jdk.nashorn.internal.parser.Parser.ifStatement(Parser.java:1192)
>at jdk.nashorn.internal.parser.Parser.statement(Parser.java:890)
>at jdk.nashorn.internal.parser.Parser.getStatement(Parser.java:560)
>at jdk.nashorn.internal.parser.Parser.ifStatement(Parser.java:1192)
>at jdk.nashorn.internal.parser.Parser.statement(Parser.java:890)
>at jdk.nashorn.internal.parser.Parser.getStatement(Parser.java:560)
>at jdk.nashorn.internal.parser.Parser.ifStatement(Parser.java:1192)
>at jdk.nashorn.internal.parser.Parser.statement(Parser.java:890)
>at jdk.nashorn.internal.parser.Parser.getStatement(Parser.java:560)
>at jdk.nashorn.internal.parser.Parser.ifStatement(Parser.java:1192)
>at jdk.nashorn.internal.parser.Parser.statement(Parser.java:890)
>at jdk.nashorn.internal.parser.Parser.getStatement(Parser.java:560)
>at jdk.nashorn.internal.parser.Parser.ifStatement(Parser.java:1192)
>at jdk.nashorn.internal.parser.Parser.statement(Parser.java:890)
>at jdk.nashorn.internal.parser.Parser.getStatement(Parser.java:560)
>at jdk.nashorn.internal.parser.Parser.ifStatement(Parser.java:1192)
> 

Re: Is there a way to reference the engine from a linker?

[Attila Szegedi]

Oh, good one. Yes, I think that’ll do. It engages Nashorn’s built-in linker 
chain to find an appropriate conversion.

Attila.

> On 2018. Apr 4., at 19:28, Paulo Lopes  wrote:
> 
> Hi,
> 
> I've worked around it by using:
> 
> 
> ScriptUtils.convert(obj, Map.class)
> 
> 
> When ever I needed to get a script object as a map or replacing the class 
> with List.class when I need a list...
> 
> Is that a safe way to do it?
> 
> 
>   Original Message  
> From: szege...@gmail.com
> Sent: April 4, 2018 7:21 PM
> To: plo...@redhat.com
> Cc: nashorn-dev@openjdk.java.net
> Subject: Re: Is there a way to reference the engine from a linker?
> 
> Sorry for an awfully late response, but hope it might still help: 
> Java.asJSONCompatible delegates on the Java side to 
> jdk.nashorn.api.scripting.wrapAsJSONCompatible. It’s part of Nashorn’s 
> supported public API, so it should be fine for you to call it.
> 
> I’m actually wondering how useful is that API method - you need to pass a 
> “homeGlobal” parameter, and honestly I’m not really sure how you’d obtain 
> that. Maybe Sundar has an idea.
> 
> Attila.
> 
>> On 2018. Mar 15., at 20:02, Paulo Lopes  wrote:
>> 
>> Hi,
>> 
>> I'm writing a guarded linker to allow custom casting from JSObject to Vertx
>> custom types. So far so good, the basic tests seem to work but I think I'm
>> writing too much boiler plate code as I need in many times to have an
>> intermediate conversion from JSObject to Map or List.
>> 
>> So I know that in the engine I could call Java.asJSONCompatible() but I
>> don't see how I could get a reference to the engine in the linker.
>> 
>> Could anyone see a way or let me know if there is a open API to do this?
>> 
>> Thanks!
>> Paulo
> 

Re: Is there a way to reference the engine from a linker?

[Attila Szegedi]

Sorry for an awfully late response, but hope it might still help: 
Java.asJSONCompatible delegates on the Java side to 
jdk.nashorn.api.scripting.wrapAsJSONCompatible. It’s part of Nashorn’s 
supported public API, so it should be fine for you to call it.

I’m actually wondering how useful is that API method - you need to pass a 
“homeGlobal” parameter, and honestly I’m not really sure how you’d obtain that. 
Maybe Sundar has an idea.

Attila.

> On 2018. Mar 15., at 20:02, Paulo Lopes  wrote:
> 
> Hi,
> 
> I'm writing a guarded linker to allow custom casting from JSObject to Vertx
> custom types. So far so good, the basic tests seem to work but I think I'm
> writing too much boiler plate code as I need in many times to have an
> intermediate conversion from JSObject to Map or List.
> 
> So I know that in the engine I could call Java.asJSONCompatible() but I
> don't see how I could get a reference to the engine in the linker.
> 
> Could anyone see a way or let me know if there is a open API to do this?
> 
> Thanks!
> Paulo

Re: RFR 8200215: 17th loop of "let foo = ''"; throws ReferenceError

[Attila Szegedi]

+1


> On 2018. Mar 26., at 15:27, Sundararajan Athijegannathan 
>  wrote:
> 
> Updated: http://cr.openjdk.java.net/~sundar/8200215/webrev.01/
> 
> Please review.
> 
> -Sundar
> 
> On 26/03/18, 6:03 PM, Hannes Wallnöfer wrote:
>> The new ScriptObject.declareAndSet method is almost identical, so the 
>> existing one could be rewritten to make use of the new one.
>> 
>> Otherwise looks good.
>> 
>> Hannes
>> 
>> 
>>> Am 26.03.2018 um 14:00 schrieb Sundararajan 
>>> Athijegannathan:
>>> 
>>> Please review http://cr.openjdk.java.net/~sundar/8200215/webrev.00/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200215
>>> 
>>> Thanks,
>>> -Sundar

Re: Field Method Conflicts

[Attila Szegedi]

No, there isn’t really. Nashorn (well, actually Dynalink that’s underlying 
Nashorn’s Java-binding functionality) gives preference to a method over a field 
as methods are more flexible, can include preconditions, can be overridden etc. 
There’s an assumption that whoever designs the class with both a field and a 
method sharing their name (or method name conforming to getter convention for 
the property) would consider the method to be more specific.

Attila.

> On 2018. Jan 19., at 10:31, Nathan Faulkner  wrote:
> 
> Is there any way, other than reflection, to access a field that shares a
> name with a method? It seems that, with the Test class,  instance.item
> returns the item() dynamic method (as does instance["item"]), and
> instance.item2 returns "b".
> 
> public class Test {
>  public String item = "1";
>  public String item2 = "2";
> 
>  public String item() {
>return "a";
>  }
> 
>  public String getItem2() {
>return "b";
>  }
> }
> 
> 
> Thanks,
> Nathan Faulkner

Re: RFR: 8195123: Very large regressions in Octane benchmarks using 10-b39

[Attila Szegedi]

+1

> On 2018. Jan 17., at 16:43, Jim Laskey  wrote:
> 
> +1
> 
> 
>> On Jan 17, 2018, at 11:36 AM, Hannes Wallnöfer 
>>  wrote:
>> 
>> Please review: 
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8195123
>> Webrev: http://cr.openjdk.java.net/~hannesw/8195123/webrev.00/
>> 
>> This undoes the recent fix for JDK-8193567 (Attila, in case you’re reading, 
>> I should have taken your doubts more serously) and replaces it with a 
>> different fix.
>> 
>> Instead of disabling optimistic types within comparison nodes, the new fix  
>> avoids the shortcuts for null and undefined comparison if the compared 
>> expression contains an optimistic expression. Previously we only checked 
>> whether the expression itself was optimistic or contained the expression 
>> that triggered the current rest-of compilation. It’s easy to see why we must 
>> avoid it also for nested optimistic expressions, as they can trigger 
>> deoptimization as well. 
>> 
>> In my testing, this fixes the performance regression.
>> 
>> Hannes
> 

Re: RFR [11]: 8194985: JavaAdapterBytecodeGenerator passes invalid type descriptor to ASM

[Attila Szegedi]

+1

That’s a weird thing to make stricter. I guess in anticipation of value types 
which will use something other than L it can’t just substitute L anymore for 
anything that’s not a known primitive type name.

Attila.

> On 2018. Jan 12., at 11:08, Sundararajan Athijegannathan 
>  wrote:
> 
> +1
> 
> -Sundar
> 
> On 12/01/18, 2:56 PM, Hannes Wallnöfer wrote:
>> Please review:
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8194985
>> Webrev: http://cr.openjdk.java.net/~hannesw/8194985/webrev.00/
>> 
>> Thanks,
>> Hannes

Re: RFR:8157251:BeanLinker relinks array length operations for array types

[Attila Szegedi]

On Jan 10, 2018, at 2:32 PM, Hannes Wallnöfer <hannes.wallnoe...@oracle.com> 
wrote:
> 
> Priya, 
> 
> The problem with your solution that using an object array invocation with a 
> primitive array will throw a ClassCastException as it passes the isArray 
> guard.
> 
> On the other hand, the problem with instanceof validation in Attila’s snippet 
> is that it uses the concrete callsite type (e.g. String[]) instead of 
> Object[]. What we’d need is a guard with an instanceof Object[] check. 

Yeah, my solution wasn’t complete by any means, it just wanted to be a pointer 
in the right direction. Priya’s change to use IS_ARRAY *almost* worked, except 
for, as you noticed, primitive arrays.

FWIW, since IS_ARRAY isn’t actually used for anything else (the JIRA ticket 
allures to it getting retired), we could replace it with a new 
IS_REFERENCE_ARRAY ValidationType (that basically describes an instanceof 
Object[] check) and then Priya and mine combined solution below would work with 
it. The only other place where a new ValidationType needs to be handled is in 
AbstractJavaLinker.getGuard and GuardedInvocationComponent.Validator.compose. 
Those would need some more adjustments (basically, replacing every 
"validatorClass.isArray()” expression with 
“Object[].class.isAssignableFrom(validatorClass)”.)

Of course, then on another look it seems to me that length properties for 
collections and maps will *also* have stricter linkage than necessary, since 
INSTANCE_OF validation type will always link an instanceof check for the linked 
class, and these properties could also have more lenient linkage, like how 
element getters and setters are stably linked for lists and maps in general. So 
I guess we might need to add an IS_COLLECTION and IS_MAP ValidationType too to 
use for these length getters :-)

It’s not a big deal adding validation types, they’re just encapsulations of 
guard logic that also know how to compose (they need to compose in unnamed 
getter linking logic… welcome to the nontrivial world of bean linking :-) ). It 
might be tempting to just override getPropertyGetter() instead and add special 
code for linking “length”, and that’d _mostly_ work; one advantage of using 
setPropertyGetter() is that those properties defined with setPropertyGetter() 
will be automatically found by call sites with unnamed access,  e.g. Nashorn 
pseudocode:

var propName = (function() { return “length” })()
arr[propName]

> However, I don’t think a callsite for array length will usually see so many 
> different array classes to go megamorphic, so I think both your solutions 
> (Priya’s webrev and Attila’s code snippet) are acceptable.

Yeah, I’m also fine with whichever solution. Committing the reversal to 
Array.getLength is fine too with me.

It might be a nice exercise though to add IS_REFERENCE_ARRAY, IS_COLLECTION, 
and IS_MAP ValidationTypes, and define the length getters for arrays, 
collections, and maps using them, with requisite adjustments to both 
AbstractJavaLinker.getGuard and GuardedInvocationComponent.Validator.compose.

Attila.

> 
> Hannes
> 
>> Am 10.01.2018 um 06:42 schrieb Priya Lakshmi Muthuswamy 
>> <priya.lakshmi.muthusw...@oracle.com>:
>> 
>> Hi Attila,
>> 
>> Thanks for the review. I just felt in the case of primitive types there will 
>> be relinking.
>> I tried with the below fix.
>> In the case object types, I see relinking when we use 
>> Validation.INSTANCE_OF. But works fine without relinking when we use 
>> Validation.IS_ARRAY
>> 
>> if(clazz.isArray()) {
>>   // Some languages won't have a notion of manipulating collections. 
>> Exposing "length" on arrays as an // explicit property is beneficial for 
>> them. if (clazz.getComponentType().isPrimitive()) {
>>   setPropertyGetter("length", MethodHandles.arrayLength(clazz), 
>> ValidationType.EXACT_CLASS);
>>   }else {
>>   setPropertyGetter("length", MethodHandles.arrayLength(Object[].class), 
>> ValidationType.IS_ARRAY);
>>   }
>> 
>> Thanks,
>> Priya
>> 
>> 
>> On 1/9/2018 7:51 PM, Attila Szegedi wrote:
>>> This effectively reverts the combined 
>>> <https://bugs.openjdk.java.net/browse/JDK-8157225> and 
>>> <https://bugs.openjdk.java.net/browse/JDK-8157250>.
>>> 
>>> That was not the intent of 8157251, though.
>>> 
>>> The intent of 8157251 was to use MethodHandles.arrayLength(Object[].class) 
>>> for all arrays with components of reference type (and use 
>>> ValidationType.INSTANCE_OF for it, as all such arrays will be instance-of 
>>> Object[] through instance-of semantics for array types) and leave the 
>>> linking of arrays with primitive component types as t

Re: Dynalink and delete

[Attila Szegedi]

I’d love to learn more about how you are using Nashorn and Dynalink for 
teaching, if you can spare a time for a short write-up.

Thanks,
  Attila.

> On 2017. Dec 22., at 0:16, Marc Downie <m...@openendedgroup.com> wrote:
> 
> 
> Attila,
> 
> Followed the reviews and commits with anticipation, pulling the changes and 
> building this evening. Assuming it all goes well, I'll have it in front of 
> students writing code in two weeks time. 
> 
> Many thanks!
> 
> Marc.
> 
> On Thu, Dec 21, 2017 at 2:59 PM, Attila Szegedi <szege...@gmail.com 
> <mailto:szege...@gmail.com>> wrote:
> Hi Marc,
> 
> So… this took about a year and a half to happen, but I’m happy to announce 
> that there’s now a REMOVE operation in Dynalink. The latest EA of JDK10 
> contains it: 
> <http://download.java.net/java/jdk10/docs/api/jdk/dynalink/StandardOperation.html#REMOVE
>  
> <http://download.java.net/java/jdk10/docs/api/jdk/dynalink/StandardOperation.html#REMOVE>>.
>  Hopefully you can still find a use for it :-)
> 
> What the latest EA doesn’t contain _yet_ is Nashorn using it to implement its 
> delete operator, so even if you link REMOVE in your language runtime, Nashorn 
> won’t be able to delete your object’s properties, and your language won’t be 
> able to delete Nashorn JS objects’ properties yet. The good news is that this 
> functionality is also implemented and committed, but I just committed it now, 
> so it will only ship with the next EA build. Alternatively, if you build your 
> own jdk10 from the tip of the jdk/jdk10 repository, or your own jdk11 from 
> the tip of jdk/jdk, you should have it.
> 
> Best Regards,
>   Attila.
> 
>> On May 24, 2016, at 12:11 AM, Marc Downie <m...@openendedgroup.com 
>> <mailto:m...@openendedgroup.com>> wrote:
>> 
>> Dear all,
>> 
>> First of all, many thanks for this year's JEP-276 / jdk.dynalink
>> refactoring. We've been enjoying all of the benefits of installing a custom
>> Linker without having to maintain a fork of Nashorn just to get it
>> installed. We can massage and customize the face that Java objects present
>> to JavaScript almost completely.
>> 
>> The one thing that remains that I can't manipulate is the behavior of Java
>> objects with respect to *delete*. In short we have elaborately customizable
>> *dyn:setProp*, *setElem*, *getProp*, *getElem* that we can bridge to other
>> languages and runtimes, but no *dyn:deleteX. *Is this by omission or by
>> design?
>> 
>> best,
>> 
>> Marc
> 
> 

Re: RFR: 8193567: Conversion of comparison nodes affects local slots in optimistic continuation

[Attila Szegedi]

A sad +1. I too wish this were easier to solve. Can you point me to the code 
parts that cause differences in local slot assignment? I guess I could try to 
figure it out myself from that terrible expression in the test, but if you have 
a quick explanation…

Thanks,
  Attila.

> On Dec 21, 2017, at 4:36 PM, Hannes Wallnöfer  
> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8193567
> Webrev: http://cr.openjdk.java.net/~hannesw/8193567/webrev.00/
> 
> I’ve tried finding a smaller fix like just tagging the child nodes of all 
> comparisons as non-optimistic, but that didn't fix the problem as those nodes 
> could still have optimistic children.
> 
> Hannes

Re: Review request for JDK-8193295: Remove no longer used COMMALEFT

[Attila Szegedi]

Yeah, JDK 11. There’s no visible changes, so it doesn’t really make sense 
pushing it into JDK 10.

> On Dec 21, 2017, at 9:37 PM, Hannes Wallnöfer <hannes.wallnoe...@oracle.com> 
> wrote:
> 
> Interesting. I bet the answer is in the commits from before we went open 
> source.
> 
> +1
> 
> I assume this is for JDK 11?
> 
> Hannes
> 
>> Am 21.12.2017 um 19:20 schrieb Attila Szegedi <szege...@gmail.com>:
>> 
>> Please review JDK-8193295 "Remove no longer used COMMALEFT" at 
>> <http://cr.openjdk.java.net/~attila/8193295/webrev.jdk> for 
>> <https://bugs.openjdk.java.net/browse/JDK-8193295>
>> 
>> I love deleting code :-)
>> 
>> COMMALEFT was an odd duck, as there’s not really anything in the ES 
>> specification that’d require it, and we really don’t even use it for 
>> anything. I had a memory that we used to use it for some behavior around 
>> object literals, but I can’t find any traces of that… I run:
>> 
>>  hg log --template "{ifcontains('COMMALEFT', diff(), '{node} {desc}\n', 
>> '')}”
>> 
>> and trawled through the diffs for all changesets it brought up, but I 
>> haven’t found a single use of COMMALEFT ever.
>> 
>> Thanks,
>> Attila.
> 

Re: Dynalink and delete

[Attila Szegedi]

Hi Marc,

So… this took about a year and a half to happen, but I’m happy to announce that 
there’s now a REMOVE operation in Dynalink. The latest EA of JDK10 contains it: 
>.
 Hopefully you can still find a use for it :-)

What the latest EA doesn’t contain _yet_ is Nashorn using it to implement its 
delete operator, so even if you link REMOVE in your language runtime, Nashorn 
won’t be able to delete your object’s properties, and your language won’t be 
able to delete Nashorn JS objects’ properties yet. The good news is that this 
functionality is also implemented and committed, but I just committed it now, 
so it will only ship with the next EA build. Alternatively, if you build your 
own jdk10 from the tip of the jdk/jdk10 repository, or your own jdk11 from the 
tip of jdk/jdk, you should have it.

Best Regards,
  Attila.

> On May 24, 2016, at 12:11 AM, Marc Downie  wrote:
> 
> Dear all,
> 
> First of all, many thanks for this year's JEP-276 / jdk.dynalink
> refactoring. We've been enjoying all of the benefits of installing a custom
> Linker without having to maintain a fork of Nashorn just to get it
> installed. We can massage and customize the face that Java objects present
> to JavaScript almost completely.
> 
> The one thing that remains that I can't manipulate is the behavior of Java
> objects with respect to *delete*. In short we have elaborately customizable
> *dyn:setProp*, *setElem*, *getProp*, *getElem* that we can bridge to other
> languages and runtimes, but no *dyn:deleteX. *Is this by omission or by
> design?
> 
> best,
> 
> Marc

Review request for JDK-8193295: Remove no longer used COMMALEFT

[Attila Szegedi]

Please review JDK-8193295 "Remove no longer used COMMALEFT" at 
 for 


I love deleting code :-)

COMMALEFT was an odd duck, as there’s not really anything in the ES 
specification that’d require it, and we really don’t even use it for anything. 
I had a memory that we used to use it for some behavior around object literals, 
but I can’t find any traces of that… I run:

hg log --template "{ifcontains('COMMALEFT', diff(), '{node} {desc}\n', 
'')}”

and trawled through the diffs for all changesets it brought up, but I haven’t 
found a single use of COMMALEFT ever.

Thanks,
  Attila.

Review request for JDK-8193371: Use Dynalink REMOVE operation in Nashorn

[Attila Szegedi]

Please review JDK-8193371 "Use Dynalink REMOVE operation in Nashorn" at 
 for 


It looks bigger than it is. let me quickly explain this change in detail:

There are some things that could make sense even if we didn’t refit delete 
operator on Dynalink REMOVE.

* Fist such thing is moving the evaluation logic for the delete operator from 
AssignSymbols into CodeGenerator. That way, we eliminated a need to carry 
information from AS to CG in a RuntimeNode, and we could retire all of DELETE, 
SLOW_DELETE, and FAIL_DELETE RuntimeNode enums. It also allowed us to have 
cleaner expression of the code generator, e.g strict flag is handled more 
elegantly when deleting an IdentNode, and also we can just emit invocation of 
ScriptObject.delete on the scope object for IdentNode removals. There’s overall 
stronger typing (e.g. slow delete implementation has a better signature).

* By not erasing “delete” UnaryNodes in AssignSymbols anymore, I had to take a 
bit of special care in LocalVariableTypesCalculator to not treat deletes of 
IdentNodes as uses.

* The changes in control flow of AbstractJavaLinker and BeanLinker 
getGuardedInvocationComponent are actual bug fixes that became apparent to me 
when I realized while writing the tests that the code as it was was failing to 
link REMOVE:PROPERTY|ELEMENT; it was incorrectly not trying all the namespaces 
it should’ve. (The bug was more generic than just that one operation 
combination: it’d affect e.g. SET:METHOD|PROPERTY too and some other 
combinations).

As for actual delete operator through Dynalink:

* MethodEmitter gained methods for emitting dynamic call sites for removal. 
Those are very similar to existing ones for dynamic getters and setters, 
nothing special there.

* The logic formerly in ScriptRuntime.DELETE has now been spread into relevant 
linkers: ScriptObject.lookup, JSObjectLinker, Undefined.lookup, and 
NashornBottomLinker. The case in ScriptRuntime.DELETE for “if 
(JSType.isPrimitive(obj))” doesn’t even have to be handled separately, 
primitive linking that instantiates wrappers takes care nicely of it.

* That said, ScriptRuntime.DELETE had a final “return true” fallback for POJOs, 
and I decided to improve on it. For one thing, theres an automatic improvement 
because delete now works as expected on Java lists and maps just by virtue of 
Dynalink providing that functionality. Another improvement that I decided to 
introduce manually is found in the way NashornBottomLinker handles delete on 
POJOs, specifically the uses of isNonConfigurableProperty. I tried treating all 
properties and methods of POJOs as if they were non-configurable properties (we 
try to treat them like that elsewhere in the code as well), so attempts to 
delete them will return false (non-strict) or throw a TypeError (strict), in 
accordance with ES 8.12.7 [[Delete]]. The newly added test file tries to 
exercise all new behavior.

* Finally, NashornCallSiteDescriptor now needs 4 bits for the operation as we 
went from 8 operations to 10 with “delete obj.name” and “delete obj[index]". 
This again halved the number of program points available to 131072, but that's 
fortunately still about 10x what is really needed, so we should be good.

Thanks,
  Attila.

Re: Review request for JDK-8193296: Parser should not eagerly transform delete expressions

[Attila Szegedi]

I updated the webrev with @bug and @summary in the tests: 
<http://cr.openjdk.java.net/~attila/8193296/webrev.02.jdk> 

Attila.

> On Dec 11, 2017, at 6:26 PM, Sundararajan Athijegannathan 
> <sundararajan.athijegannat...@oracle.com> wrote:
> 
> Hi,
> 
> 1) @bug and @summary are for documentation purpose - explain what the test is 
> all about (without having to look at JIRA...)
> 
> 2) @modules is needed only if you want to add module exports for internal 
> packages from other modules to your test (equivalent to --add-exports in java 
> command line). That is not needed in this case (because you use only exported 
> API packages from jdk.dynalink module).
> 
> -Sundar
> 
> On 11/12/17, 4:55 PM, Attila Szegedi wrote:
>> Thanks!
>> 
>> I admittedly cribbed the various @tags from the neighboring JDK_8188098_Test 
>> class :-). I take it “@run testng …” is meaningful and understood by jtreg 
>> then, so I can leave that as it is? I tried to find other examples and 
>> stumbled upon e.g. JDK_8184723_Test which specifies “@run main/othervm” and 
>> also declares “@modules” - is that something I should be doing as well, and 
>> can you advice what would be the correct values?
>> 
>> Attila.
>> 
>> 
>>> On Dec 11, 2017, at 8:18 AM, Sundararajan 
>>> Athijegannathan<sundararajan.athijegannat...@oracle.com>  wrote:
>>> 
>>> * Test misses copyright comment
>>> * you may want to add @bug  and @summary line in jtreg comment 
>>> section
>>> 
>>> Other than that, +1
>>> 
>>> -Sundar
>>> 
>>> On 10/12/17, 9:52 PM, Attila Szegedi wrote:
>>>> Please review JDK-8193296 "Parser should not eagerly transform delete 
>>>> expressions" 
>>>> at<http://cr.openjdk.java.net/~attila/8193296/webrev.jdk<http://cr.openjdk.java.net/~attila/8193296/webrev.jdk>>
>>>>
>>>> for<https://bugs.openjdk.java.net/browse/JDK-8193296<https://bugs.openjdk.java.net/browse/JDK-8193296>>
>>>> 
>>>> Thanks,
>>>>  Attila.
>>>> 

Re: RFR:8191301:JavaImporter fails to resolve imported elements within functions, that contain too many statements

[Attila Szegedi]

Excellent! 

+1

Attila.

> On 2017. Dec 13., at 4:42, Priya Lakshmi Muthuswamy 
> <priya.lakshmi.muthusw...@oracle.com> wrote:
> 
> Thanks Attila, I have modified the patch
> 
> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.03/ 
> <http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.03/>Thanks,
> Priya
> On 12/13/2017 12:57 AM, Attila Szegedi wrote:
>> This is generally acceptable, and while I really don’t want to be a pain, 
>> I’ll point out few minor things still, because I really want this code to be 
>> the best it can be :-)
>> 
>> - in Nashorn code (and OpenJDK in general), we format “else” and “else if” 
>> to be on the same line as the closing brace of the previous block, so :
>> 
>> if (…) {
>> …
>> } else if (…) {
>>…
>> } else {
>>…
>> }
>> 
>> - in Nashorn, we declare all method parameters to be final.
>> 
>> - We strongly prefer final local variables with single-assignment whenever 
>> possible, so instead of early-initializing “expression" to null in 
>> getJavaImporter and then overwriting it, the preferred style would be:
>> 
>> final NativeJavaImporter expression;
>> if (self instanceof NativeJavaImporter) {
>> expression = (NativeJavaImporter)self;
>> } else if (self instanceof ScriptObject) {
>> expression = getJavaImporterInScope((ScriptObject)self);
>> } else {
>> expression = null;
>> }
>> return expression;
>> 
>> The compiler will prove that a final variable is assigned exactly once on 
>> each branch. This code is fairly simple so it might not matter much, but 
>> it’s good to adopt this style of coding as it lets the compiler help you 
>> ensure you didn’t forget to initialize the variable on any path. Sometimes 
>> the early-initialization value, in this case null, wouldn’t be valid in all 
>> cases and by providing it early, you paper over all the missing cases and 
>> the compiler can’t tell if you overlooked something. On the other hand, if 
>> you declare the variable as final, it’ll report a compilation error if the 
>> variable is not initialized on every possible path.
>> 
>> Alternatively, you could even do away with expression completely, and just 
>> use early return statements like this:
>> 
>> if (self instanceof NativeJavaImporter) {
>> return (NativeJavaImporter)self;
>> }
>> if (self instanceof ScriptObject) {
>> return getJavaImporterInScope((ScriptObject)self);
>> }
>> return null;
>> 
>> but I don’t consider that to be more valid than the above version with 
>> "final NativeJavaImporter expression”; they’re pretty much equivalent, 
>> albeit this last one is slightly shorter.
>> 
>> Attila.
>> 
>>> On 2017. Dec 12., at 18:31, Priya Lakshmi Muthuswamy 
>>> <priya.lakshmi.muthusw...@oracle.com 
>>> <mailto:priya.lakshmi.muthusw...@oracle.com>> wrote:
>>> 
>>> Hi Attila,
>>> 
>>> I have modified the patch with your suggestions.
>>> 
>>> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.02/ 
>>> <http://cr.openjdk.java.net/%7Epmuthuswamy/8191301/webrev.02/>
>>> 
>>> Thanks,
>>> Priya
>>> 
>>> On 12/12/2017 8:49 PM, Attila Szegedi wrote:
>>>> Hi Priya,
>>>> 
>>>> This indeed looks much better, although I do have some remarks with regard 
>>>> to the the style of the code. Specifically, repetitions of identical code, 
>>>> as well as assignments inside predicates.
>>>> 
>>>> There are several cases of code that is repeating:
>>>> First is:
>>>> 
>>>> ((NativeJavaImporter)...).createProperty(JSType.toString(name))
>>>> 
>>>> Which occurs twice. You can avoid this by creating a “private static 
>>>> NativeJavaImporter getJavaImporter(Object self)” method that either 
>>>> returns self or does the lookup in scope, finally throws the type error if 
>>>> it found nothing. Then __noSuchProperty__ can be simply written as:
>>>> 
>>>> return getJavaImporter(self).createProperty(JSType.toString(name));
>>>> 
>>>> You have a similar duplication of ((WithObject)obj).getExpression() in 
>>>> getJavaImporterInScope that you should avoid with an assignment to a 
>>>> (final) local variable.
>>>> 
>>>> Also note that this method could return NativeJavaImporter as it already 
>>

Re: RFR:8191301:JavaImporter fails to resolve imported elements within functions, that contain too many statements

[Attila Szegedi]

This is generally acceptable, and while I really don’t want to be a pain, I’ll 
point out few minor things still, because I really want this code to be the 
best it can be :-)

- in Nashorn code (and OpenJDK in general), we format “else” and “else if” to 
be on the same line as the closing brace of the previous block, so :

if (…) {
…
} else if (…) {
   …
} else {
   …
}

- in Nashorn, we declare all method parameters to be final.

- We strongly prefer final local variables with single-assignment whenever 
possible, so instead of early-initializing “expression" to null in 
getJavaImporter and then overwriting it, the preferred style would be:

final NativeJavaImporter expression;
if (self instanceof NativeJavaImporter) {
expression = (NativeJavaImporter)self;
} else if (self instanceof ScriptObject) {
expression = getJavaImporterInScope((ScriptObject)self);
} else {
expression = null;
}
return expression;

The compiler will prove that a final variable is assigned exactly once on each 
branch. This code is fairly simple so it might not matter much, but it’s good 
to adopt this style of coding as it lets the compiler help you ensure you 
didn’t forget to initialize the variable on any path. Sometimes the 
early-initialization value, in this case null, wouldn’t be valid in all cases 
and by providing it early, you paper over all the missing cases and the 
compiler can’t tell if you overlooked something. On the other hand, if you 
declare the variable as final, it’ll report a compilation error if the variable 
is not initialized on every possible path.

Alternatively, you could even do away with expression completely, and just use 
early return statements like this:

if (self instanceof NativeJavaImporter) {
return (NativeJavaImporter)self;
}
if (self instanceof ScriptObject) {
return getJavaImporterInScope((ScriptObject)self);
}
return null;

but I don’t consider that to be more valid than the above version with "final 
NativeJavaImporter expression”; they’re pretty much equivalent, albeit this 
last one is slightly shorter.

Attila.

> On 2017. Dec 12., at 18:31, Priya Lakshmi Muthuswamy 
> <priya.lakshmi.muthusw...@oracle.com> wrote:
> 
> Hi Attila,
> 
> I have modified the patch with your suggestions.
> 
> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.02/
> 
> Thanks,
> Priya
> 
> On 12/12/2017 8:49 PM, Attila Szegedi wrote:
>> Hi Priya,
>> 
>> This indeed looks much better, although I do have some remarks with regard 
>> to the the style of the code. Specifically, repetitions of identical code, 
>> as well as assignments inside predicates.
>> 
>> There are several cases of code that is repeating:
>> First is:
>> 
>> ((NativeJavaImporter)...).createProperty(JSType.toString(name))
>> 
>> Which occurs twice. You can avoid this by creating a “private static 
>> NativeJavaImporter getJavaImporter(Object self)” method that either returns 
>> self or does the lookup in scope, finally throws the type error if it found 
>> nothing. Then __noSuchProperty__ can be simply written as:
>> 
>> return getJavaImporter(self).createProperty(JSType.toString(name));
>> 
>> You have a similar duplication of ((WithObject)obj).getExpression() in 
>> getJavaImporterInScope that you should avoid with an assignment to a (final) 
>> local variable.
>> 
>> Also note that this method could return NativeJavaImporter as it already 
>> tests the expression for being an instanceof NativeJavaImporter. Basically, 
>> push the (NativeJavaImporter) cast down into getJavaImporterInScope; it’ll 
>> look nicer from the point of view of types than if you have to cast its 
>> return value in the caller.
>> 
>> Assignment in if: that’s discouraged because visually it’s easy to overlook 
>> or mistake for a comparison check at a glance. Instead of
>> 
>> ScriptObject expression;
>> if (self instanceof ScriptObject && (expression  = 
>> getJavaImporterInScope((ScriptObject)self))!=null) {
>> return 
>> ((NativeJavaImporter)expression).createProperty(JSType.toString(name));
>> }
>> 
>> use
>> 
>> if (self instanceof ScriptObject) {
>> final NativeJavaExporter expression = 
>> getJavaImporterInScope((ScriptObject)self);
>> If (expression != null) {
>> return ...
>> }
>> }
>> 
>> Attila.
>> 
>>> On Dec 12, 2017, at 1:32 PM, Priya Lakshmi Muthuswamy 
>>> <priya.lakshmi.muthusw...@oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> Kindly review. I have modified the fix to work with multiple with scopes.
>>> 
>>> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8

Re: RFR: 8069338: Implement sharedScopeCall for optimistic types

[Attila Szegedi]

I personally don’t believe anybody will ever be fidgeting with these, but it 
doesn’t hurt having them configurable, so… +1 :-)

> On Dec 12, 2017, at 2:39 PM, Hannes Wallnöfer <hannes.wallnoe...@oracle.com> 
> wrote:
> 
> Thanks for the review, Sundar.
> 
> I think making thresholds configurable is a good idea. I’ve uploaded a new 
> webrev where SHARED_CALL_THRESHOLD and SHARED_GET_THRESHOLD are configurable 
> via „nashorn.shared.scope.call.threshold“ and 
> „nashorn.shared.scope.get.threshold“ system properties, respectively. 
> 
> http://cr.openjdk.java.net/~hannesw/8069338/webrev.02/
> 
> Hannes
> 
>> Am 12.12.2017 um 14:00 schrieb Sundararajan Athijegannathan 
>> <sundararajan.athijegannat...@oracle.com>:
>> 
>> +1
>> 
>> PS. Not sure if it is worth making SHARED_GET_THRESHOLD configurable via 
>> System property?
>> 
>> -Sundar
>> 
>> On 12/12/17, 5:51 PM, Hannes Wallnöfer wrote:
>>> Thanks for the review, Attila.
>>> 
>>> I’ve uploaded a new webrev with your suggested changes (including making 
>>> ScriptObject.getProto(int) accept 0 argument and refactoring GET_PROTO code 
>>> in CodeGenerator into a method).
>>> 
>>> I have also done extensive performance testing over the last days and found 
>>> that for some reason, shared methods for variable access has a very 
>>> detrimental effect on performance for some reason. My theory is that we 
>>> don’t save as much by making property access shared, and the flood of 
>>> additional methods has some significant cost on codegen, runtime, JIT etc. 
>>> Based on this I decided to increase the threshold for shared property 
>>> access again to 100, which performs noticeably better than with the lower 
>>> threshold in some benchmarks.
>>> 
>>> New webrev is here:
>>> 
>>> http://cr.openjdk.java.net/~hannesw/8069338/webrev.01/
>>> 
>>> Hannes
>>> 
>>> 
>>>> Am 11.12.2017 um 11:55 schrieb Attila Szegedi<szege...@gmail.com>:
>>>> 
>>>> Reviewing this now, thanks for going ahead and implementing it!
>>>> 
>>>> So what you are saying about slow scopes is that shared scopes were 
>>>> disabled anyway with them for some time, so you didn’t really take away 
>>>> functionality, just cleaned up the remains?
>>>> 
>>>> So, some remarks:
>>>> 
>>>> 1. I see the bytecode shape you wrote around invocation of 
>>>> ScriptObject.getProto(int), and I realized it’s weird it asserts n>  0 and 
>>>> it has the first getProto() unrolled before the loop. I’m pretty sure it 
>>>> can just look like this:
>>>> 
>>>> public final ScriptObject getProto(final int n) {
>>>>ScriptObject p = this;
>>>>for (int i = n; i-->  0;) {
>>>>p = p.getProto();
>>>>}
>>>>return p;
>>>> }
>>>> 
>>>> That assert was there because we knew that it’s only CodeGenerator that 
>>>> emits calls to it, and it will always emit invocations with n>  0, but now 
>>>> we’d have a justification for invoking it with n == 0, so I think it’s 
>>>> fine to do it and avoid the no_proto_call branch in shared scope call 
>>>> bytecode. It’s not a big deal even if you leave it as-is, though.
>>>> 
>>>> To be entirely pedantic, that assert in getProto should’ve read “n>  1” 
>>>> before because the CodeGenerator was guaranteed to emit invocations to it 
>>>> with n>  1, so a really pedantic implementation of it should’ve read:
>>>> 
>>>> public final ScriptObject getProto(final int n) {
>>>>assert n>  1;
>>>>ScriptObject p = getProto().getProto();
>>>>for (int i = n - 1; --i>  0;) {
>>>>p = p.getProto();
>>>>}
>>>>return p;
>>>> }
>>>> 
>>>> (God, I really hope everyone reading this realizes I’m joking with this 
>>>> last one.)
>>>> 
>>>> FWIW, we could also factor out the:
>>>> 
>>>> if (depth>  1) {
>>>>method.load(depth);
>>>>method.invoke(ScriptObject.GET_PROTO_DEPTH);
>>>> } else {
>>>>method.invoke(ScriptObject.GET_PROTO);
>>>> }
>>>> 
>>>> pattern in CodeGenerator into its own little “emitGetProto(int depth)” 
>>>> method, as it appears twi

Re: RFR:8191301:JavaImporter fails to resolve imported elements within functions, that contain too many statements

[Attila Szegedi]

Hi Priya,

This indeed looks much better, although I do have some remarks with regard to 
the the style of the code. Specifically, repetitions of identical code, as well 
as assignments inside predicates.

There are several cases of code that is repeating:
First is: 

((NativeJavaImporter)...).createProperty(JSType.toString(name))

Which occurs twice. You can avoid this by creating a “private static 
NativeJavaImporter getJavaImporter(Object self)” method that either returns 
self or does the lookup in scope, finally throws the type error if it found 
nothing. Then __noSuchProperty__ can be simply written as:

return getJavaImporter(self).createProperty(JSType.toString(name));

You have a similar duplication of ((WithObject)obj).getExpression() in 
getJavaImporterInScope that you should avoid with an assignment to a (final) 
local variable. 

Also note that this method could return NativeJavaImporter as it already tests 
the expression for being an instanceof NativeJavaImporter. Basically, push the 
(NativeJavaImporter) cast down into getJavaImporterInScope; it’ll look nicer 
from the point of view of types than if you have to cast its return value in 
the caller.

Assignment in if: that’s discouraged because visually it’s easy to overlook or 
mistake for a comparison check at a glance. Instead of 

ScriptObject expression;
if (self instanceof ScriptObject && (expression  = 
getJavaImporterInScope((ScriptObject)self))!=null) {
return 
((NativeJavaImporter)expression).createProperty(JSType.toString(name));
}

use

if (self instanceof ScriptObject) {
final NativeJavaExporter expression = 
getJavaImporterInScope((ScriptObject)self);
If (expression != null) {
return ...
}
}

Attila.

> On Dec 12, 2017, at 1:32 PM, Priya Lakshmi Muthuswamy 
> <priya.lakshmi.muthusw...@oracle.com> wrote:
> 
> Hi,
> 
> Kindly review. I have modified the fix to work with multiple with scopes.
> 
> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.01/
> 
> Thanks,
> Priya
> On 12/5/2017 12:54 PM, Priya Lakshmi Muthuswamy wrote:
>> Hi Attila,
>> 
>> Thanks for review.
>> Yes when I checked with two with scopes as suggested(JavaImporter as outer), 
>> current fix doesn't work. I will work on that.
>> 
>> Thanks,
>> Priya
>> On 12/5/2017 12:12 PM, Attila Szegedi wrote:
>>> Hm… this seems to be an issue with shared scope calls; that’s why it’s 
>>> sensitive to the number of similar statements.
>>> 
>>> That said, here’s some thoughts:
>>> 
>>> 1. Instead of
>>> 
>>> if (self instanceof ScriptObject && 
>>> ((ScriptObject)self).hasWithScope()) {
>>> 
>>> you should be able to just use
>>> 
>>> if (self instanceof ScriptObject) {
>>> 
>>> As then you’ll evaluate getWithScopeObject and test it for being null 
>>> anyway. This way, you avoid walking the prototype chain twice.
>>> 
>>> 2. That said, I guess hasWithScope could be reimplemented simply as
>>> 
>>> public boolean hasWithScope() {
>>> return getWithScopeObject() != null;
>>> }
>>> 
>>> as both have very similar code, so it’d reduce to it nicely. (I understand 
>>> that you haven’t changed that, but since you were in the vicinity of that 
>>> code, you might as wel do it… It’s also fine if you leave it alone as it 
>>> is.)
>>> 
>>> 3. One of the statements in the test is indented differently than the 
>>> others.
>>> 
>>> 4. What happens if there’s _two_ with scopes, and the JavaImporter is in 
>>> the outer one? Does this fix still work? E.g.:
>>> 
>>> var imports = new JavaImporter(java.lang);
>>> var dummy = { x: 42, y: 13 }
>>> with (imports) {
>>>  with (dummy) {
>>>  function func() {
>>>  System.out.println('a');
>>> System.out.println('a');
>>> System.out.println('a');
>>>  System.out.println('a');
>>> System.out.println('a');
>>> System.out.println('a');
>>> System.out.println('a');
>>>  };
>>>  func();
>>> }
>>> }
>>> 
>>> Attila.
>>> 
>>>> On Dec 5, 2017, at 7:13 AM, Priya Lakshmi Muthuswamy 
>>>> <priya.lakshmi.muthusw...@oracle.com> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> please review JDK-8191301 : JavaImporter fails to resolve imported 
>>>> elements within functions, that contain too many statements
>>>> 
>>>> JBS : https://bugs.openjdk.java.net/browse/JDK-8191301
>>>> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.00/
>>>> 
>>>> Thanks,
>>>> Priya
>>>> 
>>>> 
>> 
> 

Re: RFR: 8069338: Implement sharedScopeCall for optimistic types

[Attila Szegedi]

+1

> On Dec 12, 2017, at 1:21 PM, Hannes Wallnöfer <hannes.wallnoe...@oracle.com> 
> wrote:
> 
> Thanks for the review, Attila.
> 
> I’ve uploaded a new webrev with your suggested changes (including making 
> ScriptObject.getProto(int) accept 0 argument and refactoring GET_PROTO code 
> in CodeGenerator into a method). 
> 
> I have also done extensive performance testing over the last days and found 
> that for some reason, shared methods for variable access has a very 
> detrimental effect on performance for some reason. My theory is that we don’t 
> save as much by making property access shared, and the flood of additional 
> methods has some significant cost on codegen, runtime, JIT etc. Based on this 
> I decided to increase the threshold for shared property access again to 100, 
> which performs noticeably better than with the lower threshold in some 
> benchmarks.
> 
> New webrev is here:
> 
> http://cr.openjdk.java.net/~hannesw/8069338/webrev.01/
> 
> Hannes
> 
> 
>> Am 11.12.2017 um 11:55 schrieb Attila Szegedi <szege...@gmail.com>:
>> 
>> Reviewing this now, thanks for going ahead and implementing it!
>> 
>> So what you are saying about slow scopes is that shared scopes were disabled 
>> anyway with them for some time, so you didn’t really take away 
>> functionality, just cleaned up the remains?
>> 
>> So, some remarks:
>> 
>> 1. I see the bytecode shape you wrote around invocation of 
>> ScriptObject.getProto(int), and I realized it’s weird it asserts n > 0 and 
>> it has the first getProto() unrolled before the loop. I’m pretty sure it can 
>> just look like this:
>> 
>> public final ScriptObject getProto(final int n) {
>>ScriptObject p = this;
>>for (int i = n; i-- > 0;) {
>>p = p.getProto();
>>}
>>return p;
>> }
>> 
>> That assert was there because we knew that it’s only CodeGenerator that 
>> emits calls to it, and it will always emit invocations with n > 0, but now 
>> we’d have a justification for invoking it with n == 0, so I think it’s fine 
>> to do it and avoid the no_proto_call branch in shared scope call bytecode. 
>> It’s not a big deal even if you leave it as-is, though.
>> 
>> To be entirely pedantic, that assert in getProto should’ve read “n > 1” 
>> before because the CodeGenerator was guaranteed to emit invocations to it 
>> with n > 1, so a really pedantic implementation of it should’ve read:
>> 
>> public final ScriptObject getProto(final int n) {
>>assert n > 1;
>>ScriptObject p = getProto().getProto();
>>for (int i = n - 1; --i > 0;) {
>>p = p.getProto();
>>}
>>return p;
>> }
>> 
>> (God, I really hope everyone reading this realizes I’m joking with this last 
>> one.)
>> 
>> FWIW, we could also factor out the:
>> 
>> if (depth > 1) {
>>method.load(depth);
>>method.invoke(ScriptObject.GET_PROTO_DEPTH);
>> } else {
>>method.invoke(ScriptObject.GET_PROTO);
>> }
>> 
>> pattern in CodeGenerator into its own little “emitGetProto(int depth)” 
>> method, as it appears twice (and make sure it asserts on depth > 0 ;-) )
>> 
>> 2. For that invocation of UnwarrantedOptimismException.withProgramPoint - 
>> I’d create a Call objects using CompilerConstants.virtualCallNoLookup and 
>> stash it in a static final field either in SharedScopeCall or 
>> UnwarrantedOptimismException; it’s more typesafe than writing type 
>> descriptors as strings.
>> 
>> 3. So, UOE.hasPrimitiveReturnValue was unused, I take it?
>> 
>> 3. In getStaticSignature you have another occurrence of number 3 that you 
>> can replace with FIXED_PARAM_COUNT :-)
>> 
>> But these are all minor points… overall, this looks really good.
>> 
>> Attila.
>> 
>>> On Dec 6, 2017, at 6:43 PM, Hannes Wallnöfer <hannes.wallnoe...@oracle.com> 
>>> wrote:
>>> 
>>> Please review: 
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8069338
>>> Webrev: http://cr.openjdk.java.net/~hannesw/8069338/webrev.00/
>>> 
>>> This implements shared scope calls for optimistic vars/calls. I followed 
>>> Attila’s blueprint in the bug description to the last detail - thanks for 
>>> figuring it all out.
>>> 
>>> Some adjustments and cleanups I did along the way:
>>> 
>>> - Originally shared scope calls were designed to support slow scope vars 
>>> (with/eval). However, that feature was disabled later on. I refactored the 
>>> code to make it clear that we only do shared scope calls for fast scope 
>>> operations.
>>> - I unified the threshold for all shared scope operations to 5. I don’t 
>>> think there is a reason for different thresholds for different operations. 
>>> I did some testing, using 5 as threshold appeared to be a sensible value.
>>> 
>>> Running all of the  octane benchmark I see a decrease in created callsites 
>>> (200 000 to 178 000) and a slight decrease in callsite invalidations.
>>> 
>>> Hannes
>> 
> 

Re: Review request for JDK-8193296: Parser should not eagerly transform delete expressions

[Attila Szegedi]

Thanks!

I admittedly cribbed the various @tags from the neighboring JDK_8188098_Test 
class :-). I take it “@run testng …” is meaningful and understood by jtreg 
then, so I can leave that as it is? I tried to find other examples and stumbled 
upon e.g. JDK_8184723_Test which specifies “@run main/othervm” and also 
declares “@modules” - is that something I should be doing as well, and can you 
advice what would be the correct values?

Attila.


> On Dec 11, 2017, at 8:18 AM, Sundararajan Athijegannathan 
> <sundararajan.athijegannat...@oracle.com> wrote:
> 
> * Test misses copyright comment
> * you may want to add @bug  and @summary line in jtreg comment section
> 
> Other than that, +1
> 
> -Sundar
> 
> On 10/12/17, 9:52 PM, Attila Szegedi wrote:
>> Please review JDK-8193296 "Parser should not eagerly transform delete 
>> expressions" 
>> at<http://cr.openjdk.java.net/~attila/8193296/webrev.jdk<http://cr.openjdk.java.net/~attila/8193296/webrev.jdk>>
>>   
>> for<https://bugs.openjdk.java.net/browse/JDK-8193296<https://bugs.openjdk.java.net/browse/JDK-8193296>>
>> 
>> Thanks,
>>  Attila.
>> 

Re: RFR: 8134516(Move getInvokeByName and getDynamicInvoker methods from Global to Context)

[Attila Szegedi]

You shouldn't make Global.getContext() public. Context is a security-sensitive 
class, and the only public access to it is supposed to be through 
Context.getContext(), which includes a security check.

I see you have also simply disabled that security check in your patch. I’m 
afraid that’s unacceptable.

You could make the patch much smaller (and avoid security concerns altogether) 
if you kept Global.getInvokeByName and Global.getDynamicInvoker methods as they 
are and have them internally delegate to their new equivalents in Context, 
adding “this” as the last argument as they do so.

This is all in addition to Hannes’ observation with regard to the performance 
implications in his previous e-mail.

Attila.

> On Dec 6, 2017, at 4:47 PM, Srinivas Dama  wrote:
> 
> Hi,
> 
> Please review http://cr.openjdk.java.net/~sdama/8134516/webrev.01/ for 
> https://bugs.openjdk.java.net/browse/JDK-8134516 
> 
> Regards,
> Srinivas

Re: RFR: 8069338: Implement sharedScopeCall for optimistic types

[Attila Szegedi]

Reviewing this now, thanks for going ahead and implementing it!

So what you are saying about slow scopes is that shared scopes were disabled 
anyway with them for some time, so you didn’t really take away functionality, 
just cleaned up the remains?

So, some remarks:

1. I see the bytecode shape you wrote around invocation of 
ScriptObject.getProto(int), and I realized it’s weird it asserts n > 0 and it 
has the first getProto() unrolled before the loop. I’m pretty sure it can just 
look like this:

public final ScriptObject getProto(final int n) {
ScriptObject p = this;
for (int i = n; i-- > 0;) {
p = p.getProto();
}
return p;
}

That assert was there because we knew that it’s only CodeGenerator that emits 
calls to it, and it will always emit invocations with n > 0, but now we’d have 
a justification for invoking it with n == 0, so I think it’s fine to do it and 
avoid the no_proto_call branch in shared scope call bytecode. It’s not a big 
deal even if you leave it as-is, though.

To be entirely pedantic, that assert in getProto should’ve read “n > 1” before 
because the CodeGenerator was guaranteed to emit invocations to it with n > 1, 
so a really pedantic implementation of it should’ve read:

public final ScriptObject getProto(final int n) {
assert n > 1;
ScriptObject p = getProto().getProto();
for (int i = n - 1; --i > 0;) {
p = p.getProto();
}
return p;
}

(God, I really hope everyone reading this realizes I’m joking with this last 
one.)

FWIW, we could also factor out the:

if (depth > 1) {
method.load(depth);
method.invoke(ScriptObject.GET_PROTO_DEPTH);
} else {
method.invoke(ScriptObject.GET_PROTO);
}

pattern in CodeGenerator into its own little “emitGetProto(int depth)” method, 
as it appears twice (and make sure it asserts on depth > 0 ;-) )

2. For that invocation of UnwarrantedOptimismException.withProgramPoint - I’d 
create a Call objects using CompilerConstants.virtualCallNoLookup and stash it 
in a static final field either in SharedScopeCall or 
UnwarrantedOptimismException; it’s more typesafe than writing type descriptors 
as strings.

3. So, UOE.hasPrimitiveReturnValue was unused, I take it?

3. In getStaticSignature you have another occurrence of number 3 that you can 
replace with FIXED_PARAM_COUNT :-)

But these are all minor points… overall, this looks really good.

Attila.

> On Dec 6, 2017, at 6:43 PM, Hannes Wallnöfer  
> wrote:
> 
> Please review: 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8069338
> Webrev: http://cr.openjdk.java.net/~hannesw/8069338/webrev.00/
> 
> This implements shared scope calls for optimistic vars/calls. I followed 
> Attila’s blueprint in the bug description to the last detail - thanks for 
> figuring it all out.
> 
> Some adjustments and cleanups I did along the way:
> 
> - Originally shared scope calls were designed to support slow scope vars 
> (with/eval). However, that feature was disabled later on. I refactored the 
> code to make it clear that we only do shared scope calls for fast scope 
> operations.
> - I unified the threshold for all shared scope operations to 5. I don’t think 
> there is a reason for different thresholds for different operations. I did 
> some testing, using 5 as threshold appeared to be a sensible value.
> 
> Running all of the  octane benchmark I see a decrease in created callsites 
> (200 000 to 178 000) and a slight decrease in callsite invalidations.
> 
> Hannes

Review request for JDK-8193298: Don't run javadoc with test.single

[Attila Szegedi]

Please review JDK-8193298 "Don't run javadoc with test.single" at 
 for 


Thanks,
  Attila.

Review request for JDK-8193296: Parser should not eagerly transform delete expressions

[Attila Szegedi]

Please review JDK-8193296 "Parser should not eagerly transform delete 
expressions" at > for 
>

Thanks,
 Attila.

Review request for JDK-8191905: Add a REMOVE value to jdk.dynalink.StandardOperation

[Attila Szegedi]

Please review JDK-8191905 "Add a REMOVE value to 
jdk.dynalink.StandardOperation" at 
 for 


The public API changes have an approved CSR. Note that this adds a REMOVE 
operation to Dynalink and a default implementation for Lists and Maps to 
BeanLinker, but stops short of retrofitting Nashorn’s delete operator - that’s 
the next step I’m yet to implement.

Thanks,
  Attila.

Re: Review request for JDK-8192970: Element getters/setters with fixed key fail to link properly

[Attila Szegedi]

Is it okay to commit this with one +1 or should I wait for another approval?

Thanks,
  Attila.

> On 2017. Dec 4., at 16:36, Hannes Wallnöfer <hannes.wallnoe...@oracle.com> 
> wrote:
> 
> Took me some time to spot the difference in behaviour (adaptation of method 
> type in Binder)!
> 
> +1
> 
> Hannes
> 
>> Am 04.12.2017 um 13:40 schrieb Attila Szegedi <szege...@gmail.com>:
>> 
>> Please review JDK-8192970 "Element getters/setters with fixed key fail to 
>> link properly" at <http://cr.openjdk.java.net/~attila/8192970/webrev.jdk> 
>> for <https://bugs.openjdk.java.net/browse/JDK-8192970>
>> 
>> Note that this is unrelated to the previous refactoring (8191878), it is 
>> present even before that and also in JDK9, I’ll have to separately produce a 
>> backport fix for it. I discovered this while trying to expand the test 
>> coverage (and good thing that I did, too…)
>> 
>> The gist of the problem is that convertArgToNumber as it was before will 
>> fail with IndexOutOfBoundsException invoking parameterType(1) on method type 
>> for fixed-key getters, as they only have one parameter at index 0. 
>> 
>> The fix is to move the logic into the Binder and use the methodType it 
>> manages, not the call site method type. This works because Binder always 
>> works with a method type as if the getter/setter were variable-key (it adds 
>> back the parameter type in its constructor if the operation is for a fixed 
>> key).
>> 
>> Thanks,
>> Attila.
> 

Re: RFR:8191301:JavaImporter fails to resolve imported elements within functions, that contain too many statements

[Attila Szegedi]

Hm… this seems to be an issue with shared scope calls; that’s why it’s 
sensitive to the number of similar statements.

That said, here’s some thoughts:

1. Instead of 

if (self instanceof ScriptObject && 
((ScriptObject)self).hasWithScope()) {

you should be able to just use

if (self instanceof ScriptObject) {

As then you’ll evaluate getWithScopeObject and test it for being null anyway. 
This way, you avoid walking the prototype chain twice. 

2. That said, I guess hasWithScope could be reimplemented simply as

public boolean hasWithScope() {
return getWithScopeObject() != null;
}

as both have very similar code, so it’d reduce to it nicely. (I understand that 
you haven’t changed that, but since you were in the vicinity of that code, you 
might as wel do it… It’s also fine if you leave it alone as it is.)

3. One of the statements in the test is indented differently than the others.

4. What happens if there’s _two_ with scopes, and the JavaImporter is in the 
outer one? Does this fix still work? E.g.:

var imports = new JavaImporter(java.lang);
var dummy = { x: 42, y: 13 }
with (imports) {
with (dummy) {
function func() {
System.out.println('a');
System.out.println('a');
System.out.println('a');
System.out.println('a');
System.out.println('a');
System.out.println('a');
System.out.println('a');
};
func();
}
}

Attila.

> On Dec 5, 2017, at 7:13 AM, Priya Lakshmi Muthuswamy 
>  wrote:
> 
> Hi,
> 
> please review JDK-8191301 : JavaImporter fails to resolve imported elements 
> within functions, that contain too many statements
> 
> JBS : https://bugs.openjdk.java.net/browse/JDK-8191301
> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.00/
> 
> Thanks,
> Priya
> 
> 

Re: Review request for JDK-8192970: Element getters/setters with fixed key fail to link properly

[Attila Szegedi]

I know, it’s subtle; that’s why I decided to describe it in detail :-)

> On 2017. Dec 4., at 16:36, Hannes Wallnöfer <hannes.wallnoe...@oracle.com> 
> wrote:
> 
> Took me some time to spot the difference in behaviour (adaptation of method 
> type in Binder)!
> 
> +1
> 
> Hannes
> 
>> Am 04.12.2017 um 13:40 schrieb Attila Szegedi <szege...@gmail.com>:
>> 
>> Please review JDK-8192970 "Element getters/setters with fixed key fail to 
>> link properly" at <http://cr.openjdk.java.net/~attila/8192970/webrev.jdk> 
>> for <https://bugs.openjdk.java.net/browse/JDK-8192970>
>> 
>> Note that this is unrelated to the previous refactoring (8191878), it is 
>> present even before that and also in JDK9, I’ll have to separately produce a 
>> backport fix for it. I discovered this while trying to expand the test 
>> coverage (and good thing that I did, too…)
>> 
>> The gist of the problem is that convertArgToNumber as it was before will 
>> fail with IndexOutOfBoundsException invoking parameterType(1) on method type 
>> for fixed-key getters, as they only have one parameter at index 0. 
>> 
>> The fix is to move the logic into the Binder and use the methodType it 
>> manages, not the call site method type. This works because Binder always 
>> works with a method type as if the getter/setter were variable-key (it adds 
>> back the parameter type in its constructor if the operation is for a fixed 
>> key).
>> 
>> Thanks,
>> Attila.
> 

Review request for JDK-8192970: Element getters/setters with fixed key fail to link properly

[Attila Szegedi]

Please review JDK-8192970 "Element getters/setters with fixed key fail to link 
properly" at  for 


Note that this is unrelated to the previous refactoring (8191878), it is 
present even before that and also in JDK9, I’ll have to separately produce a 
backport fix for it. I discovered this while trying to expand the test coverage 
(and good thing that I did, too…)

The gist of the problem is that convertArgToNumber as it was before will fail 
with IndexOutOfBoundsException invoking parameterType(1) on method type for 
fixed-key getters, as they only have one parameter at index 0. 

The fix is to move the logic into the Binder and use the methodType it manages, 
not the call site method type. This works because Binder always works with a 
method type as if the getter/setter were variable-key (it adds back the 
parameter type in its constructor if the operation is for a fixed key).

Thanks,
  Attila.

Review request for JDK-8191878: Reduce code duplication in BeanLinker

[Attila Szegedi]

Hey folks,

I’m able to spend some free time again on OpenJDK development, and one thing I 
have on my plate is adding a REMOVE operation to Dynalink.

This CR however, is not yet it: that will require a CCC sponsorship etc. as 
I’ll be adding a new enum value to StandardOperations, and I will follow up 
separately once I’m done with it. 

What this is a refactoring of BeanLinker code to eliminate most of the code 
duplication between getElementGetter and getElementSetter methods. This would 
be justified on its own, but once I need to add the getElementRemover method, 
it will really pay off as then we won’t have triplication of similar code.

With that in mind, please review JDK-8191878 "Reduce code duplication in 
BeanLinker" at  for 


Thanks,
  Attila.

Re: RFR:JDK-8190391:nashorn: "!!" of nonzero even integer var becomes false when returned

[Attila Szegedi]

+1. Nice catch. Feels like an implementation detail, but the JVM
specification is indeed unclear on the behavior in case there's a bytecode
method doing this:

public static func(I)Z
0 iload 0
1 ireturn


I went spelunking in the JVM spec, and the closest I could find is in
section 2.3.4 says "The Java Virtual Machine encodes boolean array
components using 1 to represent true and 0 to represent false. Where Java
programming language boolean values are mapped by compilers to values of
Java Virtual Machine type int, the compilers must use the same encoding."
So I guess we better stick to that.

Attila.


On Mon, Nov 13, 2017 at 7:21 AM, Priya Lakshmi Muthuswamy <
priya.lakshmi.muthusw...@oracle.com> wrote:

> Hi,
>
> Please review JDK-8190391 : nashorn: "!!" of nonzero even integer var
> becomes false when returned
>
> JBS : https://bugs.openjdk.java.net/browse/JDK-8190391
> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8190391/webrev.00/
>
> Thanks,
> Priya
>

Re: RFR: 8187962: Optimistic types ignore JavaAdapter return types

[Attila Szegedi]

+1

> On 2017. Sep 26., at 19:05, Hannes Wallnöfer  
> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8187962
> Webrev: http://cr.openjdk.java.net/~hannesw/8187962/webrev/
> 
> Thanks,
> Hannes

Re: RFR:8187362:Nashorn unsigned right shift operator unexpectedly returns floating-point

[Attila Szegedi]

Wow, that hidden unboxing and primitive widening in the conditional operator is 
sinister. I had to write a small test program and use javap on it to see it 
with my own eyes. Surely this isn’t a javac bug?

Attila.

> On 2017. Sep 13., at 11:18, Hannes Wallnöfer  
> wrote:
> 
> +1
> 
> Hannes
> 
>> Am 13.09.2017 um 07:21 schrieb Sundararajan Athijegannathan 
>> :
>> 
>> +1
>> 
>> PS. You may want to add explanation to the bug (if not done already). We may 
>> have to revisit conditional expressions elsewhere as well
>> 
>> -Sundar
>> 
>> On 13/09/17, 10:37 AM, Priya Lakshmi Muthuswamy wrote:
>>> Updated patch : http://cr.openjdk.java.net/~pmuthuswamy/8187362/webrev.01/
>>> corrected the alignment.
>>> 
>>> Thanks,
>>> Priya
>>> 
>>> On 9/13/2017 9:58 AM, Priya Lakshmi Muthuswamy wrote:
 Hi,
 
 Please review JDK-8187362 : Nashorn unsigned right shift operator 
 unexpectedly returns floating-point
 JBS: https://bugs.openjdk.java.net/browse/JDK-8187362
 webrev: http://cr.openjdk.java.net/~pmuthuswamy/8187362/webrev.00/
 
 Thanks,
 Priya
>>> 
> 

Re: Invalidate callsite

[Attila Szegedi]

I’d suggest that when findCallMethod is invoked so that in the LinkRequest 
arguments, there’s a string argument, you produce a GuardedInvocation with the 
first method and a guard that checks if the relevant argument is a string, and 
when invoked with a PyObject, then produce a GuardedInvocation with the second 
method and a guard that checks if argument 3 is a PyObject.

Attila.

> On 01 Aug 2017, at 13:43, Isaiah Peng  wrote:
> 
> Hi guys,
> 
> My name is Isaiah, I'm currently trying to implement invokedynamic for my
> Python 3 implementation. Everything went quite well until I encountered a
> `ClassCastException` which I don't know how to fix.
> 
> Here is my theory: there are two method calls that has the same arity, with
> signatures of:
> 
> `(LPyObject;LThreadState;[LPyObject;LString;)LPyObject`
> and
> `(LPyObject;LThreadState;LPyObject;LPyObject)LPyObject`
> 
> The former is for methods that take vararg and keyword arguments, the later
> is for methods that take two arguments. The stacktrace is as following:
> 
> java.lang.ClassCastException: Cannot cast [Ljava.lang.String; to
> org.python.core.PyObject
> 
>at java.base/java.lang.Class.cast(Class.java:3578)
>at contextlib_jython_36.__init__$12(contextlib:67)
>at org.python.core.Py.runCode(Py.java:1663)
>at org.python.core.PyTableCode.call(PyTableCode.java:404)
>at org.python.core.PyTableCode.call(PyTableCode.java:382)
>at org.python.core.PyFunction.__call__(PyFunction.java:442)
>at
> org.python.core.PyMethod.instancemethod___call__(PyMethod.java:237)
>at org.python.core.PyMethod.__call__(PyMethod.java:228)
>at org.python.core.PyMethod.__call__(PyMethod.java:223)
>at org.python.core.Deriveds.dispatch__init__(Deriveds.java:19)
>at
> org.python.core.PyObjectDerived.dispatch__init__(PyObjectDerived.java:940)
>at org.python.core.PyType.type___call__(PyType.java:1675)
>at org.python.core.PyType$type___call___exposer.__call__(Unknown
> Source)
>at org.python.core.PyTypeDerived.__call__(PyTypeDerived.java:831)
>at org.python.core.PyObject.__call__(PyObject.java:506)
>at org.python.core.PyObject.__call__(PyObject.java:510)
>at contextlib_jython_36.helper$17(contextlib:159)
> 
> The GuardedInvocation returned from the linker is like:
> 
> `return new GuardedInvocation(mh, null, new SwitchPoint[0],
> ClassCastException.class);`
> 
> It seems to be able to catch the class cast exception for the receiver but
> not for arguments. I create a similar call path and the function works
> fine, so I thought the cause could be the callsite is not invalidated.
> 
> My question is: Is my guess correct? if so why does it reuse the callsite
> when the signatures are different? and how to create a guard for such case?
> 
> The source code can be found here:
> 
> https://bitbucket.org/jylang/jylang/src/e0c64d17b21db7784c75892424cae09f9faa07d3/src/org/python/core/PyFunction.java?at=indy=file-view-default#PyFunction.java-513
> 
> Thanks in advance,
> Isaiah Peng

Re: RFR (10): JDK-8181191: getUint32 returning Long

[Attila Szegedi]

+1

the test described in the issue was failing because we treated Long objects as 
JS objects, right?

Attila.

> On 13 Jun 2017, at 17:51, Hannes Wallnöfer  
> wrote:
> 
> Please review: 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8181191
> Webrev: http://cr.openjdk.java.net/~hannesw/8181191/webrev/
> 
> Thanks,
> Hannes

Re: how to help with ES6 features

[Attila Szegedi]

It should likely be written to be able to work with either generally any 
j.u.concurrent.ExecutorService (or even better just j.u.concurrent.Executor if 
the contract is simple enough), and provide a default using some of the 
j.u.c.Executors static factory methods, e.g. an Executors.newCachedThreadPool().

Attila.

> On 27 Apr 2017, at 14:07, Paulo Lopes  wrote:
> 
> I can make it work with nashorn. Currently it does run on nashorn jdk8 plus
> I need a executor impl for the async part. Of course I'm using vert.x for
> this ;) However this could be a runtime configuration and by default use a
> simple ThreadPool as it exists on the JDK itself and allow (say with some
> runtime config) to provide a custom executor.
> 
> The executor is basically the equivalent of the not yet standard:
> 
> setImmediate(function);
> 
> Or node's:
> 
> nextTick(function);
> 
> So in nashorn it can be just a java.lang.Runnable and a ThreadPoolExecutor.
> 
> Cheers,
> Paulo
> 
> 
> On Thu, Apr 27, 2017 at 1:49 PM, Hannes Wallnöfer <
> hannes.wallnoe...@oracle.com> wrote:
> 
>> Hi Paulo,
>> 
>> Excellent! I’d be happy to help you and sponsor this work.
>> 
>> Do you think your existing code would work in Nashorn, or would it be a
>> reimplementation based on that prototype? In any case, a link to the code
>> would be nice to get an idea of what’s involved.
>> 
>> Also, before contributing to OpenJDK you have to sign and send in the
>> committer agreement as described in http://openjdk.java.net/contribute/ .
>> If you aren’t a committer already we can help you with this.
>> 
>> Hannes
>> 
>> 
>>> Am 27.04.2017 um 13:16 schrieb Paulo Lopes :
>>> 
>>> Hi,
>>> 
>>> For Vert.x javascript support I've prototyped the Promise API as per:
>>> 
>>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/
>> Reference/Global_Objects/Promise
>>> http://www.ecma-international.org/ecma-262/6.0/#sec-promise-objects
>>> 
>>> I see that it is not in the complete list, If someone would "mentor" me
>> with how to get it in nashorn, I'd gladly contribute the code.
>>> 
>>> As an example here's some demo:
>>> 
>>> https://gist.github.com/pmlopes/3d86f67943b3ffd9dd9aff73067de0a2
>>> 
>>> And it has been tested to work with babel.js to allow transpiling
>> `async` `await` to Promise API.
>>> 
>>> Cheers,
>>> Paulo
>>> 
>>> 
>>> On Wed, Apr 26, 2017 at 4:38 PM, Hannes Wallnöfer <
>> hannes.wallnoe...@oracle.com> wrote:
>>> Here’s a list of things we have working and things we don’t:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8066046
>>> 
>>> ES6 support in the parser is pretty much complete, so some features are
>> arrow functions are ‚almost‘ working, and others may not require too much
>> effort.
>>> 
>>> Hannes
>>> 
>>> 
 Am 26.04.2017 um 16:18 schrieb Karl Pietrzak :
 
 On Wed, Apr 26, 2017 at 10:14 AM, Hannes Wallnöfer <
 hannes.wallnoe...@oracle.com> wrote:
 
> ES6 support is still work in progress, we only support some of it, so
> making it the default wouldn’t be a good idea.
> 
 
 
 Is there a feature I can help with?   If someone points me in the right
 direction, I can submit a patch.  I don't see anything in JIRA, really.
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Paulo Lopes
>>> www.jetdrone.com
>> 
>> 
> 
> 
> -- 
> Paulo Lopes
> www.jetdrone.com

Re: RFR: 8156743: ES6 for..of should work for Java Maps and Sets

[Attila Szegedi]

Contrary to the issue name, I don’t see anything for handling Set in the patch, 
but I guess that’s because Set is a Collection and those already work?

As an aside… I was looking into your use of NativeJava.from to convert a Java 
array to a NativeArray, and realized that we have at least 3 ways to do it, 
each with different drawbacks:
1. NativeJava.from as used in this patch. Its drawback is that it defensively 
always clones the array (here we woulnd’t need to clone it, although it doesn’t 
hurt)
2. Global.instance.wrapAsObject. Its drawback is that its Object[] case is 
further down the if/else list than NativeJava.from (5th instanceof vs. 2nd)
3. Global.instance.allocate. (This one is primarily used from generated 
bytecode.) Its drawback is that it iterates over the elements scanning for any 
ScriptRuntime.EMPTY values. I guess we could pass in a boolean flag to indicate 
there are no empty values to skip this scan (compiler could set the flag when 
it can prove the array literal it’s constructing has no empties).

This doesn’t affect your patch - I think NativeJava.from() is a decent choice.

So, +1.

Attila.

> On 02 Mar 2017, at 15:36, Srinivas Dama  wrote:
> 
> Hello,
> 
> Please review http://cr.openjdk.java.net/~sdama/8156743/webrev.00/ 
> for https://bugs.openjdk.java.net/browse/JDK-8156743 
> 
> Regards,
> Srinivas
> 

Re: Supporting [[hasProperty]] on JavaBeans

[Attila Szegedi]

BeansLinker has a bunch of static methods like getReadableInstancePropertyNames 
etc. that could be used to implement special cases in ScriptRuntime.IN. A logic 
modelled after how NativeObject.bindProperties works should do (after all, “in” 
on a bean should work equivalently to how it works on the result of 
Object.bindProperties({}, bean).

To answer your operator question, a lot of INVOKESTATIC calls to RuntimeNode 
special methods could be eqiuvalently reworked to use INVOKEDYNAMIC with custom 
operations, although the benefit is unclear as long as all possible 
implementations reside within a single runtime (Nashorn). Expanding the set of 
standard operations would probably make more sense… My first candidate for a 
new standard operation is specifically DELETE (folks have asked for it here on 
the list), I just couldn’t find the time to make it happen for the JDK 9 
initial release timeframe :-(

Attila.

> On 26 Jan 2017, at 13:57, Hannes Wallnöfer  
> wrote:
> 
> I noticed today that we don’t support the „in“ operator on JavaBeans. 
> ScriptRuntime.IN(Object, Object) returns false if the second argument is a 
> generic object (not a ScriptObject or JSObject).
> 
> I was wondering if this is an oversight or intentional. If it is the former, 
> how would we implement this? Is this the case for a non-standard Dynalink 
> operation such as HAS?
> 
> Hannes

Re: RFR: 8172006: Nashorn JavaScript engine fails to call @FunctionalInterface with a java.util.List argument

[Attila Szegedi]

Well, filterInternalObjects itself doesn’t change the method handle type. I 
guess what happens is that the delegate BeansLinker.getGuardedInvocation 
returned a handle that it already adapted to the call site type. But you’re 
right that the filterInternalObjects here was both redundant and harmful; 
BeanLinker calls it where necessary.

+1.

Glad you got to the bottom of this, it felt really scary how the original 
reproducer seemingly depended on the shape of not-yet-evaluated expressions (I 
completely forgot about shared scope…)

Attila.

> On 25 Jan 2017, at 17:32, Hannes Wallnöfer <hannes.wallnoe...@oracle.com> 
> wrote:
> 
> The problem is that the first invocation of filtertInternalObjects (that 
> happens closer to the target handle) changes the method handle’s parameter 
> type from java.util.List to java.lang.Object, so the outer 
> filtertInternalObjects invocation did not see the List target type.
> 
> Hannes
> 
>> Am 25.01.2017 um 17:21 schrieb Attila Szegedi <szege...@gmail.com>:
>> 
>> Oh, great. I was just starting at this for a bit (after I saw you updated 
>> the JIRA), and was definitely starting to suspect the filterInternalObjects 
>> call in NashornBeansLinker. It still worries me that filtering would add a 
>> script object mirror wrapper – the method handle’s parameter is typed as 
>> List, isn’t it? DefaultInternalObjectFilter should only operate on 
>> parameters declared as Object.
>> 
>> Attila.
>> 
>>> On 25 Jan 2017, at 17:05, Hannes Wallnöfer <hannes.wallnoe...@oracle.com> 
>>> wrote:
>>> 
>>> Please review:
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172006
>>> Webrev: http://cr.openjdk.java.net/~hannesw/8172006/webrev.00/
>>> 
>>> The final invocation of linkerServices.filterInternalObjects was redundant, 
>>> and in fact caused the argument to be converted to ScripObjectMirror when 
>>> the actual target type was java.util.List. As far as I can tell, 
>>> linkerServices.filterInternalObjects is called elsewhere for all types of 
>>> invocations. Existing tests pass, and I added a few more.
>>> 
>>> Thanks,
>>> Hannes
>> 
> 

Re: RFR: 8172006: Nashorn JavaScript engine fails to call @FunctionalInterface with a java.util.List argument

[Attila Szegedi]

Oh, great. I was just starting at this for a bit (after I saw you updated the 
JIRA), and was definitely starting to suspect the filterInternalObjects call in 
NashornBeansLinker. It still worries me that filtering would add a script 
object mirror wrapper – the method handle’s parameter is typed as List, isn’t 
it? DefaultInternalObjectFilter should only operate on parameters declared as 
Object.

Attila.

> On 25 Jan 2017, at 17:05, Hannes Wallnöfer  
> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8172006
> Webrev: http://cr.openjdk.java.net/~hannesw/8172006/webrev.00/
> 
> The final invocation of linkerServices.filterInternalObjects was redundant, 
> and in fact caused the argument to be converted to ScripObjectMirror when the 
> actual target type was java.util.List. As far as I can tell, 
> linkerServices.filterInternalObjects is called elsewhere for all types of 
> invocations. Existing tests pass, and I added a few more.
> 
> Thanks,
> Hannes

Re: RFR: 8166186: ClassCastException with arguments usage

[Attila Szegedi]

+1

> On 24 Jan 2017, at 15:31, Hannes Wallnöfer  
> wrote:
> 
> Please review:
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8166186
> webrev: http://cr.openjdk.java.net/~hannesw/8166186/webrev.00/
> 
> The problem was that guards for non-strict functions sometimes have a 
> this-object parameter which also needs to be unpacked, inserted, or wrapped 
> when called via Function.prototype.apply.
> 
> This also includes a patch for types contributed by Ahmed Ashour.
> 
> Thanks,
> Hannes

Re: RFR: 8166187: Regression: NPE during reparse when using persistent code cache and optimistic types

[Attila Szegedi]

+1

> On 10 Jan 2017, at 15:50, Hannes Wallnöfer <hannes.wallnoe...@oracle.com> 
> wrote:
> 
> I just realized I used the wrong bug id for the second webrev linked below. 
> Here’s the webrev again, with the correct id:
> 
> http://cr.openjdk.java.net/~hannesw/8166187/webrev.01/
> 
> Hannes
> 
>> Am 23.12.2016 um 12:20 schrieb Hannes Wallnöfer 
>> <hannes.wallnoe...@oracle.com>:
>> 
>> Thanks Attila, I had forgotten cached AST is not just a performance feature.
>> 
>> I uploaded a new webrev. It pretty much follows your suggestions, except I 
>> used a slightly different approach to conditional serialization of cachedAst 
>> - I left the field transient and serialize it explicitly if it is an 
>> instance of SerializedAst, otherwise write out null. I also added a test 
>> case for split stored functions.
>> 
>> http://cr.openjdk.java.net/~hannesw/8170977/webrev.01/ 
>> 
>> Hannes
>> 
>> 
>>> Am 22.12.2016 um 16:48 schrieb Attila Szegedi <szege...@gmail.com>:
>>> 
>>> Hm… cachedAst is essential for split functions; specifically if it contains 
>>> a SerializedAst, then its "byte[] serializedAst" field is essential. If 
>>> cachedAst is lost, we can reparse an unsplit function from source, but we 
>>> can’t reparse fragments of split functions.
>>> 
>>> I’d suggest instead of making cachedAst transient, we should:
>>> 1. make SerializedAst Serializable, and have SerializedAst.cachedAst within 
>>> it transient (reference objects aren’t serializable, and we can afford to 
>>> lose it anyway).
>>> 2. introduce RecompilableScriptFunctionData.writeObject and make sure that 
>>> if serializedAst contains a reference (instead of a SerializedAst object) 
>>> then we don’t attempt to serialize it — write null instead (this can be 
>>> accomplished by just setting serializedAst = null, and maybe re-setting it 
>>> back to what it was after defaultWriteObject)
>>> 3. make sure there’s a null check on SerializedAst.cachedAst read in 
>>> getCachedAst() (as now it can actually be null on deserialization, it was 
>>> an invariant that it was never null before)
>>> 
>>> Attila.
>>> 
>>>> On 22 Dec 2016, at 16:18, Hannes Wallnöfer <hannes.wallnoe...@oracle.com> 
>>>> wrote:
>>>> 
>>>> Please review: 
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166187
>>>> Webrev: http://cr.openjdk.java.net/~hannesw/8166187/webrev/
>>>> 
>>>> It was actually the combination of having a non-serialisable AST reference 
>>>> and not initialising the transient fields of nested functions that caused 
>>>> this error.
>>>> 
>>>> Thanks,
>>>> Hannes
>>> 
>> 
> 

Re: RFR 8164391: Provide a javadoc description for jdk.scripting.nashorn

[Attila Szegedi]

+1

> On 04 Jan 2017, at 11:40, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8164391/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8164391
> 
> Thanks,
> -Sundar

Re: RFR 8172183: Provide a javadoc description for jdk.dynalink module

[Attila Szegedi]

+1

Thanks!

Attila.

> On 03 Jan 2017, at 17:37, Sundararajan Athijegannathan 
> <sundararajan.athijegannat...@oracle.com> wrote:
> 
> Updated: http://cr.openjdk.java.net/~sundar/8172183/webrev.02/
> 
> Thanks
> -Sundar
> 
> On 03/01/17, 9:33 PM, Attila Szegedi wrote:
>> My preference would be to move all the prose from package-info.java to 
>> module-info.java.
>> 
>> At the time I wrote the documentation, I didn't consider module-info as it 
>> wasn’t picked up by javadoc back then, so the entry point into the 
>> documentation was the top-level packaage’s package-info. The intent of all 
>> of it, though, is to act as a comprehensive overview of Dynalink. It works 
>> best as a single unit of prose. My recommendation would be to move all of 
>> text in package-info to module-info (presumably, module-info also can 
>> contain links etc.), and only leave that one-sentence description you just 
>> added in package-info.
>> 
>> Thanks,
>>   Attila.
>> 
>>> On 03 Jan 2017, at 16:04, Sundararajan 
>>> Athijegannathan<sundararajan.athijegannat...@oracle.com>  wrote:
>>> 
>>> Fixed. Updated webrev: http://cr.openjdk.java.net/~sundar/8172183/webrev.01/
>>> 
>>> Thanks,
>>> -Sundar
>>> 
>>> On 03/01/17, 7:37 PM, Sundararajan Athijegannathan wrote:
>>>> Thanks Attila.
>>>> 
>>>> I'll fix that article. Can I consider your comment as a review?
>>>> 
>>>> Thanks,
>>>> -Sundar
>>>> 
>>>> On 03/01/17, 6:38 PM, Attila Szegedi wrote:
>>>>> + * Contains interfaces and classes that are used to link a {@code 
>>>>> invokedynamic} call site.
>>>>> 
>>>>> should be “an” invokedynamic call site.
>>>>> 
>>>>> Attila.
>>>>> 
>>>>>> On 03 Jan 2017, at 06:17, Sundararajan 
>>>>>> Athijegannathan<sundararajan.athijegannat...@oracle.com>   wrote:
>>>>>> 
>>>>>> Please review http://cr.openjdk.java.net/~sundar/8172183/webrev.00/ for 
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8172183
>>>>>> 
>>>>>> Piggybacking couple of README cleanups in nashorn repo.
>>>>>> 
>>>>>> Thanks,
>>>>>> -Sundar

Re: RFR 8172183: Provide a javadoc description for jdk.dynalink module

[Attila Szegedi]

My preference would be to move all the prose from package-info.java to 
module-info.java. 

At the time I wrote the documentation, I didn't consider module-info as it 
wasn’t picked up by javadoc back then, so the entry point into the 
documentation was the top-level packaage’s package-info. The intent of all of 
it, though, is to act as a comprehensive overview of Dynalink. It works best as 
a single unit of prose. My recommendation would be to move all of text in 
package-info to module-info (presumably, module-info also can contain links 
etc.), and only leave that one-sentence description you just added in 
package-info.

Thanks,
  Attila.

> On 03 Jan 2017, at 16:04, Sundararajan Athijegannathan 
> <sundararajan.athijegannat...@oracle.com> wrote:
> 
> Fixed. Updated webrev: http://cr.openjdk.java.net/~sundar/8172183/webrev.01/
> 
> Thanks,
> -Sundar
> 
> On 03/01/17, 7:37 PM, Sundararajan Athijegannathan wrote:
>> Thanks Attila.
>> 
>> I'll fix that article. Can I consider your comment as a review?
>> 
>> Thanks,
>> -Sundar
>> 
>> On 03/01/17, 6:38 PM, Attila Szegedi wrote:
>>> + * Contains interfaces and classes that are used to link a {@code 
>>> invokedynamic} call site.
>>> 
>>> should be “an” invokedynamic call site.
>>> 
>>> Attila.
>>> 
>>>> On 03 Jan 2017, at 06:17, Sundararajan 
>>>> Athijegannathan<sundararajan.athijegannat...@oracle.com>  wrote:
>>>> 
>>>> Please review http://cr.openjdk.java.net/~sundar/8172183/webrev.00/ for 
>>>> https://bugs.openjdk.java.net/browse/JDK-8172183
>>>> 
>>>> Piggybacking couple of README cleanups in nashorn repo.
>>>> 
>>>> Thanks,
>>>> -Sundar

Re: RFR 8172183: Provide a javadoc description for jdk.dynalink module

[Attila Szegedi]

+ * Contains interfaces and classes that are used to link a {@code 
invokedynamic} call site.

should be “an” invokedynamic call site.

Attila.

> On 03 Jan 2017, at 06:17, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8172183/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8172183
> 
> Piggybacking couple of README cleanups in nashorn repo.
> 
> Thanks,
> -Sundar

Re: RFR: 8170781: PropertyMapIterator throws NoSuchElementException on last element

[Attila Szegedi]

+1 from me.

Attila.

On Fri, Dec 23, 2016 at 15:57 Sundararajan Athijegannathan <
sundararajan.athijegannat...@oracle.com> wrote:

> Because this is a java test, you can add jtreg declarations (you may
>
> want to check other tests with @bug, @test comments under test/src) to
>
> enable this test for jtreg mode.
>
>
>
> Other than that, +1
>
>
>
> -Sundar
>
>
>
> On 23/12/16, 7:06 PM, Hannes Wallnöfer wrote:
>
> > Please review:
>
> >
>
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8170781
>
> > Webrev: http://cr.openjdk.java.net/~hannesw/8170781/webrev/
>
> >
>
> > Thanks,
>
> > Hannes
>
>