+1 On Sun, Oct 25, 2020 at 5:18 PM Peter Ansell <ansell.pe...@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 <szege...@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 <szege...@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 <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 > > > > > >
