Thanks Isaiah - I totally missed that point in the thread. I'll hit up some Ivy folks I know and see if they're interested in helping with this.
Ben On Tue, 17 Nov 2020 at 12:50, Isaiah Peng <issa...@gmail.com> wrote: > > FYI, the reason for using Any is specified in the thread: > > > 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. > > Ben Evans <benjamin.john.ev...@gmail.com> 于 2020年11月17日周二 上午10:37写道： >> >> 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 >> > >> >> > > >> >
