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