Standalone Nashorn is coming for Java 15+

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Attila Szegedi" <szegedia at gmail.com>
> À: "nashorn-dev" <nashorn-dev at openjdk.java.net>
> Envoyé: Lundi 19 Octobre 2020 17:16:55
> Objet: Re: Standalone Nashorn is coming for Java 15+

> Hi y’all,


Hi Attila,

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

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

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

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

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

>
> Attila.

regards,
Rémi

>
> [0] https://github.com/tc39/test262/tree/es5-tests
>
>> On 2020. Oct 11., at 9:28, Attila Szegedi <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