Standalone Nashorn is coming for Java 15+

Tue Oct 20 04:04:42 UTC 2020

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

-Sundar

On 19/10/20 9:41 pm, forax at univ-mlv.fr wrote:
> ----- 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