From szegedia at gmail.com  Wed Apr  4 17:20:50 2018
From: szegedia at gmail.com (Attila Szegedi)
Date: Wed, 4 Apr 2018 19:20:50 +0200
Subject: Is there a way to reference the engine from a linker?
In-Reply-To: <CAJuEN80fLmDbrKQxMp_Cn+u6xs3t-m_arnkF_KPTQHozWep0Nw@mail.gmail.com>
References: <CAJuEN80531px1Om1SmrHGc5xmP7zTvFuu4bSN_RXJbraKKPnQw@mail.gmail.com>
 <CAJuEN82bY8G0SK==u6=sJ-thCZeL7CvQFBHN9y30Jygpob=NHA@mail.gmail.com>
 <CAJuEN8221aNYA0GZnzvwH530jjShTUY4FPNoRuHKfj6JkmfymA@mail.gmail.com>
 <CAJuEN83uQneFSTnJWXiA-r1UaLd3DfUw1a+G-dsa-8WWSF2ZRQ@mail.gmail.com>
 <CAJuEN80NsY+Kg0ni7J0MCYiYGe5r3Kig=anGvT2qZN7R7kPeaA@mail.gmail.com>
 <CAJuEN82dEt3ogTFb852=xMQtQ-P_K0wU3XGDZWc=ZL9xvs5pzQ@mail.gmail.com>
 <CAJuEN83J+qQ-pP_y9aR02EHF5r07gEOWW5r=gDjYJjAth6eg9g@mail.gmail.com>
 <CAJuEN81_98nF23=-ZEZZPvChjVXdsXpSVKCvxZQkgC7k+c76DQ@mail.gmail.com>
 <CAJuEN81NyAZKpw_KqXycXx5SiRO7VMx6d+oiwX2aoeJmhD7WOw@mail.gmail.com>
 <CAJuEN81OGbW7eoxCsPGKo5FD4jHnC99NkqNTX0K5URx9mxmnpg@mail.gmail.com>
 <CAJuEN82=oM9fhU0ivkTMeiVhPnVR8SF1rff0MO3xoCua8qjLmQ@mail.gmail.com>
 <CAJuEN80fLmDbrKQxMp_Cn+u6xs3t-m_arnkF_KPTQHozWep0Nw@mail.gmail.com>
Message-ID: <9517986F-C07F-4F4D-A352-07C42E25F9B8@gmail.com>

Sorry for an awfully late response, but hope it might still help: Java.asJSONCompatible delegates on the Java side to jdk.nashorn.api.scripting.wrapAsJSONCompatible. It?s part of Nashorn?s supported public API, so it should be fine for you to call it.

I?m actually wondering how useful is that API method - you need to pass a ?homeGlobal? parameter, and honestly I?m not really sure how you?d obtain that. Maybe Sundar has an idea.

Attila.

> On 2018. Mar 15., at 20:02, Paulo Lopes <plopes at redhat.com> wrote:
> 
> Hi,
> 
> I'm writing a guarded linker to allow custom casting from JSObject to Vertx
> custom types. So far so good, the basic tests seem to work but I think I'm
> writing too much boiler plate code as I need in many times to have an
> intermediate conversion from JSObject to Map or List.
> 
> So I know that in the engine I could call Java.asJSONCompatible() but I
> don't see how I could get a reference to the engine in the linker.
> 
> Could anyone see a way or let me know if there is a open API to do this?
> 
> Thanks!
> Paulo


From pmartins at redhat.com  Wed Apr  4 17:28:35 2018
From: pmartins at redhat.com (Paulo Lopes)
Date: Wed, 04 Apr 2018 19:28:35 +0200
Subject: Is there a way to reference the engine from a linker?
In-Reply-To: <9517986F-C07F-4F4D-A352-07C42E25F9B8@gmail.com>
Message-ID: <udqno5iapvhlttnslhtaso4k.1522862915569@redhat.com>

Hi,

I've worked around it by using:


ScriptUtils.convert(obj, Map.class)


When ever I needed to get a script object as a map or replacing the class with List.class when I need a list...

Is that a safe way to do it?


? Original Message ?
From: szegedia at gmail.com
Sent: April 4, 2018 7:21 PM
To: plopes at redhat.com
Cc: nashorn-dev at openjdk.java.net
Subject: Re: Is there a way to reference the engine from a linker?

Sorry for an awfully late response, but hope it might still help: Java.asJSONCompatible delegates on the Java side to jdk.nashorn.api.scripting.wrapAsJSONCompatible. It?s part of Nashorn?s supported public API, so it should be fine for you to call it.

I?m actually wondering how useful is that API method - you need to pass a ?homeGlobal? parameter, and honestly I?m not really sure how you?d obtain that. Maybe Sundar has an idea.

Attila.

> On 2018. Mar 15., at 20:02, Paulo Lopes <plopes at redhat.com> wrote:
> 
> Hi,
> 
> I'm writing a guarded linker to allow custom casting from JSObject to Vertx
> custom types. So far so good, the basic tests seem to work but I think I'm
> writing too much boiler plate code as I need in many times to have an
> intermediate conversion from JSObject to Map or List.
> 
> So I know that in the engine I could call Java.asJSONCompatible() but I
> don't see how I could get a reference to the engine in the linker.
> 
> Could anyone see a way or let me know if there is a open API to do this?
> 
> Thanks!
> Paulo


From szegedia at gmail.com  Wed Apr  4 17:50:21 2018
From: szegedia at gmail.com (Attila Szegedi)
Date: Wed, 4 Apr 2018 19:50:21 +0200
Subject: Is there a way to reference the engine from a linker?
In-Reply-To: <udqno5iapvhlttnslhtaso4k.1522862915569@redhat.com>
References: <udqno5iapvhlttnslhtaso4k.1522862915569@redhat.com>
Message-ID: <C4F06FDA-6D8D-4496-A0C0-C172081E0127@gmail.com>

Oh, good one. Yes, I think that?ll do. It engages Nashorn?s built-in linker chain to find an appropriate conversion.

Attila.

> On 2018. Apr 4., at 19:28, Paulo Lopes <pmartins at redhat.com> wrote:
> 
> Hi,
> 
> I've worked around it by using:
> 
> 
> ScriptUtils.convert(obj, Map.class)
> 
> 
> When ever I needed to get a script object as a map or replacing the class with List.class when I need a list...
> 
> Is that a safe way to do it?
> 
> 
>   Original Message  
> From: szegedia at gmail.com
> Sent: April 4, 2018 7:21 PM
> To: plopes at redhat.com
> Cc: nashorn-dev at openjdk.java.net
> Subject: Re: Is there a way to reference the engine from a linker?
> 
> Sorry for an awfully late response, but hope it might still help: Java.asJSONCompatible delegates on the Java side to jdk.nashorn.api.scripting.wrapAsJSONCompatible. It?s part of Nashorn?s supported public API, so it should be fine for you to call it.
> 
> I?m actually wondering how useful is that API method - you need to pass a ?homeGlobal? parameter, and honestly I?m not really sure how you?d obtain that. Maybe Sundar has an idea.
> 
> Attila.
> 
>> On 2018. Mar 15., at 20:02, Paulo Lopes <plopes at redhat.com> wrote:
>> 
>> Hi,
>> 
>> I'm writing a guarded linker to allow custom casting from JSObject to Vertx
>> custom types. So far so good, the basic tests seem to work but I think I'm
>> writing too much boiler plate code as I need in many times to have an
>> intermediate conversion from JSObject to Map or List.
>> 
>> So I know that in the engine I could call Java.asJSONCompatible() but I
>> don't see how I could get a reference to the engine in the linker.
>> 
>> Could anyone see a way or let me know if there is a open API to do this?
>> 
>> Thanks!
>> Paulo
> 


From victor2 at ukr.net  Wed Apr 11 04:48:02 2018
From: victor2 at ukr.net (Victor Polischuk)
Date: Wed, 11 Apr 2018 07:48:02 +0300
Subject: JSObject without Java-based conversion to JSON
Message-ID: <1523420499.910049156.g94dciyq@frv45.fwdcdn.com>

Dear all,

I apologize if the question was already raised in the mail list, however, I find it quite strange that JSObject lacks convenient methods to convert it at least to JSON-string, if not directly to Java-POJOs?

The Internet is full of suggestions which involve JavaScript JSON.stringify(..) as a utility. While it might work too, but I guess a lot of others are just traversing the JSObject by their own "converters".

Therefore, if there is no design limitations/reasons why the conversion should/could not be applied within the Java representation, I am ready to volunteer on the patch.

My reason for it are:
 * It looks quite ugly to execute JavaScript to make something with "almost" Java object.
 * Java has enormous number of JSON libraries already. I guess it is nice to allow people connect their favorite with minimal efforts. Potentially, if it will be required "string" phase might be excluded (not JSObject->String->POJO, but JSObject->POJO). 
 * It may simplify logging/debugging of interaction between Java and JS.

/
Best Regards,
Victor

From sundararajan.athijegannathan at oracle.com  Fri Apr 13 02:50:38 2018
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 13 Apr 2018 08:20:38 +0530
Subject: JSObject without Java-based conversion to JSON
In-Reply-To: <1523420499.910049156.g94dciyq@frv45.fwdcdn.com>
References: <1523420499.910049156.g94dciyq@frv45.fwdcdn.com>
Message-ID: <5AD01AFE.7090107@oracle.com>

Please note that a general Java object graph may involve circular 
references. Without modifying JSON somehow, it is not possible to handle 
such cases.  That said, please do file a rfe with your ideas and we can 
discuss.

-Sundar

On 11/04/18, 10:18 AM, Victor Polischuk wrote:
> Dear all,
>
> I apologize if the question was already raised in the mail list, however, I find it quite strange that JSObject lacks convenient methods to convert it at least to JSON-string, if not directly to Java-POJOs?
>
> The Internet is full of suggestions which involve JavaScript JSON.stringify(..) as a utility. While it might work too, but I guess a lot of others are just traversing the JSObject by their own "converters".
>
> Therefore, if there is no design limitations/reasons why the conversion should/could not be applied within the Java representation, I am ready to volunteer on the patch.
>
> My reason for it are:
>   * It looks quite ugly to execute JavaScript to make something with "almost" Java object.
>   * Java has enormous number of JSON libraries already. I guess it is nice to allow people connect their favorite with minimal efforts. Potentially, if it will be required "string" phase might be excluded (not JSObject->String->POJO, but JSObject->POJO).
>   * It may simplify logging/debugging of interaction between Java and JS.
>
> /
> Best Regards,
> Victor

From victor2 at ukr.net  Sat Apr 14 09:52:36 2018
From: victor2 at ukr.net (Victor Polischuk)
Date: Sat, 14 Apr 2018 12:52:36 +0300
Subject: JSObject without Java-based conversion to JSON
In-Reply-To: <5AD01AFE.7090107@oracle.com>
References: <1523420499.910049156.g94dciyq@frv45.fwdcdn.com>
 <5AD01AFE.7090107@oracle.com>
Message-ID: <1523699230.250083672.m6w48tps@frv45.fwdcdn.com>

Hi Sundar,

Thank you for the answer. I have filed a RFE #9053373, with the minimal intrusion in the API which already should allow people to work with Nashorn more comfortably. 

/Victor
 
 --- Original message ---
 From: "Sundararajan Athijegannathan" <sundararajan.athijegannathan at oracle.com>
 Date: 13 April 2018, 05:47:38
  


> Please note that a general Java object graph may involve circular 
> references. Without modifying JSON somehow, it is not possible to handle 
> such cases. That said, please do file a rfe with your ideas and we can 
> discuss.
> 
> -Sundar
> 
> On 11/04/18, 10:18 AM, Victor Polischuk wrote:
> > Dear all,
> >
> > I apologize if the question was already raised in the mail list, however, I find it quite strange that JSObject lacks convenient methods to convert it at least to JSON-string, if not directly to Java-POJOs?
> >
> > The Internet is full of suggestions which involve JavaScript JSON.stringify(..) as a utility. While it might work too, but I guess a lot of others are just traversing the JSObject by their own "converters".
> >
> > Therefore, if there is no design limitations/reasons why the conversion should/could not be applied within the Java representation, I am ready to volunteer on the patch.
> >
> > My reason for it are:
> > * It looks quite ugly to execute JavaScript to make something with "almost" Java object.
> > * Java has enormous number of JSON libraries already. I guess it is nice to allow people connect their favorite with minimal efforts. Potentially, if it will be required "string" phase might be excluded (not JSObject->String->POJO, but JSObject->POJO).
> > * It may simplify logging/debugging of interaction between Java and JS.
> >
> > /
> > Best Regards,
> > Victor
> 

From tonyzakula at gmail.com  Sat Apr 14 12:43:25 2018
From: tonyzakula at gmail.com (Tony Zakula)
Date: Sat, 14 Apr 2018 08:43:25 -0400
Subject: JSObject without Java-based conversion to JSON
In-Reply-To: <1523699230.250083672.m6w48tps@frv45.fwdcdn.com>
References: <1523420499.910049156.g94dciyq@frv45.fwdcdn.com>
 <5AD01AFE.7090107@oracle.com> <1523699230.250083672.m6w48tps@frv45.fwdcdn.com>
Message-ID: <CAC_sW-cuD1K54bZ93oAqwZE1mOSh3Mw+bgFpJZWk4S6LV_FxwQ@mail.gmail.com>

Where is it filed?  Curious.  We use Jackson and annotations to avoid
circular references.

On Sat, Apr 14, 2018 at 5:52 AM, Victor Polischuk <victor2 at ukr.net> wrote:

> Hi Sundar,
>
> Thank you for the answer. I have filed a RFE #9053373, with the minimal
> intrusion in the API which already should allow people to work with Nashorn
> more comfortably.
>
> /Victor
>
>  --- Original message ---
>  From: "Sundararajan Athijegannathan" <sundararajan.athijegannathan@
> oracle.com>
>  Date: 13 April 2018, 05:47:38
>
>
>
> > Please note that a general Java object graph may involve circular
> > references. Without modifying JSON somehow, it is not possible to handle
> > such cases. That said, please do file a rfe with your ideas and we can
> > discuss.
> >
> > -Sundar
> >
> > On 11/04/18, 10:18 AM, Victor Polischuk wrote:
> > > Dear all,
> > >
> > > I apologize if the question was already raised in the mail list,
> however, I find it quite strange that JSObject lacks convenient methods to
> convert it at least to JSON-string, if not directly to Java-POJOs?
> > >
> > > The Internet is full of suggestions which involve JavaScript
> JSON.stringify(..) as a utility. While it might work too, but I guess a lot
> of others are just traversing the JSObject by their own "converters".
> > >
> > > Therefore, if there is no design limitations/reasons why the
> conversion should/could not be applied within the Java representation, I am
> ready to volunteer on the patch.
> > >
> > > My reason for it are:
> > > * It looks quite ugly to execute JavaScript to make something with
> "almost" Java object.
> > > * Java has enormous number of JSON libraries already. I guess it is
> nice to allow people connect their favorite with minimal efforts.
> Potentially, if it will be required "string" phase might be excluded (not
> JSObject->String->POJO, but JSObject->POJO).
> > > * It may simplify logging/debugging of interaction between Java and JS.
> > >
> > > /
> > > Best Regards,
> > > Victor
> >
>

From hannes.wallnoefer at oracle.com  Mon Apr 23 13:49:50 2018
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Mon, 23 Apr 2018 15:49:50 +0200
Subject: RFR: 8201466: Nashorn: defineProperty setters/getters on prototype
 object ignored with numeric property names
Message-ID: <E4855A23-C7E7-4C1C-B7A3-52D53730AEDC@oracle.com>

Please review: 

Bug: https://bugs.openjdk.java.net/browse/JDK-8201466
Webrev: http://cr.openjdk.java.net/~hannesw/8201466/webrev/

Thanks,
Hannes

From sundararajan.athijegannathan at oracle.com  Mon Apr 23 14:19:37 2018
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 23 Apr 2018 07:19:37 -0700
Subject: RFR: 8201466: Nashorn: defineProperty setters/getters on prototype
 object ignored with numeric property names
In-Reply-To: <E4855A23-C7E7-4C1C-B7A3-52D53730AEDC@oracle.com>
References: <E4855A23-C7E7-4C1C-B7A3-52D53730AEDC@oracle.com>
Message-ID: <5ADDEB79.8070806@oracle.com>

Looks good.

-Sundar

On 23/04/18, 6:49 AM, Hannes Walln?fer wrote:
> Please review:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201466
> Webrev: http://cr.openjdk.java.net/~hannesw/8201466/webrev/
>
> Thanks,
> Hannes

From james.laskey at oracle.com  Mon Apr 23 15:16:01 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Mon, 23 Apr 2018 12:16:01 -0300
Subject: RFR: 8201466: Nashorn: defineProperty setters/getters on
 prototype object ignored with numeric property names
In-Reply-To: <E4855A23-C7E7-4C1C-B7A3-52D53730AEDC@oracle.com>
References: <E4855A23-C7E7-4C1C-B7A3-52D53730AEDC@oracle.com>
Message-ID: <E93D0734-637A-44F1-8F01-D9C57AF4B538@oracle.com>

+1


> On Apr 23, 2018, at 10:49 AM, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
> 
> Please review: 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201466
> Webrev: http://cr.openjdk.java.net/~hannesw/8201466/webrev/
> 
> Thanks,
> Hannes


From hannes.wallnoefer at oracle.com  Mon Apr 23 15:34:18 2018
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Mon, 23 Apr 2018 17:34:18 +0200
Subject: RFR: 8198816: AbstractScriptEngine.getScriptContext creation of
 SimpleScriptContext is inefficient
Message-ID: <B61CE52E-2F44-492A-A6E8-223C4FF4B4B6@oracle.com>

Please review:

Bug: https://bugs.openjdk.java.net/browse/JDK-8198816
Webrev: http://cr.openjdk.java.net/~hannesw/8198816/webrev/

Thanks,
Hannes

From james.laskey at oracle.com  Mon Apr 23 15:59:23 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Mon, 23 Apr 2018 12:59:23 -0300
Subject: RFR: 8198816: AbstractScriptEngine.getScriptContext creation of
 SimpleScriptContext is inefficient
In-Reply-To: <B61CE52E-2F44-492A-A6E8-223C4FF4B4B6@oracle.com>
References: <B61CE52E-2F44-492A-A6E8-223C4FF4B4B6@oracle.com>
Message-ID: <3373BE70-C2A0-44EE-AC8D-910F121B123F@oracle.com>

+1


> On Apr 23, 2018, at 12:34 PM, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198816
> Webrev: http://cr.openjdk.java.net/~hannesw/8198816/webrev/
> 
> Thanks,
> Hannes


From sundararajan.athijegannathan at oracle.com  Mon Apr 23 16:13:53 2018
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 23 Apr 2018 09:13:53 -0700
Subject: RFR: 8198816: AbstractScriptEngine.getScriptContext creation
 of SimpleScriptContext is inefficient
In-Reply-To: <B61CE52E-2F44-492A-A6E8-223C4FF4B4B6@oracle.com>
References: <B61CE52E-2F44-492A-A6E8-223C4FF4B4B6@oracle.com>
Message-ID: <5ADE0641.2010104@oracle.com>

+1

-Sundar

On 23/04/18, 8:34 AM, Hannes Walln?fer wrote:
> Please review:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198816
> Webrev: http://cr.openjdk.java.net/~hannesw/8198816/webrev/
>
> Thanks,
> Hannes

From rberdeen at hubspot.com  Mon Apr 30 22:38:44 2018
From: rberdeen at hubspot.com (Ryan Berdeen)
Date: Mon, 30 Apr 2018 22:38:44 +0000
Subject: Longs aren't numbers in Java 8u162
Message-ID: <CA+dnjxfUboo_Mi7EGf_+=umGqTyvOgS_wMmOO3mTvRN4gqThkw@mail.gmail.com>

I encountered an issue when upgrading from Java 8u66 to 8u162. In 8u66,
java.lang.Integer and java.lang.Long both behaved as JS numbers. In 8u162
(and 10.0.1), Longs behave differently in a way that is breaking my
application.

    function test(n) {
      print(n);
      print(typeof n);
      print(n.hasOwnProperty('x'));
      print();
    }

    test(new java.lang.Integer(0));
    test(new java.lang.Long(0));

In 8u66, this behaved the same for Integer and Long, but in 8u162, typeof
returns "object", and the object doesn't have the expected properties:

    $ jjs longs.js
    0
    number
    false

    0
    object
    longs.js:4 TypeError: n.hasOwnProperty is not a function

In my application, this came up with values passed through to the engine in
bindings.

Is this change intentional? If so, is there a way to revert to the previous
behavior and if not, is there a way to work around it so that I can update?

From jluzon at riotgames.com  Mon Apr 30 23:10:18 2018
From: jluzon at riotgames.com (Jesus Luzon)
Date: Mon, 30 Apr 2018 16:10:18 -0700
Subject: Longs aren't numbers in Java 8u162
In-Reply-To: <CA+dnjxfUboo_Mi7EGf_+=umGqTyvOgS_wMmOO3mTvRN4gqThkw@mail.gmail.com>
References: <CA+dnjxfUboo_Mi7EGf_+=umGqTyvOgS_wMmOO3mTvRN4gqThkw@mail.gmail.com>
Message-ID: <CAJ_jK4n_ukuJ8pVeqOgLFCCyD73=B29XWk3o8V0vhxoKcX1jcg@mail.gmail.com>

This seems like it could be a side effect of a bug I reported where using a
number as the key in an object in Nashorn made an array of the at least the
size of the number and then inserted in the index of the number specified.
The bug was fixed around that version that you mention.

On Mon, Apr 30, 2018 at 3:38 PM, Ryan Berdeen <rberdeen at hubspot.com> wrote:

> I encountered an issue when upgrading from Java 8u66 to 8u162. In 8u66,
> java.lang.Integer and java.lang.Long both behaved as JS numbers. In 8u162
> (and 10.0.1), Longs behave differently in a way that is breaking my
> application.
>
>     function test(n) {
>       print(n);
>       print(typeof n);
>       print(n.hasOwnProperty('x'));
>       print();
>     }
>
>     test(new java.lang.Integer(0));
>     test(new java.lang.Long(0));
>
> In 8u66, this behaved the same for Integer and Long, but in 8u162, typeof
> returns "object", and the object doesn't have the expected properties:
>
>     $ jjs longs.js
>     0
>     number
>     false
>
>     0
>     object
>     longs.js:4 TypeError: n.hasOwnProperty is not a function
>
> In my application, this came up with values passed through to the engine in
> bindings.
>
> Is this change intentional? If so, is there a way to revert to the previous
> behavior and if not, is there a way to work around it so that I can update?
>