Standalone Nashorn is coming for Java 15+

Wed Oct 28 10:46:07 UTC 2020

+1

On Sun, Oct 25, 2020 at 5:18 PM Peter Ansell <ansell.peter at gmail.com> wrote:

> Hi Atilla,
>
> Nashorn-15 seems intuitive to me.
>
> Thanks for the regular updates!
>
> Peter
>
> On Mon, 26 Oct 2020 at 04:08, 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
> > >
> >
>