subject:"RE\: Standalone Nashorn bound to specific JVM flavors\?"

Re: Standalone Nashorn bound to specific JVM flavors?

2020-11-23 Thread 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<mailto:thomas.bur...@3ds.com>
>> 
>> [3DS Logo]
>> 
>> 3DS.COM/ENOVIA<http://www.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<mailto: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 o

Re: Standalone Nashorn bound to specific JVM flavors?

2020-11-23 Thread 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<mailto:thomas.bur...@3ds.com>
>>
>> [3DS Logo]
>>
>> 3DS.COM/ENOVIA<http://www.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<mailto: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 n

RE: Standalone Nashorn bound to specific JVM flavors?

2020-11-23 Thread 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<mailto:thomas.bur...@3ds.com>
>
> [3DS Logo]
>
> 3DS.COM/ENOVIA<http://www.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<mailto: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<mailto: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?

2020-11-23 Thread 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

Re: Standalone Nashorn bound to specific JVM flavors?

Re: Standalone Nashorn bound to specific JVM flavors?

RE: Standalone Nashorn bound to specific JVM flavors?

Re: Standalone Nashorn bound to specific JVM flavors?

4 matches

Site Navigation

Mail list logo

Footer information