Re: Standalone Nashorn bound to specific JVM flavors?

[Attila Szegedi]

I’m happy to expend some effort to make it compatible with other JVMs that 
people want to use. It’s also entirely possible that there’s nothing specific 
to do! There’s nothing in Nashorn that depends on HotSpot. Nashorn is written 
in Java, it generates bytecode, and uses invokedynamic and method handles, 
which are all part of the standard JVM specification. I’d suggest you try it on 
OpenJ9 and report back with your findings. As I said, I’m happy to address 
small snags, and I wouldn’t expect deeper issues.

Attila.

> On 2020. Nov 23., at 18:32, BURRIS Thomas  wrote:
> 
> Hi Attila -- Just to clarify to make sure I understand... So the target JVM 
> flavor for compatibility with Standalone Nashorn will be HotSpot? And -- at 
> least at the moment -- there are no explicit plans to make compatible with 
> (for example) OpenJ9 (aside from turning off anon-classes)?
> 
> As for your question: for our usage, we would not have a need for a lower 
> class version. Can't speak for others...
> 
> thanks for your time!
> 
> Best Regards,
> Thomas BURRIS
> RDF Modeling R Software Architecture Director
> 
> –––
> Office: +1 78 1810 3718
> Mobile: +1 61 7678 9158
> thomas.bur...@3ds.com
> http://www.3ds.com/enovia
> –––
> DS Americas Corp. | 175 Wyman Street | Waltham, MA 02451 | United States
> 
> 
> 
> -Original Message-
> From: Attila Szegedi 
> Sent: Monday, November 23, 2020 11:59 AM
> To: BURRIS Thomas 
> Cc: nashorn-dev@openjdk.java.net
> Subject: Re: Standalone Nashorn bound to specific JVM flavors?
> 
> EXTERNAL EMAIL : The sender of this email is external to 3DS. Be wary of the 
> content and do not open unexpected attachments or links. If you consider this 
> email as spam, you can click the following link 
> https://spam-report.3ds.com/?linktext=https://www.mailcontrol.com/sr/h1GaZGJOvGTGX2PQPOmvUjDF5G4QKHNhl082kiOTzADNbjc452RwRmfbAtROIo3aofl_zynrChD1JTd_1uc-_w==
>   (no login or additional action will be requested).
> 
> 
> It has exactly one dependency on sun.misc.Unsafe - a call to 
> defineAnonymousClass. I’m not aware if that’s available on other JVMs or not, 
> but that might be the only issue I’m aware of. FWIW, Nashorn can be used with 
> --anonymous-classes=false to turn this feature off (it’s a bit of an 
> optimization.)
> 
> As it is, I meant to publish the initial version with javac compiling for 
> Java 15, as I presumed nobody would be interested in using it on earlier Java 
> versions as 14 comes with Nashorn included. I have not released it _just yet_ 
> to Maven central (there’s some permission snags on Sonatype OSS). I’m 
> wondering if there’d be value in compiling with a lower target class version?
> 
> Attila.
> 
>> On 2020. Nov 23., at 17:32, BURRIS Thomas  wrote:
>> 
>> Hi Attila (et. al.) - is there a pre-requisite between the "standalone" 
>> Nashorn and the origin of the JVM ? For example, would it possible to run 
>> the future stand-alone Nashorn and AdoptOpenJDK with OpenJ9 (rather than 
>> HotSpot) ?
>> 
>> 
>> Best Regards,
>> 
>> Thomas BURRIS
>> 
>> RDF Modeling R Software Architecture Director
>> 
>> 
>> 
>> 
>> 
>> Office: +1 78 1810 3718
>> Mobile: +1 61 7678 9158
>> thomas.bur...@3ds.com
>> 
>> [3DS Logo]
>> 
>> 3DS.COM/ENOVIA
>> 
>> 
>> DS Americas Corp. | 175 Wyman Street | Waltham, MA 02451 | United States
>> 
>> 
>> 
>> This email and any attachments are intended solely for the use of the 
>> individual or entity to whom it is addressed and may be confidential and/or 
>> privileged.
>> 
>> If you are not one of the named recipients or have received this email in 
>> error,
>> 
>> (i) you should not read, disclose, or copy it,
>> 
>> (ii) please notify sender of your receipt by reply email and delete this 
>> email and all attachments,
>> 
>> (iii) Dassault Syst?mes does not accept or assume any liability or 
>> responsibility for any use of or reliance on this email.
>> 
>> 
>> Please be informed that your personal data are processed according to our 
>> data privacy policy as described on our website. Should you have any 
>> questions related to personal data protection, please contact 3DS Data 
>> Protection Officer at 
>> 3ds.compliance-priv...@3ds.com
>> 
>> 
>> For other languages, go to https://www.3ds.com/terms/email-disclaimer
> 
> This email and any attachments are intended solely for the use of the 
> individual or entity to whom it is addressed and may be confidential and/or 
> privileged.
> 
> If you are not one of the named recipients or have received this email in 
> error,
> 
> (i) you should not read, disclose, or copy it,
> 
> (ii) please notify sender of your receipt by reply email and delete this 
> email and all attachments,
> 
> (iii) Dassault Systèmes does not accept or assume any liability or 
> responsibility for any use of or reliance on this email.
> 
> 
> Please be informed that your personal 

Re: Standalone Nashorn bound to specific JVM flavors?

[Remi Forax]

- Mail original -
> De: "BURRIS Thomas" 
> À: "Attila Szegedi" 
> Cc: "nashorn-dev" 
> Envoyé: Lundi 23 Novembre 2020 18:32:37
> Objet: RE: Standalone Nashorn bound to specific JVM flavors?

> Hi Attila -- Just to clarify to make sure I understand... So the target JVM
> flavor for compatibility with Standalone Nashorn will be HotSpot? And -- at
> least at the moment -- there are no explicit plans to make compatible with 
> (for
> example) OpenJ9 (aside from turning off anon-classes)?

OpenJ9 doesn't support constant pool patching of live objects, the last 
parameter of defineAnonymousClass.
Nashorn uses defineAnonymousClass with null as last argument so it should work 
with OpenJ9.

> 
> As for your question: for our usage, we would not have a need for a lower 
> class
> version. Can't speak for others...
> 
> thanks for your time!
> 
> Best Regards,
> Thomas BURRIS
> RDF Modeling R Software Architecture Director

regards,
Rémi

> 
> –––
> Office: +1 78 1810 3718
> Mobile: +1 61 7678 9158
> thomas.bur...@3ds.com
> http://www.3ds.com/enovia
> –––
> DS Americas Corp. | 175 Wyman Street | Waltham, MA 02451 | United States
> 
> 
> 
> -Original Message-
> From: Attila Szegedi 
> Sent: Monday, November 23, 2020 11:59 AM
> To: BURRIS Thomas 
> Cc: nashorn-dev@openjdk.java.net
> Subject: Re: Standalone Nashorn bound to specific JVM flavors?
> 
> EXTERNAL EMAIL : The sender of this email is external to 3DS. Be wary of the
> content and do not open unexpected attachments or links. If you consider this
> email as spam, you can click the following link
> https://spam-report.3ds.com/?linktext=https://www.mailcontrol.com/sr/h1GaZGJOvGTGX2PQPOmvUjDF5G4QKHNhl082kiOTzADNbjc452RwRmfbAtROIo3aofl_zynrChD1JTd_1uc-_w==
> (no login or additional action will be requested).
> 
> 
> It has exactly one dependency on sun.misc.Unsafe - a call to
> defineAnonymousClass. I’m not aware if that’s available on other JVMs or not,
> but that might be the only issue I’m aware of. FWIW, Nashorn can be used with
> --anonymous-classes=false to turn this feature off (it’s a bit of an
> optimization.)
> 
> As it is, I meant to publish the initial version with javac compiling for Java
> 15, as I presumed nobody would be interested in using it on earlier Java
> versions as 14 comes with Nashorn included. I have not released it _just yet_
> to Maven central (there’s some permission snags on Sonatype OSS). I’m 
> wondering
> if there’d be value in compiling with a lower target class version?
> 
> Attila.
> 
>> On 2020. Nov 23., at 17:32, BURRIS Thomas  wrote:
>>
>> Hi Attila (et. al.) - is there a pre-requisite between the "standalone" 
>> Nashorn
>> and the origin of the JVM ? For example, would it possible to run the future
>> stand-alone Nashorn and AdoptOpenJDK with OpenJ9 (rather than HotSpot) ?
>>
>>
>> Best Regards,
>>
>> Thomas BURRIS
>>
>> RDF Modeling R Software Architecture Director
>>
>>
>>
>>
>>
>> Office: +1 78 1810 3718
>> Mobile: +1 61 7678 9158
>> thomas.bur...@3ds.com
>>
>> [3DS Logo]
>>
>> 3DS.COM/ENOVIA
>>
>>
>> DS Americas Corp. | 175 Wyman Street | Waltham, MA 02451 | United States
>>
>>
>>
>> This email and any attachments are intended solely for the use of the 
>> individual
>> or entity to whom it is addressed and may be confidential and/or privileged.
>>
>> If you are not one of the named recipients or have received this email in 
>> error,
>>
>> (i) you should not read, disclose, or copy it,
>>
>> (ii) please notify sender of your receipt by reply email and delete this 
>> email
>> and all attachments,
>>
>> (iii) Dassault Syst?mes does not accept or assume any liability or
>> responsibility for any use of or reliance on this email.
>>
>>
>> Please be informed that your personal data are processed according to our 
>> data
>> privacy policy as described on our website. Should you have any questions
>> related to personal data protection, please contact 3DS Data Protection 
>> Officer
>> at 3ds.compliance-priv...@3ds.com
>>
>>
>> For other languages, go to https://www.3ds.com/terms/email-disclaimer
> 
> This email and any attachments are intended solely for the use of the 
> individual
> or entity to whom it is addressed and may be confidential and/or privileged.
> 
> If you are not one of the named recipients or have received this email in 
> error,
> 
> (i) you should not read, disclose, or copy it,
> 
> (ii) please notify sender of your receipt by reply email and delete this email
> and all attachments,
> 
> (iii) Dassault Systèmes does not accept or assume any liability or
> responsibility for any use of or reliance on this email.
> 
> 
> Please be informed that your personal data are processed according to our data
> privacy policy as described on our website. Should you have any questions
> related to personal data protection, please contact 3DS Data Protection 
> 

RE: Standalone Nashorn bound to specific JVM flavors?

[BURRIS Thomas]

Hi Attila -- Just to clarify to make sure I understand... So the target JVM 
flavor for compatibility with Standalone Nashorn will be HotSpot? And -- at 
least at the moment -- there are no explicit plans to make compatible with (for 
example) OpenJ9 (aside from turning off anon-classes)?

As for your question: for our usage, we would not have a need for a lower class 
version. Can't speak for others...

thanks for your time!

Best Regards,
Thomas BURRIS
RDF Modeling R Software Architecture Director

–––
Office: +1 78 1810 3718
Mobile: +1 61 7678 9158
thomas.bur...@3ds.com
http://www.3ds.com/enovia
–––
DS Americas Corp. | 175 Wyman Street | Waltham, MA 02451 | United States



-Original Message-
From: Attila Szegedi 
Sent: Monday, November 23, 2020 11:59 AM
To: BURRIS Thomas 
Cc: nashorn-dev@openjdk.java.net
Subject: Re: Standalone Nashorn bound to specific JVM flavors?

EXTERNAL EMAIL : The sender of this email is external to 3DS. Be wary of the 
content and do not open unexpected attachments or links. If you consider this 
email as spam, you can click the following link 
https://spam-report.3ds.com/?linktext=https://www.mailcontrol.com/sr/h1GaZGJOvGTGX2PQPOmvUjDF5G4QKHNhl082kiOTzADNbjc452RwRmfbAtROIo3aofl_zynrChD1JTd_1uc-_w==
  (no login or additional action will be requested).


It has exactly one dependency on sun.misc.Unsafe - a call to 
defineAnonymousClass. I’m not aware if that’s available on other JVMs or not, 
but that might be the only issue I’m aware of. FWIW, Nashorn can be used with 
--anonymous-classes=false to turn this feature off (it’s a bit of an 
optimization.)

As it is, I meant to publish the initial version with javac compiling for Java 
15, as I presumed nobody would be interested in using it on earlier Java 
versions as 14 comes with Nashorn included. I have not released it _just yet_ 
to Maven central (there’s some permission snags on Sonatype OSS). I’m wondering 
if there’d be value in compiling with a lower target class version?

Attila.

> On 2020. Nov 23., at 17:32, BURRIS Thomas  wrote:
>
> Hi Attila (et. al.) - is there a pre-requisite between the "standalone" 
> Nashorn and the origin of the JVM ? For example, would it possible to run the 
> future stand-alone Nashorn and AdoptOpenJDK with OpenJ9 (rather than HotSpot) 
> ?
>
>
> Best Regards,
>
> Thomas BURRIS
>
> RDF Modeling R Software Architecture Director
>
>
>
>
>
> Office: +1 78 1810 3718
> Mobile: +1 61 7678 9158
> thomas.bur...@3ds.com
>
> [3DS Logo]
>
> 3DS.COM/ENOVIA
>
>
> DS Americas Corp. | 175 Wyman Street | Waltham, MA 02451 | United States
>
>
>
> This email and any attachments are intended solely for the use of the 
> individual or entity to whom it is addressed and may be confidential and/or 
> privileged.
>
> If you are not one of the named recipients or have received this email in 
> error,
>
> (i) you should not read, disclose, or copy it,
>
> (ii) please notify sender of your receipt by reply email and delete this 
> email and all attachments,
>
> (iii) Dassault Syst?mes does not accept or assume any liability or 
> responsibility for any use of or reliance on this email.
>
>
> Please be informed that your personal data are processed according to our 
> data privacy policy as described on our website. Should you have any 
> questions related to personal data protection, please contact 3DS Data 
> Protection Officer at 
> 3ds.compliance-priv...@3ds.com
>
>
> For other languages, go to https://www.3ds.com/terms/email-disclaimer

This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
at 3ds.compliance-priv...@3ds.com


For other languages, go to https://www.3ds.com/terms/email-disclaimer

Re: Standalone Nashorn bound to specific JVM flavors?

[Attila Szegedi]

It has exactly one dependency on sun.misc.Unsafe - a call to 
defineAnonymousClass. I’m not aware if that’s available on other JVMs or not, 
but that might be the only issue I’m aware of. FWIW, Nashorn can be used with 
--anonymous-classes=false to turn this feature off (it’s a bit of an 
optimization.) 

As it is, I meant to publish the initial version with javac compiling for Java 
15, as I presumed nobody would be interested in using it on earlier Java 
versions as 14 comes with Nashorn included. I have not released it _just yet_ 
to Maven central (there’s some permission snags on Sonatype OSS). I’m wondering 
if there’d be value in compiling with a lower target class version?

Attila.

> On 2020. Nov 23., at 17:32, BURRIS Thomas  wrote:
> 
> Hi Attila (et. al.) - is there a pre-requisite between the "standalone" 
> Nashorn and the origin of the JVM ? For example, would it possible to run the 
> future stand-alone Nashorn and AdoptOpenJDK with OpenJ9 (rather than HotSpot) 
> ?
> 
> 
> Best Regards,
> 
> Thomas BURRIS
> 
> RDF Modeling R Software Architecture Director
> 
> 
> 
> 
> 
> Office: +1 78 1810 3718
> Mobile: +1 61 7678 9158
> thomas.bur...@3ds.com
> 
> [3DS Logo]
> 
> 3DS.COM/ENOVIA
> 
> 
> DS Americas Corp. | 175 Wyman Street | Waltham, MA 02451 | United States
> 
> 
> 
> This email and any attachments are intended solely for the use of the 
> individual or entity to whom it is addressed and may be confidential and/or 
> privileged.
> 
> If you are not one of the named recipients or have received this email in 
> error,
> 
> (i) you should not read, disclose, or copy it,
> 
> (ii) please notify sender of your receipt by reply email and delete this 
> email and all attachments,
> 
> (iii) Dassault Syst?mes does not accept or assume any liability or 
> responsibility for any use of or reliance on this email.
> 
> 
> Please be informed that your personal data are processed according to our 
> data privacy policy as described on our website. Should you have any 
> questions related to personal data protection, please contact 3DS Data 
> Protection Officer at 
> 3ds.compliance-priv...@3ds.com
> 
> 
> For other languages, go to https://www.3ds.com/terms/email-disclaimer

Standalone Nashorn bound to specific JVM flavors?

[BURRIS Thomas]

Hi Attila (et. al.) - is there a pre-requisite between the "standalone" Nashorn 
and the origin of the JVM ? For example, would it possible to run the future 
stand-alone Nashorn and AdoptOpenJDK with OpenJ9 (rather than HotSpot) ?


Best Regards,

Thomas BURRIS

RDF Modeling R Software Architecture Director





Office: +1 78 1810 3718
Mobile: +1 61 7678 9158
thomas.bur...@3ds.com

[3DS Logo]

3DS.COM/ENOVIA


DS Americas Corp. | 175 Wyman Street | Waltham, MA 02451 | United States



This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Syst?mes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
at 3ds.compliance-priv...@3ds.com


For other languages, go to https://www.3ds.com/terms/email-disclaimer

Fix for NashornScriptEngineFactory.getOutputStatement(toDisplay) (Re: Standalone Nashorn is coming for Java 15+

[Rony G. Flatscher]

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