Hi, thanks for reporting this. I filed a JBS issue[0] and I have a PR[0] to fix it put up. It’ll go into the next Nashorn release.
Thanks, Attila. [0] https://bugs.openjdk.java.net/browse/JDK-8258787 [1] https://github.com/openjdk/nashorn/pull/11 > On 2020. Nov 23., at 17:20, Rony G. Flatscher <rony.flatsc...@wu.ac.at> wrote: > > Hi there, > > the NashornScriptEngineFactory.getOutputStatement() does not create a valid > String from the > toDisplay argument. As a result it is not possible to create correct > Javascript statements that > output strings created with that method (Nashorn creates an exception when > running a statement it > created itself). > > The input string toDisplay: > > ~~~ > 'hello world', this is "ECMAScript" speaking! > ~~~ > > The current getOutputStatement(toDisplay) returns the syntaxtically wrong > output statement (will > cause an exception): > > ~~~ > print('hello world', this is "ECMAScript" speaking!) > ~~~ > > The following git diff would apply double-quotes and escape double-quotes, if > they are part of the > supplied toDisplay argument: > > ~~~ > > G:\dev\openjfx\nashorn\src\org.openjdk.nashorn\share\classes\org\openjdk\nashorn\api\scripting>git > diff > diff --git > a/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/api/scripting/NashornScriptEngineFactory.java > > b/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/api/scripting/NashornScriptEngineFactory.java > index 8dc8895a..59d5d60b 100644 > --- > a/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/api/scripting/NashornScriptEngineFactory.java > +++ > b/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/api/scripting/NashornScriptEngineFactory.java > @@ -104,7 +104,7 @@ public final class NashornScriptEngineFactory > implements ScriptEngineFactory { > > @Override > public String getOutputStatement(final String toDisplay) { > - return "print(" + toDisplay + ")"; > + return "print(\"" + toDisplay.replace("\"","\\\"") + "\")"; > } > > @Override > ~~~ > > The corrected getOutputStatement(toDisplay) with the change returns: > > ~~~ > print("'hello world', this is \"ECMAScript\" speaking!") > ~~~ > > Please advise how to best proceed in order to fix this long standing bug. > > ---rony > > P.S.: If you want you can take that code directly as I signed the Oracle > Contributor Agreement and > submitted changes in the OpenJFX project in the past. > > > On 15.11.2020 18:25, Attila Szegedi 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 >
