For anyone who doesn’t want to build this from sources themselves, but want to try it, I put a preliminary prebuilt version in my Dropbox at <https://www.dropbox.com/s/pfiq6z8d4g0hrq1/nashorn-core-15.0.jar>
Attila. > On 2020. Nov 15., at 18:25, Attila Szegedi <szege...@gmail.com> wrote: > > Hi y’all, > > openjdk/nashorn repo is up and its main branch is populated with the initial > copy of Nashorn as it existed in JDK 14. I added a fix for wrong/missing > licenses for two files (agreed with Oracle) and an initial project README on > top of it. > > An even better news is that I have the initial standalone Nashorn 15.0.0 PR > up ready for review. It is at: > > <https://github.com/openjdk/nashorn/pull/3> > > > The PR describes the steps to build the artifacts. I’d like to encourage > everyone here to try it out and report back with your experiences, and to > also give an earnest review of the PR. If it works out okay, we could merge > this into main in the next few days and then I can get the artifacts > published into Maven Central! > > Attila. > >> On 2020. Oct 25., at 18:07, 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 >>> >> >
