From 1655362684 at qq.com  Mon Nov  2 02:49:50 2020
From: 1655362684 at qq.com (ruanzhi)
Date: Sun, 1 Nov 2020 19:49:50 -0700 (MST)
Subject: java.lang.NoSuchMethodException: No such function
Message-ID: <1604285390976-0.post@n7.nabble.com>

 I recently found a strange problem, I used code similar to the following in
the project:
 public static void main(String[] args) throws ScriptException,
NoSuchMethodException {
        ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
        ScriptEngine engine =
scriptEngineManager.getEngineByName("nashorn");
        Compilable ce = (Compilable) engine;
        CompiledScript cs;
        try {
            String script = "function f1602838289254hw9b() {\n" +
                    "var responses =
JSON.parse(org.example.MockHttpUtils.sendGetRequest([{\n" +
                    "url:'https://rz.xx.com/test',\n" +
                    "params: {\n" +
                    "id: 0,\n" +
                    "// uuid\n" +
                    "uuid:1,\n" +
                    "styleid: \")\",\n" +
                    "// styleId\n" +
                    "templateid: 0 // backend templateId\n" +
                    "}\n" +
                    "}]));\n" +
                    "var e = responses[2]\n" +
                    "return responses\n" +
                    "}";
            ce.compile(script);
            engine.eval(script);
        } catch (Exception e) {
            e.printStackTrace();
        }
        System.out.println(JSON.toJSONString(((Invocable)
engine).invokeFunction("f1602838289254hw9b")));
    }

I first perform a pre-compilation, and then I will execute the js script
logic by calling function, but it can compile normally, but when the
invokeFunction is executed, the method name is passed in, and an error is
reported: java.lang.NoSuchMethodException: No such function
I re-compile it again, and invokeFunction can be executed normally.
I don't know what caused this, and this problem seems to be unable to
reproduce stably.
Another curious point is why the invokeFunction method needs to be executed
first after the evel method is executed. What do compile and eval do below?
 ScriptEngine engine = scriptEngineManager.getEngineByName("nashorn");
        Compilable ce = (Compilable) engine;
 ce.compile(script);
 engine.eval(script);

I understand that compile has done everything and can directly execute
invokeFunction.



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

From szegedia at gmail.com  Sun Nov 15 17:25:55 2020
From: szegedia at gmail.com (Attila Szegedi)
Date: Sun, 15 Nov 2020 18:25:55 +0100
Subject: Standalone Nashorn is coming for Java 15+
In-Reply-To: <A8C36122-4AA0-4F73-AE23-17C4B3C123C8@gmail.com>
References: <2C7141B6-B170-42E8-809B-6E642EAD0CD7@gmail.com>
 <0C46B001-12D8-4BE0-B0B5-4715B9BCEC66@gmail.com>
 <A8C36122-4AA0-4F73-AE23-17C4B3C123C8@gmail.com>
Message-ID: <C19A9CE6-0F3A-4A52-8E5B-821F9460B4EF@gmail.com>

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 <szegedia at gmail.com> 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 <szegedia at gmail.com> 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 ?<eval>? as their script name and anonymous functions no longer report ?<anonymous>? 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 <szegedia at gmail.com> 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 (<nashorn-dev at openjdk.java.net>).
>>> 
>>> * A GitHub project openjdk/nashorn will be set up. It will be populated by a clone of the openjdk/jdk14u repo that has been filtered for  Nashorn-only commits. (Thanks, git-filter-repo[2], you are awesome!) There will be no synchronization back to jdk14u afterwards, it won't act as an upstream. openjdk/nashorn proceeds independently from that point on.
>>> 
>>> * The project will change the module and package names as it can't keep living within the top-level "jdk." package. In accordance with other independently-developed OpenJDK projects, it will transition to module and package names within the "org.openjdk." package. Fortunately for Nashorn, it is mostly used through the "javax.script.*" APIs so people that use it through those APIs won't have to adapt their code. Creating the engine by name as described in Nashorn?s last (JDK 14) API docs[3] will continue to work. People that used to use the Nashorn-specific API (typically, AbstractJSObject and ScriptObjectMirror) will need to adapt their code for new package names, though.
>>> 
>>> * Project artifacts (in plain English: JAR file to be used with Maven etc.) will be published on SonaType under the "org.openjdk" organization, again similar to other independently-developed OpenJDK projects.
>>> 
>>> The goal for the initial release is to ship a standalone Nashorn with identical functionality to that in JDK 14, with the only changes being:
>>> 
>>> * reversing of deprecation and ?scheduled for removal? notices,
>>> * enacting the package and module name changes,
>>> * replacing or removing dependencies on various jdk.internal.* packages since those are no longer exported from JDK modules to the Nashorn module.
>>> 
>>> It is possible for expediency that we will decide to ship Nashorn as a library first, and separately ship the initial version of the jjs shell sometime later.
>>> 
>>> I?m personally undertaking these initial tasks. I will let you know here on the list about the progress, and once the repo is set up the work will also start appearing on a branch.
>>> 
>>> There are some other aspects of the project that need to be worked out: contribution and review guidelines, publication location of the accompanying documentation (that will no longer be part of the JDK documentation) and so on. I will post discussion-initiating e-mails for these as well as time comes and will absolutely welcome feedback on them, just as I welcome feedback on this plan too.
>>> 
>>> Attila.
>>> 
>>> --
>>> [1] https://openjdk.java.net/projects/nashorn/
>>> [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
>> 
> 


From szegedia at gmail.com  Mon Nov 16 21:06:30 2020
From: szegedia at gmail.com (Attila Szegedi)
Date: Mon, 16 Nov 2020 22:06:30 +0100
Subject: Standalone Nashorn is coming for Java 15+
In-Reply-To: <C19A9CE6-0F3A-4A52-8E5B-821F9460B4EF@gmail.com>
References: <2C7141B6-B170-42E8-809B-6E642EAD0CD7@gmail.com>
 <0C46B001-12D8-4BE0-B0B5-4715B9BCEC66@gmail.com>
 <A8C36122-4AA0-4F73-AE23-17C4B3C123C8@gmail.com>
 <C19A9CE6-0F3A-4A52-8E5B-821F9460B4EF@gmail.com>
Message-ID: <C3371057-218D-4C37-94DE-C26C70F11DF2@gmail.com>

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 <szegedia at gmail.com> 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 <szegedia at gmail.com> 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 <szegedia at gmail.com> 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 ?<eval>? as their script name and anonymous functions no longer report ?<anonymous>? 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 <szegedia at gmail.com> 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 (<nashorn-dev at openjdk.java.net>).
>>>> 
>>>> * A GitHub project openjdk/nashorn will be set up. It will be populated by a clone of the openjdk/jdk14u repo that has been filtered for  Nashorn-only commits. (Thanks, git-filter-repo[2], you are awesome!) There will be no synchronization back to jdk14u afterwards, it won't act as an upstream. openjdk/nashorn proceeds independently from that point on.
>>>> 
>>>> * The project will change the module and package names as it can't keep living within the top-level "jdk." package. In accordance with other independently-developed OpenJDK projects, it will transition to module and package names within the "org.openjdk." package. Fortunately for Nashorn, it is mostly used through the "javax.script.*" APIs so people that use it through those APIs won't have to adapt their code. Creating the engine by name as described in Nashorn?s last (JDK 14) API docs[3] will continue to work. People that used to use the Nashorn-specific API (typically, AbstractJSObject and ScriptObjectMirror) will need to adapt their code for new package names, though.
>>>> 
>>>> * Project artifacts (in plain English: JAR file to be used with Maven etc.) will be published on SonaType under the "org.openjdk" organization, again similar to other independently-developed OpenJDK projects.
>>>> 
>>>> The goal for the initial release is to ship a standalone Nashorn with identical functionality to that in JDK 14, with the only changes being:
>>>> 
>>>> * reversing of deprecation and ?scheduled for removal? notices,
>>>> * enacting the package and module name changes,
>>>> * replacing or removing dependencies on various jdk.internal.* packages since those are no longer exported from JDK modules to the Nashorn module.
>>>> 
>>>> It is possible for expediency that we will decide to ship Nashorn as a library first, and separately ship the initial version of the jjs shell sometime later.
>>>> 
>>>> I?m personally undertaking these initial tasks. I will let you know here on the list about the progress, and once the repo is set up the work will also start appearing on a branch.
>>>> 
>>>> There are some other aspects of the project that need to be worked out: contribution and review guidelines, publication location of the accompanying documentation (that will no longer be part of the JDK documentation) and so on. I will post discussion-initiating e-mails for these as well as time comes and will absolutely welcome feedback on them, just as I welcome feedback on this plan too.
>>>> 
>>>> Attila.
>>>> 
>>>> --
>>>> [1] https://openjdk.java.net/projects/nashorn/
>>>> [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
>>> 
>> 
> 


From benjamin.john.evans at gmail.com  Tue Nov 17 09:37:13 2020
From: benjamin.john.evans at gmail.com (Ben Evans)
Date: Tue, 17 Nov 2020 10:37:13 +0100
Subject: Standalone Nashorn is coming for Java 15+
In-Reply-To: <C19A9CE6-0F3A-4A52-8E5B-821F9460B4EF@gmail.com>
References: <2C7141B6-B170-42E8-809B-6E642EAD0CD7@gmail.com>
 <0C46B001-12D8-4BE0-B0B5-4715B9BCEC66@gmail.com>
 <A8C36122-4AA0-4F73-AE23-17C4B3C123C8@gmail.com>
 <C19A9CE6-0F3A-4A52-8E5B-821F9460B4EF@gmail.com>
Message-ID: <CABKW8RgRrsUt7ZBe0pPKCY=qJ_hJq72FBoAb922V-1c+mrbZdg@mail.gmail.com>

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 <szegedia at gmail.com> 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 <szegedia at gmail.com> 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 <szegedia at gmail.com> 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 ?<eval>? as their script name and anonymous functions no longer report ?<anonymous>? 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 <szegedia at gmail.com> 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 (<nashorn-dev at openjdk.java.net>).
> >>>
> >>> * A GitHub project openjdk/nashorn will be set up. It will be populated by a clone of the openjdk/jdk14u repo that has been filtered for  Nashorn-only commits. (Thanks, git-filter-repo[2], you are awesome!) There will be no synchronization back to jdk14u afterwards, it won't act as an upstream. openjdk/nashorn proceeds independently from that point on.
> >>>
> >>> * The project will change the module and package names as it can't keep living within the top-level "jdk." package. In accordance with other independently-developed OpenJDK projects, it will transition to module and package names within the "org.openjdk." package. Fortunately for Nashorn, it is mostly used through the "javax.script.*" APIs so people that use it through those APIs won't have to adapt their code. Creating the engine by name as described in Nashorn?s last (JDK 14) API docs[3] will continue to work. People that used to use the Nashorn-specific API (typically, AbstractJSObject and ScriptObjectMirror) will need to adapt their code for new package names, though.
> >>>
> >>> * Project artifacts (in plain English: JAR file to be used with Maven etc.) will be published on SonaType under the "org.openjdk" organization, again similar to other independently-developed OpenJDK projects.
> >>>
> >>> The goal for the initial release is to ship a standalone Nashorn with identical functionality to that in JDK 14, with the only changes being:
> >>>
> >>> * reversing of deprecation and ?scheduled for removal? notices,
> >>> * enacting the package and module name changes,
> >>> * replacing or removing dependencies on various jdk.internal.* packages since those are no longer exported from JDK modules to the Nashorn module.
> >>>
> >>> It is possible for expediency that we will decide to ship Nashorn as a library first, and separately ship the initial version of the jjs shell sometime later.
> >>>
> >>> I?m personally undertaking these initial tasks. I will let you know here on the list about the progress, and once the repo is set up the work will also start appearing on a branch.
> >>>
> >>> There are some other aspects of the project that need to be worked out: contribution and review guidelines, publication location of the accompanying documentation (that will no longer be part of the JDK documentation) and so on. I will post discussion-initiating e-mails for these as well as time comes and will absolutely welcome feedback on them, just as I welcome feedback on this plan too.
> >>>
> >>> Attila.
> >>>
> >>> --
> >>> [1] https://openjdk.java.net/projects/nashorn/
> >>> [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
> >>
> >
>

From issaria at gmail.com  Tue Nov 17 11:50:42 2020
From: issaria at gmail.com (Isaiah Peng)
Date: Tue, 17 Nov 2020 12:50:42 +0100
Subject: Standalone Nashorn is coming for Java 15+
In-Reply-To: <CABKW8RgRrsUt7ZBe0pPKCY=qJ_hJq72FBoAb922V-1c+mrbZdg@mail.gmail.com>
References: <2C7141B6-B170-42E8-809B-6E642EAD0CD7@gmail.com>
 <0C46B001-12D8-4BE0-B0B5-4715B9BCEC66@gmail.com>
 <A8C36122-4AA0-4F73-AE23-17C4B3C123C8@gmail.com>
 <C19A9CE6-0F3A-4A52-8E5B-821F9460B4EF@gmail.com>
 <CABKW8RgRrsUt7ZBe0pPKCY=qJ_hJq72FBoAb922V-1c+mrbZdg@mail.gmail.com>
Message-ID: <CAFxYmVpg_E-o8mK823L2chJvZfdwYCPSHD-ayGBms0Zb=dC9Qg@mail.gmail.com>

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 <benjamin.john.evans at gmail.com> ? 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 <szegedia at gmail.com> 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 <szegedia at gmail.com> 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 <szegedia at gmail.com>
> 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 ?<eval>? as their
> script name and anonymous functions no longer report ?<anonymous>? 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 <szegedia at gmail.com>
> 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 (<
> nashorn-dev at openjdk.java.net>).
> > >>>
> > >>> * A GitHub project openjdk/nashorn will be set up. It will be
> populated by a clone of the openjdk/jdk14u repo that has been filtered for
> Nashorn-only commits. (Thanks, git-filter-repo[2], you are awesome!) There
> will be no synchronization back to jdk14u afterwards, it won't act as an
> upstream. openjdk/nashorn proceeds independently from that point on.
> > >>>
> > >>> * The project will change the module and package names as it can't
> keep living within the top-level "jdk." package. In accordance with other
> independently-developed OpenJDK projects, it will transition to module and
> package names within the "org.openjdk." package. Fortunately for Nashorn,
> it is mostly used through the "javax.script.*" APIs so people that use it
> through those APIs won't have to adapt their code. Creating the engine by
> name as described in Nashorn?s last (JDK 14) API docs[3] will continue to
> work. People that used to use the Nashorn-specific API (typically,
> AbstractJSObject and ScriptObjectMirror) will need to adapt their code for
> new package names, though.
> > >>>
> > >>> * Project artifacts (in plain English: JAR file to be used with
> Maven etc.) will be published on SonaType under the "org.openjdk"
> organization, again similar to other independently-developed OpenJDK
> projects.
> > >>>
> > >>> The goal for the initial release is to ship a standalone Nashorn
> with identical functionality to that in JDK 14, with the only changes being:
> > >>>
> > >>> * reversing of deprecation and ?scheduled for removal? notices,
> > >>> * enacting the package and module name changes,
> > >>> * replacing or removing dependencies on various jdk.internal.*
> packages since those are no longer exported from JDK modules to the Nashorn
> module.
> > >>>
> > >>> It is possible for expediency that we will decide to ship Nashorn as
> a library first, and separately ship the initial version of the jjs shell
> sometime later.
> > >>>
> > >>> I?m personally undertaking these initial tasks. I will let you know
> here on the list about the progress, and once the repo is set up the work
> will also start appearing on a branch.
> > >>>
> > >>> There are some other aspects of the project that need to be worked
> out: contribution and review guidelines, publication location of the
> accompanying documentation (that will no longer be part of the JDK
> documentation) and so on. I will post discussion-initiating e-mails for
> these as well as time comes and will absolutely welcome feedback on them,
> just as I welcome feedback on this plan too.
> > >>>
> > >>> Attila.
> > >>>
> > >>> --
> > >>> [1] https://openjdk.java.net/projects/nashorn/
> > >>> [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
> > >>
> > >
> >
>

From benjamin.john.evans at gmail.com  Tue Nov 17 11:53:59 2020
From: benjamin.john.evans at gmail.com (Ben Evans)
Date: Tue, 17 Nov 2020 12:53:59 +0100
Subject: Standalone Nashorn is coming for Java 15+
In-Reply-To: <CAFxYmVpg_E-o8mK823L2chJvZfdwYCPSHD-ayGBms0Zb=dC9Qg@mail.gmail.com>
References: <2C7141B6-B170-42E8-809B-6E642EAD0CD7@gmail.com>
 <0C46B001-12D8-4BE0-B0B5-4715B9BCEC66@gmail.com>
 <A8C36122-4AA0-4F73-AE23-17C4B3C123C8@gmail.com>
 <C19A9CE6-0F3A-4A52-8E5B-821F9460B4EF@gmail.com>
 <CABKW8RgRrsUt7ZBe0pPKCY=qJ_hJq72FBoAb922V-1c+mrbZdg@mail.gmail.com>
 <CAFxYmVpg_E-o8mK823L2chJvZfdwYCPSHD-ayGBms0Zb=dC9Qg@mail.gmail.com>
Message-ID: <CABKW8RgQx3CwvAuUL7KjE_8eUcvinDjhkaj5uYcBSgnx4eYdcA@mail.gmail.com>

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 <issaria at gmail.com> 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 <benjamin.john.evans at gmail.com> ? 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 <szegedia at gmail.com> 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 <szegedia at gmail.com> 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 <szegedia at gmail.com> 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 ?<eval>? as their script name and anonymous functions no longer report ?<anonymous>? 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 <szegedia at gmail.com> 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 (<nashorn-dev at openjdk.java.net>).
>> > >>>
>> > >>> * A GitHub project openjdk/nashorn will be set up. It will be populated by a clone of the openjdk/jdk14u repo that has been filtered for  Nashorn-only commits. (Thanks, git-filter-repo[2], you are awesome!) There will be no synchronization back to jdk14u afterwards, it won't act as an upstream. openjdk/nashorn proceeds independently from that point on.
>> > >>>
>> > >>> * The project will change the module and package names as it can't keep living within the top-level "jdk." package. In accordance with other independently-developed OpenJDK projects, it will transition to module and package names within the "org.openjdk." package. Fortunately for Nashorn, it is mostly used through the "javax.script.*" APIs so people that use it through those APIs won't have to adapt their code. Creating the engine by name as described in Nashorn?s last (JDK 14) API docs[3] will continue to work. People that used to use the Nashorn-specific API (typically, AbstractJSObject and ScriptObjectMirror) will need to adapt their code for new package names, though.
>> > >>>
>> > >>> * Project artifacts (in plain English: JAR file to be used with Maven etc.) will be published on SonaType under the "org.openjdk" organization, again similar to other independently-developed OpenJDK projects.
>> > >>>
>> > >>> The goal for the initial release is to ship a standalone Nashorn with identical functionality to that in JDK 14, with the only changes being:
>> > >>>
>> > >>> * reversing of deprecation and ?scheduled for removal? notices,
>> > >>> * enacting the package and module name changes,
>> > >>> * replacing or removing dependencies on various jdk.internal.* packages since those are no longer exported from JDK modules to the Nashorn module.
>> > >>>
>> > >>> It is possible for expediency that we will decide to ship Nashorn as a library first, and separately ship the initial version of the jjs shell sometime later.
>> > >>>
>> > >>> I?m personally undertaking these initial tasks. I will let you know here on the list about the progress, and once the repo is set up the work will also start appearing on a branch.
>> > >>>
>> > >>> There are some other aspects of the project that need to be worked out: contribution and review guidelines, publication location of the accompanying documentation (that will no longer be part of the JDK documentation) and so on. I will post discussion-initiating e-mails for these as well as time comes and will absolutely welcome feedback on them, just as I welcome feedback on this plan too.
>> > >>>
>> > >>> Attila.
>> > >>>
>> > >>> --
>> > >>> [1] https://openjdk.java.net/projects/nashorn/
>> > >>> [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
>> > >>
>> > >
>> >

From szegedia at gmail.com  Tue Nov 17 13:18:42 2020
From: szegedia at gmail.com (Attila Szegedi)
Date: Tue, 17 Nov 2020 14:18:42 +0100
Subject: Standalone Nashorn is coming for Java 15+
In-Reply-To: <CABKW8RgQx3CwvAuUL7KjE_8eUcvinDjhkaj5uYcBSgnx4eYdcA@mail.gmail.com>
References: <2C7141B6-B170-42E8-809B-6E642EAD0CD7@gmail.com>
 <0C46B001-12D8-4BE0-B0B5-4715B9BCEC66@gmail.com>
 <A8C36122-4AA0-4F73-AE23-17C4B3C123C8@gmail.com>
 <C19A9CE6-0F3A-4A52-8E5B-821F9460B4EF@gmail.com>
 <CABKW8RgRrsUt7ZBe0pPKCY=qJ_hJq72FBoAb922V-1c+mrbZdg@mail.gmail.com>
 <CAFxYmVpg_E-o8mK823L2chJvZfdwYCPSHD-ayGBms0Zb=dC9Qg@mail.gmail.com>
 <CABKW8RgQx3CwvAuUL7KjE_8eUcvinDjhkaj5uYcBSgnx4eYdcA@mail.gmail.com>
Message-ID: <787D96B2-728D-4F00-8907-1749A4AFACF1@gmail.com>

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 <benjamin.john.evans at gmail.com> 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 <issaria at gmail.com> 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 <benjamin.john.evans at gmail.com> ? 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 <szegedia at gmail.com> 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 <szegedia at gmail.com> 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 <szegedia at gmail.com> 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 ?<eval>? as their script name and anonymous functions no longer report ?<anonymous>? 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 <szegedia at gmail.com> 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 (<nashorn-dev at openjdk.java.net>).
>>>>>>> 
>>>>>>> * A GitHub project openjdk/nashorn will be set up. It will be populated by a clone of the openjdk/jdk14u repo that has been filtered for  Nashorn-only commits. (Thanks, git-filter-repo[2], you are awesome!) There will be no synchronization back to jdk14u afterwards, it won't act as an upstream. openjdk/nashorn proceeds independently from that point on.
>>>>>>> 
>>>>>>> * The project will change the module and package names as it can't keep living within the top-level "jdk." package. In accordance with other independently-developed OpenJDK projects, it will transition to module and package names within the "org.openjdk." package. Fortunately for Nashorn, it is mostly used through the "javax.script.*" APIs so people that use it through those APIs won't have to adapt their code. Creating the engine by name as described in Nashorn?s last (JDK 14) API docs[3] will continue to work. People that used to use the Nashorn-specific API (typically, AbstractJSObject and ScriptObjectMirror) will need to adapt their code for new package names, though.
>>>>>>> 
>>>>>>> * Project artifacts (in plain English: JAR file to be used with Maven etc.) will be published on SonaType under the "org.openjdk" organization, again similar to other independently-developed OpenJDK projects.
>>>>>>> 
>>>>>>> The goal for the initial release is to ship a standalone Nashorn with identical functionality to that in JDK 14, with the only changes being:
>>>>>>> 
>>>>>>> * reversing of deprecation and ?scheduled for removal? notices,
>>>>>>> * enacting the package and module name changes,
>>>>>>> * replacing or removing dependencies on various jdk.internal.* packages since those are no longer exported from JDK modules to the Nashorn module.
>>>>>>> 
>>>>>>> It is possible for expediency that we will decide to ship Nashorn as a library first, and separately ship the initial version of the jjs shell sometime later.
>>>>>>> 
>>>>>>> I?m personally undertaking these initial tasks. I will let you know here on the list about the progress, and once the repo is set up the work will also start appearing on a branch.
>>>>>>> 
>>>>>>> There are some other aspects of the project that need to be worked out: contribution and review guidelines, publication location of the accompanying documentation (that will no longer be part of the JDK documentation) and so on. I will post discussion-initiating e-mails for these as well as time comes and will absolutely welcome feedback on them, just as I welcome feedback on this plan too.
>>>>>>> 
>>>>>>> Attila.
>>>>>>> 
>>>>>>> --
>>>>>>> [1] https://openjdk.java.net/projects/nashorn/
>>>>>>> [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
>>>>>> 
>>>>> 
>>>> 


From jmansfield at cadixdev.org  Sat Nov 21 17:53:52 2020
From: jmansfield at cadixdev.org (Jamie Mansfield)
Date: Sat, 21 Nov 2020 17:53:52 +0000
Subject: Standalone Nashorn is coming for Java 15+
Message-ID: <2050099.irdbgypaU6@claude>

Hey ;)

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

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

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

Regards,
Jamie

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



From Rony.Flatscher at wu.ac.at  Mon Nov 23 16:20:16 2020
From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher)
Date: Mon, 23 Nov 2020 17:20:16 +0100
Subject: Fix for NashornScriptEngineFactory.getOutputStatement(toDisplay) (Re:
 Standalone Nashorn is coming for Java 15+
In-Reply-To: <C19A9CE6-0F3A-4A52-8E5B-821F9460B4EF@gmail.com>
References: <2C7141B6-B170-42E8-809B-6E642EAD0CD7@gmail.com>
 <0C46B001-12D8-4BE0-B0B5-4715B9BCEC66@gmail.com>
 <A8C36122-4AA0-4F73-AE23-17C4B3C123C8@gmail.com>
 <C19A9CE6-0F3A-4A52-8E5B-821F9460B4EF@gmail.com>
Message-ID: <a6315312-dcce-6404-90d3-7fdaee2711ac@wu.ac.at>

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 <szegedia at gmail.com> 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 <szegedia at gmail.com> 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 ?<eval>? as their script name and anonymous functions no longer report ?<anonymous>? 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 <szegedia at gmail.com> 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 (<nashorn-dev at openjdk.java.net>).
>>>>
>>>> * A GitHub project openjdk/nashorn will be set up. It will be populated by a clone of the openjdk/jdk14u repo that has been filtered for  Nashorn-only commits. (Thanks, git-filter-repo[2], you are awesome!) There will be no synchronization back to jdk14u afterwards, it won't act as an upstream. openjdk/nashorn proceeds independently from that point on.
>>>>
>>>> * The project will change the module and package names as it can't keep living within the top-level "jdk." package. In accordance with other independently-developed OpenJDK projects, it will transition to module and package names within the "org.openjdk." package. Fortunately for Nashorn, it is mostly used through the "javax.script.*" APIs so people that use it through those APIs won't have to adapt their code. Creating the engine by name as described in Nashorn?s last (JDK 14) API docs[3] will continue to work. People that used to use the Nashorn-specific API (typically, AbstractJSObject and ScriptObjectMirror) will need to adapt their code for new package names, though.
>>>>
>>>> * Project artifacts (in plain English: JAR file to be used with Maven etc.) will be published on SonaType under the "org.openjdk" organization, again similar to other independently-developed OpenJDK projects.
>>>>
>>>> The goal for the initial release is to ship a standalone Nashorn with identical functionality to that in JDK 14, with the only changes being:
>>>>
>>>> * reversing of deprecation and ?scheduled for removal? notices,
>>>> * enacting the package and module name changes,
>>>> * replacing or removing dependencies on various jdk.internal.* packages since those are no longer exported from JDK modules to the Nashorn module.
>>>>
>>>> It is possible for expediency that we will decide to ship Nashorn as a library first, and separately ship the initial version of the jjs shell sometime later.
>>>>
>>>> I?m personally undertaking these initial tasks. I will let you know here on the list about the progress, and once the repo is set up the work will also start appearing on a branch.
>>>>
>>>> There are some other aspects of the project that need to be worked out: contribution and review guidelines, publication location of the accompanying documentation (that will no longer be part of the JDK documentation) and so on. I will post discussion-initiating e-mails for these as well as time comes and will absolutely welcome feedback on them, just as I welcome feedback on this plan too.
>>>>
>>>> Attila.
>>>>
>>>> --
>>>> [1] https://openjdk.java.net/projects/nashorn/
>>>> [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


From Thomas.BURRIS at 3ds.com  Mon Nov 23 16:32:11 2020
From: Thomas.BURRIS at 3ds.com (BURRIS Thomas)
Date: Mon, 23 Nov 2020 16:32:11 +0000
Subject: Standalone Nashorn bound to specific JVM flavors?
Message-ID: <e381f41369924e609674b2c802a2c52e@3ds.com>

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&D Software Architecture Director





Office: +1 78 1810 3718
Mobile: +1 61 7678 9158
thomas.burris at 3ds.com<mailto:Thomas.BURRIS at 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-privacy at 3ds.com<mailto:3DS.compliance-privacy at 3ds.com>


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

From szegedia at gmail.com  Mon Nov 23 16:58:30 2020
From: szegedia at gmail.com (Attila Szegedi)
Date: Mon, 23 Nov 2020 17:58:30 +0100
Subject: Standalone Nashorn bound to specific JVM flavors?
In-Reply-To: <e381f41369924e609674b2c802a2c52e@3ds.com>
References: <e381f41369924e609674b2c802a2c52e@3ds.com>
Message-ID: <49C78523-BCB6-4CB3-B564-C728C48D51E3@gmail.com>

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 <Thomas.BURRIS at 3ds.com> 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&D Software Architecture Director
> 
> 
> 
> 
> 
> Office: +1 78 1810 3718
> Mobile: +1 61 7678 9158
> thomas.burris at 3ds.com<mailto:Thomas.BURRIS at 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-privacy at 3ds.com<mailto:3DS.compliance-privacy at 3ds.com>
> 
> 
> For other languages, go to https://www.3ds.com/terms/email-disclaimer


From Thomas.BURRIS at 3ds.com  Mon Nov 23 17:32:37 2020
From: Thomas.BURRIS at 3ds.com (BURRIS Thomas)
Date: Mon, 23 Nov 2020 17:32:37 +0000
Subject: Standalone Nashorn bound to specific JVM flavors?
In-Reply-To: <49C78523-BCB6-4CB3-B564-C728C48D51E3@gmail.com>
References: <e381f41369924e609674b2c802a2c52e@3ds.com>
 <49C78523-BCB6-4CB3-B564-C728C48D51E3@gmail.com>
Message-ID: <f6a4a7bc33d64aac9205e550da89ced7@3ds.com>

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&D Software Architecture Director

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



-----Original Message-----
From: Attila Szegedi <szegedia at gmail.com>
Sent: Monday, November 23, 2020 11:59 AM
To: BURRIS Thomas <Thomas.BURRIS at 3ds.com>
Cc: nashorn-dev at 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 <Thomas.BURRIS at 3ds.com> 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&D Software Architecture Director
>
>
>
>
>
> Office: +1 78 1810 3718
> Mobile: +1 61 7678 9158
> thomas.burris at 3ds.com<mailto:Thomas.BURRIS at 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-privacy at 3ds.com<mailto:3DS.compliance-privacy at 3ds.com>
>
>
> For other languages, go to https://www.3ds.com/terms/email-disclaimer

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

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

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

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

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


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


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

From forax at univ-mlv.fr  Mon Nov 23 17:52:23 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 23 Nov 2020 18:52:23 +0100 (CET)
Subject: Standalone Nashorn bound to specific JVM flavors?
In-Reply-To: <f6a4a7bc33d64aac9205e550da89ced7@3ds.com>
References: <e381f41369924e609674b2c802a2c52e@3ds.com>
 <49C78523-BCB6-4CB3-B564-C728C48D51E3@gmail.com>
 <f6a4a7bc33d64aac9205e550da89ced7@3ds.com>
Message-ID: <434113385.812793.1606153943265.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "BURRIS Thomas" <Thomas.BURRIS at 3ds.com>
> ?: "Attila Szegedi" <szegedia at gmail.com>
> Cc: "nashorn-dev" <nashorn-dev at openjdk.java.net>
> Envoy?: Lundi 23 Novembre 2020 18:32:37
> Objet: RE: Standalone Nashorn bound to specific JVM flavors?

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

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

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

regards,
R?mi

> 
> ???????????????????????
> Office: +1 78 1810 3718
> Mobile: +1 61 7678 9158
> thomas.burris at 3ds.com
> http://www.3ds.com/enovia
> ???????????????????????
> DS Americas Corp. | 175 Wyman Street | Waltham, MA 02451 | United States
> 
> 
> 
> -----Original Message-----
> From: Attila Szegedi <szegedia at gmail.com>
> Sent: Monday, November 23, 2020 11:59 AM
> To: BURRIS Thomas <Thomas.BURRIS at 3ds.com>
> Cc: nashorn-dev at 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 <Thomas.BURRIS at 3ds.com> 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&D Software Architecture Director
>>
>>
>>
>>
>>
>> Office: +1 78 1810 3718
>> Mobile: +1 61 7678 9158
>> thomas.burris at 3ds.com<mailto:Thomas.BURRIS at 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-privacy at 3ds.com<mailto:3DS.compliance-privacy at 3ds.com>
>>
>>
>> For other languages, go to https://www.3ds.com/terms/email-disclaimer
> 
> This email and any attachments are intended solely for the use of the individual
> or entity to whom it is addressed and may be confidential and/or privileged.
> 
> If you are not one of the named recipients or have received this email in error,
> 
> (i) you should not read, disclose, or copy it,
> 
> (ii) please notify sender of your receipt by reply email and delete this email
> and all attachments,
> 
> (iii) Dassault Syst?mes does not accept or assume any liability or
> responsibility for any use of or reliance on this email.
> 
> 
> Please be informed that your personal data are processed according to our data
> privacy policy as described on our website. Should you have any questions
> related to personal data protection, please contact 3DS Data Protection Officer
> at 3DS.compliance-privacy at 3ds.com<mailto:3DS.compliance-privacy at 3ds.com>
> 
> 
> For other languages, go to https://www.3ds.com/terms/email-disclaimer

From szegedia at gmail.com  Mon Nov 23 18:40:49 2020
From: szegedia at gmail.com (Attila Szegedi)
Date: Mon, 23 Nov 2020 19:40:49 +0100
Subject: Standalone Nashorn bound to specific JVM flavors?
In-Reply-To: <f6a4a7bc33d64aac9205e550da89ced7@3ds.com>
References: <e381f41369924e609674b2c802a2c52e@3ds.com>
 <49C78523-BCB6-4CB3-B564-C728C48D51E3@gmail.com>
 <f6a4a7bc33d64aac9205e550da89ced7@3ds.com>
Message-ID: <BD98039C-7FAE-4DC0-9ADD-9B3127D72974@gmail.com>

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 <Thomas.BURRIS at 3ds.com> 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&D Software Architecture Director
> 
> ???????????????????????
> Office: +1 78 1810 3718
> Mobile: +1 61 7678 9158
> thomas.burris at 3ds.com
> http://www.3ds.com/enovia
> ???????????????????????
> DS Americas Corp. | 175 Wyman Street | Waltham, MA 02451 | United States
> 
> 
> 
> -----Original Message-----
> From: Attila Szegedi <szegedia at gmail.com>
> Sent: Monday, November 23, 2020 11:59 AM
> To: BURRIS Thomas <Thomas.BURRIS at 3ds.com>
> Cc: nashorn-dev at 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 <Thomas.BURRIS at 3ds.com> 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&D Software Architecture Director
>> 
>> 
>> 
>> 
>> 
>> Office: +1 78 1810 3718
>> Mobile: +1 61 7678 9158
>> thomas.burris at 3ds.com<mailto:Thomas.BURRIS at 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-privacy at 3ds.com<mailto:3DS.compliance-privacy at 3ds.com>
>> 
>> 
>> For other languages, go to https://www.3ds.com/terms/email-disclaimer
> 
> This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.
> 
> If you are not one of the named recipients or have received this email in error,
> 
> (i) you should not read, disclose, or copy it,
> 
> (ii) please notify sender of your receipt by reply email and delete this email and all attachments,
> 
> (iii) Dassault Syst?mes does not accept or assume any liability or responsibility for any use of or reliance on this email.
> 
> 
> Please be informed that your personal data are processed according to our data privacy policy as described on our website. Should you have any questions related to personal data protection, please contact 3DS Data Protection Officer at 3DS.compliance-privacy at 3ds.com<mailto:3DS.compliance-privacy at 3ds.com>
> 
> 
> For other languages, go to https://www.3ds.com/terms/email-disclaimer


From szegedia at gmail.com  Fri Nov 27 18:36:04 2020
From: szegedia at gmail.com (Attila Szegedi)
Date: Fri, 27 Nov 2020 19:36:04 +0100
Subject: Standalone Nashorn 15.0 is out!
Message-ID: <B4A787FE-5C67-49CF-9866-3D3049BFDB31@gmail.com>

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

From nilskp at gmail.com  Fri Nov 27 21:02:41 2020
From: nilskp at gmail.com (Nils Kilden-Pedersen)
Date: Fri, 27 Nov 2020 15:02:41 -0600
Subject: Standalone Nashorn 15.0 is out!
In-Reply-To: <B4A787FE-5C67-49CF-9866-3D3049BFDB31@gmail.com>
References: <B4A787FE-5C67-49CF-9866-3D3049BFDB31@gmail.com>
Message-ID: <CABDULvUuPvd-suJ=xPfXRKcm6N69RoQwR1uLS+4Oek8J2CwFdg@mail.gmail.com>

Congrats! ????

On Fri, Nov 27, 2020 at 12:36 PM Attila Szegedi <szegedia at gmail.com> wrote:

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

From jmansfield at cadixdev.org  Fri Nov 27 21:27:44 2020
From: jmansfield at cadixdev.org (Jamie Mansfield)
Date: Fri, 27 Nov 2020 21:27:44 +0000
Subject: Standalone Nashorn 15.0 is out!
In-Reply-To: <B4A787FE-5C67-49CF-9866-3D3049BFDB31@gmail.com>
References: <B4A787FE-5C67-49CF-9866-3D3049BFDB31@gmail.com>
Message-ID: <2186754.ElGaqSPkdT@claude>

Hey Attila,

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

Best regards,
Jamie



From tonyzakula at gmail.com  Sat Nov 28 00:29:22 2020
From: tonyzakula at gmail.com (Tony Zakula)
Date: Fri, 27 Nov 2020 19:29:22 -0500
Subject: Standalone Nashorn 15.0 is out!
In-Reply-To: <2186754.ElGaqSPkdT@claude>
References: <B4A787FE-5C67-49CF-9866-3D3049BFDB31@gmail.com>
 <2186754.ElGaqSPkdT@claude>
Message-ID: <CAC_sW-ck+_4g7ibhX8NAsmK7vfvRTKDy2QwCzDZNmRunFkW10w@mail.gmail.com>

Congrats and Thank you!

On Fri, Nov 27, 2020 at 4:28 PM Jamie Mansfield <jmansfield at cadixdev.org>
wrote:

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

From sundararajan.athijegannathan at oracle.com  Mon Nov 30 06:27:16 2020
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Mon, 30 Nov 2020 11:57:16 +0530
Subject: Standalone Nashorn 15.0 is out!
In-Reply-To: <B4A787FE-5C67-49CF-9866-3D3049BFDB31@gmail.com>
References: <B4A787FE-5C67-49CF-9866-3D3049BFDB31@gmail.com>
Message-ID: <d4911cc6-f67d-e013-3b84-233fc485e1fe@oracle.com>

Congrats Attila!

-Sundar

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