Re: Standalone Nashorn is coming for Java 15+
Hi Atilla, Nashorn-15 seems intuitive to me. Thanks for the regular updates! Peter On Mon, 26 Oct 2020 at 04:08, Attila Szegedi 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 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 “” as their > > script name and anonymous functions no longer report “” 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 wrote: >
Re: Standalone Nashorn is coming for Java 15+
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 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 “” as their script name and anonymous functions no longer report > “” 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 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
