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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
>>>> (<[email protected]>).
>>>>
>>>> * 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
