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 > > >> > > > > > >
