----- Mail original -----
De: "Attila Szegedi" <szege...@gmail.com>
À: "nashorn-dev" <nashorn-dev@openjdk.java.net>
Envoyé: Lundi 19 Octobre 2020 17:16:55
Objet: Re: Standalone Nashorn is coming for Java 15+
Hi y’all,
Hi Attila,
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 <szege...@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@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
