Thanks for all the work you've done on this, Attila. Quick question: The project still seems to be using Ant. Is there a reason for that? Would you merge a PR that ported the build system to Maven or Gradle instead? (and if so, do you have a preference for either one?) IME, Ant is rather inaccessible as a tool these days, and so it might be a good idea to get off it early on.
Thanks, Ben On Sun, 15 Nov 2020 at 18:26, 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 > >> > > >
