From vivin.paliath at gmail.com  Sat Oct  1 19:38:40 2016
From: vivin.paliath at gmail.com (Vivin Suresh Paliath)
Date: Sat, 1 Oct 2016 12:38:40 -0700
Subject: RFR: 8166902: Nested object literal property maps not reset in
	optimistic recompilation
In-Reply-To: <679032F0-243F-4426-B5E7-8D372145F9C7@oracle.com>
References: <B6C9EF85-18A1-4D78-8202-B35A46F9623C@oracle.com>
	<2A9C9E9C-2A39-408D-AE8D-789D6FBECAE7@lagergren.net>
	<3DF261BD-5626-4EC1-A7BD-7D75157E8E26@gmail.com>
	<679032F0-243F-4426-B5E7-8D372145F9C7@oracle.com>
Message-ID: <CAF5LYURN9GZZ17eWgye-rUKmQkTiiQAU4-P1t7F5cE+TPsRgKw@mail.gmail.com>

Thanks for resolving this so quickly!

On Fri, Sep 30, 2016 at 10:30 AM, Hannes Walln?fer <
hannes.wallnoefer at oracle.com> wrote:

> Thanks to both of you!
>
> Attila: the TypeEvaluator (which is the only thing that will cause such as
> map change AFAICT) was added after the continuation code in question, so I
> think it was actually correct back then ;-)
>
> Hannes
>
>
> > Am 30.09.2016 um 18:29 schrieb Attila Szegedi <szegedia at gmail.com>:
> >
> > +1; good work. I'm kinda embarrassed I didn?t think of this case?
> >
> > Attila.
> >
> >> On 30 Sep 2016, at 18:18, Marcus Lagergren <marcus at lagergren.net>
> wrote:
> >>
> >> +1. Good catch, Hannes!
> >>
> >> /M
> >>
> >>> On 30 Sep 2016, at 16:46, Hannes Walln?fer <
> hannes.wallnoefer at oracle.com> wrote:
> >>>
> >>> Please review 8166902: Nested object literal property maps not reset
> in optimistic recompilation:
> >>>
> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166902
> >>> Webrev: http://cr.openjdk.java.net/~hannesw/8166902/webrev.00/
> >>>
> >>> The original assumption was that the property map only has to be
> replaced in the top level object literal when optimistic recompilation
> happens within a nested object literal. However, recompilation may also
> create different maps on parent object literals as more information about
> types may be available.
> >>>
> >>> Thanks,
> >>> Hannes
> >>
> >
>
>


-- 
*[vivin.net <http://vivin.net> :: github <http://github.com/vivin> ::
linkedin <https://www.linkedin.com/in/vivin>]*

From szegedia at gmail.com  Mon Oct  3 17:17:21 2016
From: szegedia at gmail.com (Attila Szegedi)
Date: Mon, 3 Oct 2016 19:17:21 +0200
Subject: Review request for JDK-8167037: Remove CALL_METHOD support from
	internal Nashorn linkers
Message-ID: <0F10EA68-06CC-4E46-AA0C-AE5D8D5BE99E@gmail.com>

Please review JDK-8167037 "Remove CALL_METHOD support from internal Nashorn linkers" at <http://cr.openjdk.java.net/~attila/8167037/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8167037>

Nashorn never emits CALL_METHOD Dynalink operation; therefore code for supporting it in internal linkers (those that only service call sites in Nashorn-generated bytecode) is unnecessary. 

I originally stumbled upon this inspecting ScriptObject.findCallMethodMethod() and noticed that the code was even somewhat incorrect by weakening the lookup of the call to public lookup. Thinking of fixing it, I realized it's actually never used.

Thanks,
  Attila.

From sundararajan.athijegannathan at oracle.com  Tue Oct  4 07:51:13 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Tue, 4 Oct 2016 13:21:13 +0530
Subject: Review request for JDK-8167037: Remove CALL_METHOD support from
	internal Nashorn linkers
In-Reply-To: <0F10EA68-06CC-4E46-AA0C-AE5D8D5BE99E@gmail.com>
References: <0F10EA68-06CC-4E46-AA0C-AE5D8D5BE99E@gmail.com>
Message-ID: <40d2d84b-a44d-5358-c21a-1e0254c92ca8@oracle.com>

+1

-Sundar

On 10/3/2016 10:47 PM, Attila Szegedi wrote:
> Please review JDK-8167037 "Remove CALL_METHOD support from internal Nashorn linkers" at <http://cr.openjdk.java.net/~attila/8167037/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8167037>
>
> Nashorn never emits CALL_METHOD Dynalink operation; therefore code for supporting it in internal linkers (those that only service call sites in Nashorn-generated bytecode) is unnecessary. 
>
> I originally stumbled upon this inspecting ScriptObject.findCallMethodMethod() and noticed that the code was even somewhat incorrect by weakening the lookup of the call to public lookup. Thinking of fixing it, I realized it's actually never used.
>
> Thanks,
>   Attila.


From hannes.wallnoefer at oracle.com  Tue Oct  4 07:58:46 2016
From: hannes.wallnoefer at oracle.com (=?windows-1252?Q?Hannes_Walln=F6fer?=)
Date: Tue, 4 Oct 2016 09:58:46 +0200
Subject: Review request for JDK-8167037: Remove CALL_METHOD support from
	internal Nashorn linkers
In-Reply-To: <40d2d84b-a44d-5358-c21a-1e0254c92ca8@oracle.com>
References: <0F10EA68-06CC-4E46-AA0C-AE5D8D5BE99E@gmail.com>
	<40d2d84b-a44d-5358-c21a-1e0254c92ca8@oracle.com>
Message-ID: <369BBB8C-912F-4A55-9624-3C96196DDD23@oracle.com>

+1

Hannes

> Am 04.10.2016 um 09:51 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
> 
> +1
> 
> -Sundar
> 
> On 10/3/2016 10:47 PM, Attila Szegedi wrote:
>> Please review JDK-8167037 "Remove CALL_METHOD support from internal Nashorn linkers" at <http://cr.openjdk.java.net/~attila/8167037/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8167037>
>> 
>> Nashorn never emits CALL_METHOD Dynalink operation; therefore code for supporting it in internal linkers (those that only service call sites in Nashorn-generated bytecode) is unnecessary. 
>> 
>> I originally stumbled upon this inspecting ScriptObject.findCallMethodMethod() and noticed that the code was even somewhat incorrect by weakening the lookup of the call to public lookup. Thinking of fixing it, I realized it's actually never used.
>> 
>> Thanks,
>>  Attila.
> 


From szegedia at gmail.com  Tue Oct  4 18:36:01 2016
From: szegedia at gmail.com (Attila Szegedi)
Date: Tue, 4 Oct 2016 20:36:01 +0200
Subject: Review request for JDK-8167117: insert missing final keywords
Message-ID: <15A2F025-BC7B-4773-8E92-0D0E03FC1922@gmail.com>

Please review JDK-8167117 "insert missing final keywords" at <http://cr.openjdk.java.net/~attila/8167117/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8167117>

Every year or so, this is done once as a kind of anti-entropy task :-)
It?s a big patch, but it?s just mechanical addition of missing ?final? keywords everywhere (and organizing imports in only few files); tests were run afterwards.

I have few other things in the pipeline, but my diffs were getting noisy because of my IDE inserting all the missing ?final? keywords in the files I touched, so wanted to get this out of the way in one swoop.

Thanks,
  Attila.

From sundararajan.athijegannathan at oracle.com  Wed Oct  5 03:41:39 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 5 Oct 2016 09:11:39 +0530
Subject: Review request for JDK-8167117: insert missing final keywords
In-Reply-To: <15A2F025-BC7B-4773-8E92-0D0E03FC1922@gmail.com>
References: <15A2F025-BC7B-4773-8E92-0D0E03FC1922@gmail.com>
Message-ID: <83a80221-55bc-763c-f848-5f00d7ef022c@oracle.com>

+1

PS. One of these days, we should write an ant task using javac API to
automate this check! Painful to manually check & fix using IDEs...

-Sundar

On 10/5/2016 12:06 AM, Attila Szegedi wrote:
> Please review JDK-8167117 "insert missing final keywords" at <http://cr.openjdk.java.net/~attila/8167117/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8167117>
>
> Every year or so, this is done once as a kind of anti-entropy task :-)
> It?s a big patch, but it?s just mechanical addition of missing ?final? keywords everywhere (and organizing imports in only few files); tests were run afterwards.
>
> I have few other things in the pipeline, but my diffs were getting noisy because of my IDE inserting all the missing ?final? keywords in the files I touched, so wanted to get this out of the way in one swoop.
>
> Thanks,
>   Attila.


From sundararajan.athijegannathan at oracle.com  Wed Oct  5 07:59:31 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 5 Oct 2016 13:29:31 +0530
Subject: RFR 8167157: ant build fails with [javadoc] javadoc: error - Illegal
	package name: "implNote:a:Implementation Note:"
Message-ID: <3e6067cb-3960-35df-92fe-dc6f91226378@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8167157/webrev.00/ for
https://bugs.openjdk.java.net/browse/JDK-8167157

PS. Note the whitespace before line continuation char "\". Apparently,
that is needed now with the latest jdk9-dev forest build! Don't know the
reason behind. But, this whitespace does fix the issue!

-Sundar


From hannes.wallnoefer at oracle.com  Wed Oct  5 08:06:12 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Wed, 5 Oct 2016 10:06:12 +0200
Subject: RFR 8167157: ant build fails with [javadoc] javadoc: error -
	Illegal package name: "implNote:a:Implementation Note:"
In-Reply-To: <3e6067cb-3960-35df-92fe-dc6f91226378@oracle.com>
References: <3e6067cb-3960-35df-92fe-dc6f91226378@oracle.com>
Message-ID: <71DECB55-9FD9-4AD3-9C71-110720456AE1@oracle.com>

+1

> Am 05.10.2016 um 09:59 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
> 
> Please review http://cr.openjdk.java.net/~sundar/8167157/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8167157
> 
> PS. Note the whitespace before line continuation char "\". Apparently,
> that is needed now with the latest jdk9-dev forest build! Don't know the
> reason behind. But, this whitespace does fix the issue!
> 
> -Sundar
> 


From james.laskey at oracle.com  Wed Oct  5 11:55:59 2016
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Wed, 5 Oct 2016 08:55:59 -0300
Subject: RFR 8167157: ant build fails with [javadoc] javadoc: error -
	Illegal package name: "implNote:a:Implementation Note:"
In-Reply-To: <3e6067cb-3960-35df-92fe-dc6f91226378@oracle.com>
References: <3e6067cb-3960-35df-92fe-dc6f91226378@oracle.com>
Message-ID: <380AE882-8D07-46C3-B6CB-AB2FC2E911AB@oracle.com>

+1

> On Oct 5, 2016, at 4:59 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8167157/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8167157
> 
> PS. Note the whitespace before line continuation char "\". Apparently,
> that is needed now with the latest jdk9-dev forest build! Don't know the
> reason behind. But, this whitespace does fix the issue!
> 
> -Sundar
> 


From szegedia at gmail.com  Thu Oct  6 12:59:00 2016
From: szegedia at gmail.com (Attila Szegedi)
Date: Thu, 6 Oct 2016 14:59:00 +0200
Subject: Review request for JDK-8167117: insert missing final keywords
In-Reply-To: <83a80221-55bc-763c-f848-5f00d7ef022c@oracle.com>
References: <15A2F025-BC7B-4773-8E92-0D0E03FC1922@gmail.com>
	<83a80221-55bc-763c-f848-5f00d7ef022c@oracle.com>
Message-ID: <041DB9DE-1FA1-4902-B491-3E6F485CA65F@gmail.com>

2nd review, anyone?

> On 05 Oct 2016, at 05:41, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> +1
> 
> PS. One of these days, we should write an ant task using javac API to
> automate this check! Painful to manually check & fix using IDEs...
> 
> -Sundar
> 
> On 10/5/2016 12:06 AM, Attila Szegedi wrote:
>> Please review JDK-8167117 "insert missing final keywords" at <http://cr.openjdk.java.net/~attila/8167117/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8167117>
>> 
>> Every year or so, this is done once as a kind of anti-entropy task :-)
>> It?s a big patch, but it?s just mechanical addition of missing ?final? keywords everywhere (and organizing imports in only few files); tests were run afterwards.
>> 
>> I have few other things in the pipeline, but my diffs were getting noisy because of my IDE inserting all the missing ?final? keywords in the files I touched, so wanted to get this out of the way in one swoop.
>> 
>> Thanks,
>>  Attila.
> 


From james.laskey at oracle.com  Thu Oct  6 14:26:27 2016
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Thu, 6 Oct 2016 11:26:27 -0300
Subject: Review request for JDK-8167117: insert missing final keywords
In-Reply-To: <15A2F025-BC7B-4773-8E92-0D0E03FC1922@gmail.com>
References: <15A2F025-BC7B-4773-8E92-0D0E03FC1922@gmail.com>
Message-ID: <E135486B-BFC5-4E43-A8A2-CD2F76F21AC8@oracle.com>

+1

> On Oct 4, 2016, at 3:36 PM, Attila Szegedi <szegedia at gmail.com> wrote:
> 
> Please review JDK-8167117 "insert missing final keywords" at <http://cr.openjdk.java.net/~attila/8167117/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8167117>
> 
> Every year or so, this is done once as a kind of anti-entropy task :-)
> It?s a big patch, but it?s just mechanical addition of missing ?final? keywords everywhere (and organizing imports in only few files); tests were run afterwards.
> 
> I have few other things in the pipeline, but my diffs were getting noisy because of my IDE inserting all the missing ?final? keywords in the files I touched, so wanted to get this out of the way in one swoop.
> 
> Thanks,
>  Attila.


From hannes.wallnoefer at oracle.com  Thu Oct  6 14:51:56 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Thu, 6 Oct 2016 16:51:56 +0200
Subject: RFR: 8167289 : Backport ES6 updates from Graal.js
Message-ID: <0112EBD1-4696-4EEB-A94C-DB7EB7D2CED9@oracle.com>

Please review:

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

These is mostly refactoring Andreas did in the Graal.js parser. It also contains minor ES6 parsing fixes. Tests for these will be included together with other additional ES6 tests I?m working on, but I wanted to do a separate commit for the backport, so this issue is labeled noreg-cleanup.

Thanks,
Hannes

From marcus at lagergren.net  Thu Oct  6 19:21:25 2016
From: marcus at lagergren.net (Marcus Lagergren)
Date: Thu, 6 Oct 2016 21:21:25 +0200
Subject: RFR: 8167289 : Backport ES6 updates from Graal.js
In-Reply-To: <0112EBD1-4696-4EEB-A94C-DB7EB7D2CED9@oracle.com>
References: <0112EBD1-4696-4EEB-A94C-DB7EB7D2CED9@oracle.com>
Message-ID: <C3794125-BE4A-44B7-88B7-241D98980B67@lagergren.net>

+1

/M

> On 6 Oct 2016, at 16:51, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8167289
> Webrev: http://cr.openjdk.java.net/~hannesw/8167289/webrev.00/
> 
> These is mostly refactoring Andreas did in the Graal.js parser. It also contains minor ES6 parsing fixes. Tests for these will be included together with other additional ES6 tests I?m working on, but I wanted to do a separate commit for the backport, so this issue is labeled noreg-cleanup.
> 
> Thanks,
> Hannes


From sundararajan.athijegannathan at oracle.com  Fri Oct  7 03:27:45 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 7 Oct 2016 08:57:45 +0530
Subject: RFR: 8167289 : Backport ES6 updates from Graal.js
In-Reply-To: <0112EBD1-4696-4EEB-A94C-DB7EB7D2CED9@oracle.com>
References: <0112EBD1-4696-4EEB-A94C-DB7EB7D2CED9@oracle.com>
Message-ID: <cf4f9bf4-b27c-554f-ed47-d16720432c3d@oracle.com>

+1

-Sundar


On 10/6/2016 8:21 PM, Hannes Walln?fer wrote:
> Please review:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8167289
> Webrev: http://cr.openjdk.java.net/~hannesw/8167289/webrev.00/
>
> These is mostly refactoring Andreas did in the Graal.js parser. It also contains minor ES6 parsing fixes. Tests for these will be included together with other additional ES6 tests I?m working on, but I wanted to do a separate commit for the backport, so this issue is labeled noreg-cleanup.
>
> Thanks,
> Hannes


From hannes.wallnoefer at oracle.com  Fri Oct  7 08:25:56 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Fri, 7 Oct 2016 10:25:56 +0200
Subject: RFR: 8167289 : Backport ES6 updates from Graal.js
In-Reply-To: <cf4f9bf4-b27c-554f-ed47-d16720432c3d@oracle.com>
References: <0112EBD1-4696-4EEB-A94C-DB7EB7D2CED9@oracle.com>
	<cf4f9bf4-b27c-554f-ed47-d16720432c3d@oracle.com>
Message-ID: <0DD22BAA-53C3-4AA1-8F02-33BF5DD6281B@oracle.com>

This change conflicts with Attila?s add-finals change in Parser.java. I uploaded a new webrev with the merged patch. I double-checked that it keeps the finals and that the code I added uses final too.

http://cr.openjdk.java.net/~hannesw/8167289/webrev.01/

Hannes


> Am 07.10.2016 um 05:27 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
> 
> +1
> 
> -Sundar
> 
> 
> On 10/6/2016 8:21 PM, Hannes Walln?fer wrote:
>> Please review:
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167289
>> Webrev: http://cr.openjdk.java.net/~hannesw/8167289/webrev.00/
>> 
>> These is mostly refactoring Andreas did in the Graal.js parser. It also contains minor ES6 parsing fixes. Tests for these will be included together with other additional ES6 tests I?m working on, but I wanted to do a separate commit for the backport, so this issue is labeled noreg-cleanup.
>> 
>> Thanks,
>> Hannes
> 


From sundararajan.athijegannathan at oracle.com  Fri Oct  7 13:16:42 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 07 Oct 2016 18:46:42 +0530
Subject: RFR 8167018: Nashorn and jjs should support --module-path and
	--add-modules options
Message-ID: <57F7A03A.5080508@oracle.com>

Please review.

Bug: https://bugs.openjdk.java.net/browse/JDK-8167018
Nashorn webrev: 
http://cr.openjdk.java.net/~sundar/8167018/nashorn/webrev.00/
JDK webrev (jjs tests): 
http://cr.openjdk.java.net/~sundar/8167018/jdk/webrev.00/

Thanks,
-Sundar

From szegedia at gmail.com  Fri Oct  7 13:22:30 2016
From: szegedia at gmail.com (Attila Szegedi)
Date: Fri, 7 Oct 2016 15:22:30 +0200
Subject: RFR: 8167289 : Backport ES6 updates from Graal.js
In-Reply-To: <0DD22BAA-53C3-4AA1-8F02-33BF5DD6281B@oracle.com>
References: <0112EBD1-4696-4EEB-A94C-DB7EB7D2CED9@oracle.com>
	<cf4f9bf4-b27c-554f-ed47-d16720432c3d@oracle.com>
	<0DD22BAA-53C3-4AA1-8F02-33BF5DD6281B@oracle.com>
Message-ID: <66F5FBDC-7A0A-4481-9ACB-6A8376D4F8D3@gmail.com>

And the patch is now much easier to review! Anyway, apologies for having you make another roundtrip.

That said, I?d prefer if subexpressions (LiteralNode.ArrayLiteralNode)literalNode and literalNode.getElementExpressions() were assigned to some shortish-named locals and used as such to improve the readability of this expression: 

+                if (((LiteralNode.ArrayLiteralNode)literalNode).hasSpread() && ((LiteralNode.ArrayLiteralNode)literalNode).hasTrailingComma()) {
+                    throw error("Rest element must be last", literalNode.getElementExpressions().get(literalNode.getElementExpressions().size() - 1).getToken());
+                }

+1 otherwise. (I?m also fine if you decide to not make this change; it?s admittedly no big deal.)

Attila.


> On 07 Oct 2016, at 10:25, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
> 
> This change conflicts with Attila?s add-finals change in Parser.java. I uploaded a new webrev with the merged patch. I double-checked that it keeps the finals and that the code I added uses final too.
> 
> http://cr.openjdk.java.net/~hannesw/8167289/webrev.01/
> 
> Hannes
> 
> 
>> Am 07.10.2016 um 05:27 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
>> 
>> +1
>> 
>> -Sundar
>> 
>> 
>> On 10/6/2016 8:21 PM, Hannes Walln?fer wrote:
>>> Please review:
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167289
>>> Webrev: http://cr.openjdk.java.net/~hannesw/8167289/webrev.00/
>>> 
>>> These is mostly refactoring Andreas did in the Graal.js parser. It also contains minor ES6 parsing fixes. Tests for these will be included together with other additional ES6 tests I?m working on, but I wanted to do a separate commit for the backport, so this issue is labeled noreg-cleanup.
>>> 
>>> Thanks,
>>> Hannes
>> 
> 


From hannes.wallnoefer at oracle.com  Fri Oct  7 13:31:44 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Fri, 7 Oct 2016 15:31:44 +0200
Subject: RFR: 8167289 : Backport ES6 updates from Graal.js
In-Reply-To: <66F5FBDC-7A0A-4481-9ACB-6A8376D4F8D3@gmail.com>
References: <0112EBD1-4696-4EEB-A94C-DB7EB7D2CED9@oracle.com>
	<cf4f9bf4-b27c-554f-ed47-d16720432c3d@oracle.com>
	<0DD22BAA-53C3-4AA1-8F02-33BF5DD6281B@oracle.com>
	<66F5FBDC-7A0A-4481-9ACB-6A8376D4F8D3@gmail.com>
Message-ID: <93668A33-7C04-4797-B64C-DD237BBE2B47@oracle.com>

Thanks Attila. You?re right about that double cast, but I already pushed the change with Marcus? and Sundar?s reviews. I?ll include that clean-up in my next commit.

Hannes


> Am 07.10.2016 um 15:22 schrieb Attila Szegedi <szegedia at gmail.com>:
> 
> And the patch is now much easier to review! Anyway, apologies for having you make another roundtrip.
> 
> That said, I?d prefer if subexpressions (LiteralNode.ArrayLiteralNode)literalNode and literalNode.getElementExpressions() were assigned to some shortish-named locals and used as such to improve the readability of this expression: 
> 
> +                if (((LiteralNode.ArrayLiteralNode)literalNode).hasSpread() && ((LiteralNode.ArrayLiteralNode)literalNode).hasTrailingComma()) {
> +                    throw error("Rest element must be last", literalNode.getElementExpressions().get(literalNode.getElementExpressions().size() - 1).getToken());
> +                }
> 
> +1 otherwise. (I?m also fine if you decide to not make this change; it?s admittedly no big deal.)
> 
> Attila.
> 
> 
>> On 07 Oct 2016, at 10:25, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
>> 
>> This change conflicts with Attila?s add-finals change in Parser.java. I uploaded a new webrev with the merged patch. I double-checked that it keeps the finals and that the code I added uses final too.
>> 
>> http://cr.openjdk.java.net/~hannesw/8167289/webrev.01/
>> 
>> Hannes
>> 
>> 
>>> Am 07.10.2016 um 05:27 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
>>> 
>>> +1
>>> 
>>> -Sundar
>>> 
>>> 
>>> On 10/6/2016 8:21 PM, Hannes Walln?fer wrote:
>>>> Please review:
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167289
>>>> Webrev: http://cr.openjdk.java.net/~hannesw/8167289/webrev.00/
>>>> 
>>>> These is mostly refactoring Andreas did in the Graal.js parser. It also contains minor ES6 parsing fixes. Tests for these will be included together with other additional ES6 tests I?m working on, but I wanted to do a separate commit for the backport, so this issue is labeled noreg-cleanup.
>>>> 
>>>> Thanks,
>>>> Hannes
>>> 
>> 
> 


From james.laskey at oracle.com  Fri Oct  7 13:36:01 2016
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Fri, 7 Oct 2016 10:36:01 -0300
Subject: RFR 8167018: Nashorn and jjs should support --module-path and
	--add-modules options
In-Reply-To: <57F7A03A.5080508@oracle.com>
References: <57F7A03A.5080508@oracle.com>
Message-ID: <3462F33F-8FE2-4D7C-986F-16E9376AAC87@oracle.com>

+1

> On Oct 7, 2016, at 10:16 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8167018
> Nashorn webrev: http://cr.openjdk.java.net/~sundar/8167018/nashorn/webrev.00/
> JDK webrev (jjs tests): http://cr.openjdk.java.net/~sundar/8167018/jdk/webrev.00/
> 
> Thanks,
> -Sundar


From hannes.wallnoefer at oracle.com  Fri Oct  7 13:50:52 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Fri, 7 Oct 2016 15:50:52 +0200
Subject: RFR 8167018: Nashorn and jjs should support --module-path and
	--add-modules options
In-Reply-To: <3462F33F-8FE2-4D7C-986F-16E9376AAC87@oracle.com>
References: <57F7A03A.5080508@oracle.com>
	<3462F33F-8FE2-4D7C-986F-16E9376AAC87@oracle.com>
Message-ID: <AD5F7415-9043-4687-AE90-556102A68390@oracle.com>

+1, very nice to have jjs as first class Jigsaw citizen!

Hannes


> Am 07.10.2016 um 15:36 schrieb Jim Laskey (Oracle) <james.laskey at oracle.com>:
> 
> +1
> 
>> On Oct 7, 2016, at 10:16 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
>> 
>> Please review.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167018
>> Nashorn webrev: http://cr.openjdk.java.net/~sundar/8167018/nashorn/webrev.00/
>> JDK webrev (jjs tests): http://cr.openjdk.java.net/~sundar/8167018/jdk/webrev.00/
>> 
>> Thanks,
>> -Sundar
> 


From szegedia at gmail.com  Mon Oct 10 20:53:58 2016
From: szegedia at gmail.com (Attila Szegedi)
Date: Mon, 10 Oct 2016 22:53:58 +0200
Subject: Review request for JDK-8167443: Nashorn static method linking
	bypasses autoexported linkers
Message-ID: <DE86A5EE-2CA3-4CBD-A4E2-68304FB8E40E@gmail.com>

Please review JDK-8167443 "Nashorn static method linking bypasses autoexported linkers" at <http://cr.openjdk.java.net/~attila/8167443/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8167443>

This is a fairly minor thing, but it was breaking one of our Dynalink samples so it actually brought to light a conceptual inconsistency.

I wrote a test for it, by factoring out the body of DynamicLinkerFactoryTest.autoLoadedLinkerTest and using it twice (once as original, although now it looks up the Object.toString method) and once with a static method (System.currentTimeMillis).


Thanks,
  Attila.

From hannes.wallnoefer at oracle.com  Tue Oct 11 08:36:00 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Tue, 11 Oct 2016 10:36:00 +0200
Subject: Review request for JDK-8167443: Nashorn static method linking
	bypasses autoexported linkers
In-Reply-To: <DE86A5EE-2CA3-4CBD-A4E2-68304FB8E40E@gmail.com>
References: <DE86A5EE-2CA3-4CBD-A4E2-68304FB8E40E@gmail.com>
Message-ID: <5918DF16-9E5C-45B9-8664-50CF04A81FBB@oracle.com>

Hi Attila, this looks good.

Hannes


> Am 10.10.2016 um 22:53 schrieb Attila Szegedi <szegedia at gmail.com>:
> 
> Please review JDK-8167443 "Nashorn static method linking bypasses autoexported linkers" at <http://cr.openjdk.java.net/~attila/8167443/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8167443>
> 
> This is a fairly minor thing, but it was breaking one of our Dynalink samples so it actually brought to light a conceptual inconsistency.
> 
> I wrote a test for it, by factoring out the body of DynamicLinkerFactoryTest.autoLoadedLinkerTest and using it twice (once as original, although now it looks up the Object.toString method) and once with a static method (System.currentTimeMillis).
> 
> 
> Thanks,
>  Attila.


From sundararajan.athijegannathan at oracle.com  Wed Oct 12 03:03:33 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 12 Oct 2016 08:33:33 +0530
Subject: Review request for JDK-8167443: Nashorn static method linking
	bypasses autoexported linkers
In-Reply-To: <DE86A5EE-2CA3-4CBD-A4E2-68304FB8E40E@gmail.com>
References: <DE86A5EE-2CA3-4CBD-A4E2-68304FB8E40E@gmail.com>
Message-ID: <00797916-3216-a259-aa5d-0f2873012bee@oracle.com>

Good catch! +1

PS. We should perhaps convert few of those dynalink samples as tests..

Thanks,

-Sundar

On 10/11/2016 2:23 AM, Attila Szegedi wrote:
> Please review JDK-8167443 "Nashorn static method linking bypasses autoexported linkers" at <http://cr.openjdk.java.net/~attila/8167443/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8167443>
>
> This is a fairly minor thing, but it was breaking one of our Dynalink samples so it actually brought to light a conceptual inconsistency.
>
> I wrote a test for it, by factoring out the body of DynamicLinkerFactoryTest.autoLoadedLinkerTest and using it twice (once as original, although now it looks up the Object.toString method) and once with a static method (System.currentTimeMillis).
>
>
> Thanks,
>   Attila.


From Joerg.Frantzius at aperto.com  Wed Oct 12 14:10:47 2016
From: Joerg.Frantzius at aperto.com (=?utf-8?B?RnJhbnR6aXVzLCBKw7ZyZw==?=)
Date: Wed, 12 Oct 2016 14:10:47 +0000
Subject: typeof Long is not 'number' anymore
Message-ID: <85A6A4E1-A03D-4770-91FD-00BEF601CB65@aperto.com>

Hi,

as of JDK 1.8.0_101, the following JUnit test fails:

    @Test
    public void testLongIsNumber() {
        jdk.nashorn.api.scripting.ScriptObjectMirror isNumberFunction = eval("function isNumber(arg) {\n" +
            "    return typeof arg === 'number';\n" +
            "}\n" +
            "");
        Object result = isNumberFunction.call(isNumberFunction, 1L);
        assertTrue((boolean) result);
    }

This breaks e.g. Nodyn, where Long numbers resulting from java.io.File.length() are passed into https://nodejs.org/api/util.html#util_util_isnumber_object , resulting in some ?if" clause now taking the wrong turn. I guess this is a side-effect of https://bugs.openjdk.java.net/browse/JDK-8144020 .

While I?m probably able to patch this in Nodyn, I find it a bit frightening that any other code out there that relies on Longs being typeof ?number? will break now, in particular because there is a lot of JDK API that returns Long...

Regards,
J?rg


---

Dipl. Inf. J?rg von Frantzius, Technical Director

E-Mail joerg.frantzius at aperto.com

Phone +49 30 283921-318
Fax +49 30 283921-29

Aperto AG ? An IBM Company
Chausseestra?e 5, D-10115 Berlin
http://www.aperto.com<http://www.aperto.de/>
http://www.facebook.com/aperto
https://www.xing.com/companies/apertoag

HRB 77049 B, AG Berlin Charlottenburg
Vorstand: Dirk Buddensiek (Vorsitzender), Kai Gro?mann, Stephan Haagen, Daniel Simon
Aufsichtsrat: Matthew Candy (Vorsitzender)


From sundararajan.athijegannathan at oracle.com  Wed Oct 12 15:11:00 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 12 Oct 2016 20:41:00 +0530
Subject: RFR 8167614: Avoid module dependency from jdk.dynalink to
	jdk.internal.module of java.base module
Message-ID: <601a2a17-7436-e380-aa86-ec7ceb0c4f4d@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8167614

jdk webrev: http://cr.openjdk.java.net/~sundar/8167614/jdk/webrev.00/

nashorn webrev:
http://cr.openjdk.java.net/~sundar/8167614/nashorn/webrev.00/

Thanks,

-Sundar


From emilian.bold at gmail.com  Wed Oct 12 15:11:54 2016
From: emilian.bold at gmail.com (Emilian Bold)
Date: Wed, 12 Oct 2016 18:11:54 +0300
Subject: typeof Long is not 'number' anymore
In-Reply-To: <85A6A4E1-A03D-4770-91FD-00BEF601CB65@aperto.com>
References: <85A6A4E1-A03D-4770-91FD-00BEF601CB65@aperto.com>
Message-ID: <CAL6R17D_4ovFR=aRAXfnFuYA2-ZmWLiLXMO_qu1H9-uN6z=i2Q@mail.gmail.com>

I just read a few of the bugs linked and it does seem worrisome. So,
Nashorn cannot reliably be used as a glue between Java code that uses longs?


--emi

On Wed, Oct 12, 2016 at 5:10 PM, Frantzius, J?rg <Joerg.Frantzius at aperto.com
> wrote:

> Hi,
>
> as of JDK 1.8.0_101, the following JUnit test fails:
>
>     @Test
>     public void testLongIsNumber() {
>         jdk.nashorn.api.scripting.ScriptObjectMirror isNumberFunction =
> eval("function isNumber(arg) {\n" +
>             "    return typeof arg === 'number';\n" +
>             "}\n" +
>             "");
>         Object result = isNumberFunction.call(isNumberFunction, 1L);
>         assertTrue((boolean) result);
>     }
>
> This breaks e.g. Nodyn, where Long numbers resulting from
> java.io.File.length() are passed into https://nodejs.org/api/util.
> html#util_util_isnumber_object , resulting in some ?if" clause now taking
> the wrong turn. I guess this is a side-effect of
> https://bugs.openjdk.java.net/browse/JDK-8144020 .
>
> While I?m probably able to patch this in Nodyn, I find it a bit
> frightening that any other code out there that relies on Longs being typeof
> ?number? will break now, in particular because there is a lot of JDK API
> that returns Long...
>
> Regards,
> J?rg
>
>
> ---
>
> Dipl. Inf. J?rg von Frantzius, Technical Director
>
> E-Mail joerg.frantzius at aperto.com
>
> Phone +49 30 283921-318
> Fax +49 30 283921-29
>
> Aperto AG ? An IBM Company
> Chausseestra?e 5, D-10115 Berlin
> http://www.aperto.com<http://www.aperto.de/>
> http://www.facebook.com/aperto
> https://www.xing.com/companies/apertoag
>
> HRB 77049 B, AG Berlin Charlottenburg
> Vorstand: Dirk Buddensiek (Vorsitzender), Kai Gro?mann, Stephan Haagen,
> Daniel Simon
> Aufsichtsrat: Matthew Candy (Vorsitzender)
>
>

From james.laskey at oracle.com  Wed Oct 12 15:14:36 2016
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Wed, 12 Oct 2016 12:14:36 -0300
Subject: RFR 8167614: Avoid module dependency from jdk.dynalink to
	jdk.internal.module of java.base module
In-Reply-To: <601a2a17-7436-e380-aa86-ec7ceb0c4f4d@oracle.com>
References: <601a2a17-7436-e380-aa86-ec7ceb0c4f4d@oracle.com>
Message-ID: <368D4001-9DD6-4006-970C-0EBD8D2D5698@oracle.com>

+1

> On Oct 12, 2016, at 12:11 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8167614
> 
> jdk webrev: http://cr.openjdk.java.net/~sundar/8167614/jdk/webrev.00/
> 
> nashorn webrev:
> http://cr.openjdk.java.net/~sundar/8167614/nashorn/webrev.00/
> 
> Thanks,
> 
> -Sundar
> 


From Alan.Bateman at oracle.com  Wed Oct 12 15:21:13 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 12 Oct 2016 16:21:13 +0100
Subject: RFR 8167614: Avoid module dependency from jdk.dynalink to
	jdk.internal.module of java.base module
In-Reply-To: <601a2a17-7436-e380-aa86-ec7ceb0c4f4d@oracle.com>
References: <601a2a17-7436-e380-aa86-ec7ceb0c4f4d@oracle.com>
Message-ID: <ffba0592-8a9e-6a51-9b91-c078f2ac9592@oracle.com>

On 12/10/2016 16:11, Sundararajan Athijegannathan wrote:

> Bug: https://bugs.openjdk.java.net/browse/JDK-8167614
>
> jdk webrev: http://cr.openjdk.java.net/~sundar/8167614/jdk/webrev.00/
>
> nashorn webrev:
> http://cr.openjdk.java.net/~sundar/8167614/nashorn/webrev.00/
>
In jdk/nashorn/internal/runtime/Context.java then it checks if the 
java.sql and java.sql.rowset are observable. This does not mean they are 
in the boot layer, I think you want 
Layer.boot().findModule("java.sql").ifPresent(...). However, the this 
code in Nashorn makes me wonder if this is actually needed or why these 
two are special cased.

-Alan

From sundararajan.athijegannathan at oracle.com  Wed Oct 12 15:33:19 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 12 Oct 2016 21:03:19 +0530
Subject: RFR 8167614: Avoid module dependency from jdk.dynalink to
	jdk.internal.module of java.base module
In-Reply-To: <ffba0592-8a9e-6a51-9b91-c078f2ac9592@oracle.com>
References: <601a2a17-7436-e380-aa86-ec7ceb0c4f4d@oracle.com>
	<ffba0592-8a9e-6a51-9b91-c078f2ac9592@oracle.com>
Message-ID: <c6799d0f-e44c-9fe2-b9a8-59c76034e645@oracle.com>

Dynalink normally uses unreflect with publicLookup to get method handles
for j.l.reflect.Method objects (found reflectively). But, publicLookup
can not be used to unreflect caller sensitive methods. So, dynalink uses
specific Lookup object from the callsite - for example, lookup of the
Nashorn script (generated) class. But, script module has to have
read-edge the module of the CallerSensitive method's class - or else
that unreflect will fail.

Dynalink used to automatically add those necessary add edges. With the
current change, nashorn adds necessary read edges. CallerSensitive
methods are found only in java.base, java.logging, java.sql and
java.sql.rowset modules - the first two are always present [in nashorn's
compact1 dependency world]. The later two are checked for presence and
read-edges are added conditionally (see ScriptLoader.java changes).

Yes, I need boot layer modules only and I'll change that.

-Sundar

On 10/12/2016 8:51 PM, Alan Bateman wrote:
> On 12/10/2016 16:11, Sundararajan Athijegannathan wrote:
>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167614
>>
>> jdk webrev: http://cr.openjdk.java.net/~sundar/8167614/jdk/webrev.00/
>>
>> nashorn webrev:
>> http://cr.openjdk.java.net/~sundar/8167614/nashorn/webrev.00/
>>
> In jdk/nashorn/internal/runtime/Context.java then it checks if the
> java.sql and java.sql.rowset are observable. This does not mean they
> are in the boot layer, I think you want
> Layer.boot().findModule("java.sql").ifPresent(...). However, the this
> code in Nashorn makes me wonder if this is actually needed or why
> these two are special cased.
>
> -Alan


From joaovarandas at inpaas.com  Wed Oct 12 15:42:02 2016
From: joaovarandas at inpaas.com (=?UTF-8?Q?Jo=C3=A3o_Paulo_Varandas?=)
Date: Wed, 12 Oct 2016 12:42:02 -0300
Subject: typeof Long is not 'number' anymore
In-Reply-To: <CAL6R17D_4ovFR=aRAXfnFuYA2-ZmWLiLXMO_qu1H9-uN6z=i2Q@mail.gmail.com>
References: <85A6A4E1-A03D-4770-91FD-00BEF601CB65@aperto.com>
	<CAL6R17D_4ovFR=aRAXfnFuYA2-ZmWLiLXMO_qu1H9-uN6z=i2Q@mail.gmail.com>
Message-ID: <CACoP5y2+GTcts-GYdv=WtDr0iLYXdj+cTV01GexacGzSN0Bg9Q@mail.gmail.com>

Joerg/Emilian.

This is a questioning we've raised some time ago.
I still cannot upgrade from revision 91 because of the side effects of this
change ...

It seems that we need some wrapping/unwrapping when working with 'Long's in
Nashorn, I don't like this either, but it seems that there's a gap between
Long, Double and JSNumber max values which was bringing a loss of precision
with long values in Nashorn. Thus, Long is now "object" ...

Check out:
http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-August/006450.html




*Jo?o Paulo Varandas*+55 11 99889-2321
joaovarandas at inpaas.com


2016-10-12 12:11 GMT-03:00 Emilian Bold <emilian.bold at gmail.com>:

> I just read a few of the bugs linked and it does seem worrisome. So,
> Nashorn cannot reliably be used as a glue between Java code that uses
> longs?
>
>
> --emi
>
> On Wed, Oct 12, 2016 at 5:10 PM, Frantzius, J?rg <
> Joerg.Frantzius at aperto.com
> > wrote:
>
> > Hi,
> >
> > as of JDK 1.8.0_101, the following JUnit test fails:
> >
> >     @Test
> >     public void testLongIsNumber() {
> >         jdk.nashorn.api.scripting.ScriptObjectMirror isNumberFunction =
> > eval("function isNumber(arg) {\n" +
> >             "    return typeof arg === 'number';\n" +
> >             "}\n" +
> >             "");
> >         Object result = isNumberFunction.call(isNumberFunction, 1L);
> >         assertTrue((boolean) result);
> >     }
> >
> > This breaks e.g. Nodyn, where Long numbers resulting from
> > java.io.File.length() are passed into https://nodejs.org/api/util.
> > html#util_util_isnumber_object , resulting in some ?if" clause now taking
> > the wrong turn. I guess this is a side-effect of
> > https://bugs.openjdk.java.net/browse/JDK-8144020 .
> >
> > While I?m probably able to patch this in Nodyn, I find it a bit
> > frightening that any other code out there that relies on Longs being
> typeof
> > ?number? will break now, in particular because there is a lot of JDK API
> > that returns Long...
> >
> > Regards,
> > J?rg
> >
> >
> > ---
> >
> > Dipl. Inf. J?rg von Frantzius, Technical Director
> >
> > E-Mail joerg.frantzius at aperto.com
> >
> > Phone +49 30 283921-318
> > Fax +49 30 283921-29
> >
> > Aperto AG ? An IBM Company
> > Chausseestra?e 5, D-10115 Berlin
> > http://www.aperto.com<http://www.aperto.de/>
> > http://www.facebook.com/aperto
> > https://www.xing.com/companies/apertoag
> >
> > HRB 77049 B, AG Berlin Charlottenburg
> > Vorstand: Dirk Buddensiek (Vorsitzender), Kai Gro?mann, Stephan Haagen,
> > Daniel Simon
> > Aufsichtsrat: Matthew Candy (Vorsitzender)
> >
> >
>

-- 
"Esta mensagem, incluindo seus anexos, pode conter informacoes 
confidenciais e privilegiadas. 
Se voce a recebeu por engano, solicitamos que a apague e avise o remetente 
imediatamente. 
Opinioes ou informacoes aqui contidas nao refletem necessariamente a 
posicao oficial da Plusoft."

"Antes de imprimir, pense em sua responsabilidade e compromisso com o MEIO 
AMBIENTE"


From emilian.bold at gmail.com  Wed Oct 12 15:58:33 2016
From: emilian.bold at gmail.com (Emilian Bold)
Date: Wed, 12 Oct 2016 18:58:33 +0300
Subject: typeof Long is not 'number' anymore
In-Reply-To: <CACoP5y2+GTcts-GYdv=WtDr0iLYXdj+cTV01GexacGzSN0Bg9Q@mail.gmail.com>
References: <85A6A4E1-A03D-4770-91FD-00BEF601CB65@aperto.com>
	<CAL6R17D_4ovFR=aRAXfnFuYA2-ZmWLiLXMO_qu1H9-uN6z=i2Q@mail.gmail.com>
	<CACoP5y2+GTcts-GYdv=WtDr0iLYXdj+cTV01GexacGzSN0Bg9Q@mail.gmail.com>
Message-ID: <CAL6R17A8oj7=HpHqyOuT9Vx7RnLDULEHn2jfucSDKeeWe95qpQ@mail.gmail.com>

Jo?o, I actually remember your thread but I assumed it's about Long
instances. Somehow it didn't click that it's about long primitives too.

java.io.File.length() is something I easily see anybody using in some basic
Nashorn script without expecting the value to be corrupted.


--emi

On Wed, Oct 12, 2016 at 6:42 PM, Jo?o Paulo Varandas <
joaovarandas at inpaas.com> wrote:

> Joerg/Emilian.
>
> This is a questioning we've raised some time ago.
> I still cannot upgrade from revision 91 because of the side effects of
> this change ...
>
> It seems that we need some wrapping/unwrapping when working with 'Long's
> in Nashorn, I don't like this either, but it seems that there's a gap
> between Long, Double and JSNumber max values which was bringing a loss of
> precision with long values in Nashorn. Thus, Long is now "object" ...
>
> Check out:
> http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-August/006450.html
>
>
>
>
> *Jo?o Paulo Varandas*+55 11 99889-2321
> joaovarandas at inpaas.com
>
>
> 2016-10-12 12:11 GMT-03:00 Emilian Bold <emilian.bold at gmail.com>:
>
>> I just read a few of the bugs linked and it does seem worrisome. So,
>> Nashorn cannot reliably be used as a glue between Java code that uses
>> longs?
>>
>>
>> --emi
>>
>> On Wed, Oct 12, 2016 at 5:10 PM, Frantzius, J?rg <
>> Joerg.Frantzius at aperto.com
>> > wrote:
>>
>> > Hi,
>> >
>> > as of JDK 1.8.0_101, the following JUnit test fails:
>> >
>> >     @Test
>> >     public void testLongIsNumber() {
>> >         jdk.nashorn.api.scripting.ScriptObjectMirror isNumberFunction =
>> > eval("function isNumber(arg) {\n" +
>> >             "    return typeof arg === 'number';\n" +
>> >             "}\n" +
>> >             "");
>> >         Object result = isNumberFunction.call(isNumberFunction, 1L);
>> >         assertTrue((boolean) result);
>> >     }
>> >
>> > This breaks e.g. Nodyn, where Long numbers resulting from
>> > java.io.File.length() are passed into https://nodejs.org/api/util.
>> > html#util_util_isnumber_object , resulting in some ?if" clause now
>> taking
>> > the wrong turn. I guess this is a side-effect of
>> > https://bugs.openjdk.java.net/browse/JDK-8144020 .
>> >
>> > While I?m probably able to patch this in Nodyn, I find it a bit
>> > frightening that any other code out there that relies on Longs being
>> typeof
>> > ?number? will break now, in particular because there is a lot of JDK API
>> > that returns Long...
>> >
>> > Regards,
>> > J?rg
>> >
>> >
>> > ---
>> >
>> > Dipl. Inf. J?rg von Frantzius, Technical Director
>> >
>> > E-Mail joerg.frantzius at aperto.com
>> >
>> > Phone +49 30 283921-318
>> > Fax +49 30 283921-29
>> >
>> > Aperto AG ? An IBM Company
>> > Chausseestra?e 5, D-10115 Berlin
>> > http://www.aperto.com<http://www.aperto.de/>
>> > http://www.facebook.com/aperto
>> > https://www.xing.com/companies/apertoag
>> >
>> > HRB 77049 B, AG Berlin Charlottenburg
>> > Vorstand: Dirk Buddensiek (Vorsitzender), Kai Gro?mann, Stephan Haagen,
>> > Daniel Simon
>> > Aufsichtsrat: Matthew Candy (Vorsitzender)
>> >
>> >
>>
>
>
> "Esta mensagem, incluindo seus anexos, pode conter informacoes
> confidenciais e privilegiadas.
> Se voce a recebeu por engano, solicitamos que a apague e avise o remetente
> imediatamente.
> Opinioes ou informacoes aqui contidas nao refletem necessariamente a
> posicao oficial da Plusoft."
>
> "Antes de imprimir, pense em sua responsabilidade e compromisso com o MEIO
> AMBIENTE"
>
>

From Alan.Bateman at oracle.com  Wed Oct 12 16:12:05 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 12 Oct 2016 17:12:05 +0100
Subject: RFR 8167614: Avoid module dependency from jdk.dynalink to
	jdk.internal.module of java.base module
In-Reply-To: <c6799d0f-e44c-9fe2-b9a8-59c76034e645@oracle.com>
References: <601a2a17-7436-e380-aa86-ec7ceb0c4f4d@oracle.com>
	<ffba0592-8a9e-6a51-9b91-c078f2ac9592@oracle.com>
	<c6799d0f-e44c-9fe2-b9a8-59c76034e645@oracle.com>
Message-ID: <c1d7e4a3-9202-2154-bbc3-d706db8ca5e4@oracle.com>

On 12/10/2016 16:33, Sundararajan Athijegannathan wrote:

> :
>
> Dynalink used to automatically add those necessary add edges. With the
> current change, nashorn adds necessary read edges. CallerSensitive
> methods are found only in java.base, java.logging, java.sql and
> java.sql.rowset modules - the first two are always present [in nashorn's
> compact1 dependency world]. The later two are checked for presence and
> read-edges are added conditionally (see ScriptLoader.java changes).
JDK-8154346 tracks fixing java.sql.DriverManager, there are 
compatibility concerns to changing it but it is being looked at.

I'm not familiar with the issue in the java.sql.rowset module but it may 
be that the security checks in SerialJavaObject::getFields can be 
re-visited (I don't know all the history on that).


>
> Yes, I need boot layer modules only and I'll change that.
>
Thanks.

-Alan.

From sundararajan.athijegannathan at oracle.com  Wed Oct 12 16:31:29 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 12 Oct 2016 22:01:29 +0530
Subject: RFR 8167614: Avoid module dependency from jdk.dynalink to
	jdk.internal.module of java.base module
In-Reply-To: <c1d7e4a3-9202-2154-bbc3-d706db8ca5e4@oracle.com>
References: <601a2a17-7436-e380-aa86-ec7ceb0c4f4d@oracle.com>
	<ffba0592-8a9e-6a51-9b91-c078f2ac9592@oracle.com>
	<c6799d0f-e44c-9fe2-b9a8-59c76034e645@oracle.com>
	<c1d7e4a3-9202-2154-bbc3-d706db8ca5e4@oracle.com>
Message-ID: <98c9502d-4cf0-e58b-1e95-7b7a0c81c493@oracle.com>

Updated nashorn webrev:
http://cr.openjdk.java.net/~sundar/8167614/nashorn/webrev.01/

Changed to use Layer.boot().findModule.

Thanks

-Sundar


On 10/12/2016 9:42 PM, Alan Bateman wrote:
> On 12/10/2016 16:33, Sundararajan Athijegannathan wrote:
>
>> :
>>
>> Dynalink used to automatically add those necessary add edges. With the
>> current change, nashorn adds necessary read edges. CallerSensitive
>> methods are found only in java.base, java.logging, java.sql and
>> java.sql.rowset modules - the first two are always present [in nashorn's
>> compact1 dependency world]. The later two are checked for presence and
>> read-edges are added conditionally (see ScriptLoader.java changes).
> JDK-8154346 tracks fixing java.sql.DriverManager, there are
> compatibility concerns to changing it but it is being looked at.
>
> I'm not familiar with the issue in the java.sql.rowset module but it
> may be that the security checks in SerialJavaObject::getFields can be
> re-visited (I don't know all the history on that).
>
>
>>
>> Yes, I need boot layer modules only and I'll change that.
>>
> Thanks.
>
> -Alan.


From Alan.Bateman at oracle.com  Wed Oct 12 17:05:32 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 12 Oct 2016 18:05:32 +0100
Subject: RFR 8167614: Avoid module dependency from jdk.dynalink to
	jdk.internal.module of java.base module
In-Reply-To: <98c9502d-4cf0-e58b-1e95-7b7a0c81c493@oracle.com>
References: <601a2a17-7436-e380-aa86-ec7ceb0c4f4d@oracle.com>
	<ffba0592-8a9e-6a51-9b91-c078f2ac9592@oracle.com>
	<c6799d0f-e44c-9fe2-b9a8-59c76034e645@oracle.com>
	<c1d7e4a3-9202-2154-bbc3-d706db8ca5e4@oracle.com>
	<98c9502d-4cf0-e58b-1e95-7b7a0c81c493@oracle.com>
Message-ID: <34c02e08-9b29-836e-8207-c196f0a5c017@oracle.com>

On 12/10/2016 17:31, Sundararajan Athijegannathan wrote:

> Updated nashorn webrev:
> http://cr.openjdk.java.net/~sundar/8167614/nashorn/webrev.01/
>
> Changed to use Layer.boot().findModule.
>
That loos okay to me. I assume that once we fix the issues in java.sql 
that this code can be removed.

-Alan

From hannes.wallnoefer at oracle.com  Wed Oct 12 17:08:06 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Wed, 12 Oct 2016 19:08:06 +0200
Subject: typeof Long is not 'number' anymore
In-Reply-To: <CAL6R17A8oj7=HpHqyOuT9Vx7RnLDULEHn2jfucSDKeeWe95qpQ@mail.gmail.com>
References: <85A6A4E1-A03D-4770-91FD-00BEF601CB65@aperto.com>
	<CAL6R17D_4ovFR=aRAXfnFuYA2-ZmWLiLXMO_qu1H9-uN6z=i2Q@mail.gmail.com>
	<CACoP5y2+GTcts-GYdv=WtDr0iLYXdj+cTV01GexacGzSN0Bg9Q@mail.gmail.com>
	<CAL6R17A8oj7=HpHqyOuT9Vx7RnLDULEHn2jfucSDKeeWe95qpQ@mail.gmail.com>
Message-ID: <692A61DC-21D3-4F86-96EC-09CB8E03DD96@oracle.com>

I am sorry about the inconvenience this is causing. ECMA defines JavaScript numbers as 64 bit doubles, and Java longs do not fit into this without either losing precision for large values or breaking the spec elsewhere. We did a lot of soul-searching on this and don?t think there?s any other solution.

However, it is not too hard to work around this. A Long object can be converted to a number calling the global Number() function without new keyword, or, if that is too verbose, by just using the unary + operator:

    Number(javaLong) // converts javaLong to a number
    +javaLong   // same

This will work seamlessly with older versions of Nashorn where javaLong is already considered a number, so no special casing is required. Again, I?m sorry for the inconvenience, but this is how things are and we are not planning to go back.

Hannes


> Am 12.10.2016 um 17:58 schrieb Emilian Bold <emilian.bold at gmail.com>:
> 
> Jo?o, I actually remember your thread but I assumed it's about Long
> instances. Somehow it didn't click that it's about long primitives too.
> 
> java.io.File.length() is something I easily see anybody using in some basic
> Nashorn script without expecting the value to be corrupted.
> 
> 
> --emi
> 
> On Wed, Oct 12, 2016 at 6:42 PM, Jo?o Paulo Varandas <
> joaovarandas at inpaas.com> wrote:
> 
>> Joerg/Emilian.
>> 
>> This is a questioning we've raised some time ago.
>> I still cannot upgrade from revision 91 because of the side effects of
>> this change ...
>> 
>> It seems that we need some wrapping/unwrapping when working with 'Long's
>> in Nashorn, I don't like this either, but it seems that there's a gap
>> between Long, Double and JSNumber max values which was bringing a loss of
>> precision with long values in Nashorn. Thus, Long is now "object" ...
>> 
>> Check out:
>> http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-August/006450.html
>> 
>> 
>> 
>> 
>> *Jo?o Paulo Varandas*+55 11 99889-2321
>> joaovarandas at inpaas.com
>> 
>> 
>> 2016-10-12 12:11 GMT-03:00 Emilian Bold <emilian.bold at gmail.com>:
>> 
>>> I just read a few of the bugs linked and it does seem worrisome. So,
>>> Nashorn cannot reliably be used as a glue between Java code that uses
>>> longs?
>>> 
>>> 
>>> --emi
>>> 
>>> On Wed, Oct 12, 2016 at 5:10 PM, Frantzius, J?rg <
>>> Joerg.Frantzius at aperto.com
>>>> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> as of JDK 1.8.0_101, the following JUnit test fails:
>>>> 
>>>>    @Test
>>>>    public void testLongIsNumber() {
>>>>        jdk.nashorn.api.scripting.ScriptObjectMirror isNumberFunction =
>>>> eval("function isNumber(arg) {\n" +
>>>>            "    return typeof arg === 'number';\n" +
>>>>            "}\n" +
>>>>            "");
>>>>        Object result = isNumberFunction.call(isNumberFunction, 1L);
>>>>        assertTrue((boolean) result);
>>>>    }
>>>> 
>>>> This breaks e.g. Nodyn, where Long numbers resulting from
>>>> java.io.File.length() are passed into https://nodejs.org/api/util.
>>>> html#util_util_isnumber_object , resulting in some ?if" clause now
>>> taking
>>>> the wrong turn. I guess this is a side-effect of
>>>> https://bugs.openjdk.java.net/browse/JDK-8144020 .
>>>> 
>>>> While I?m probably able to patch this in Nodyn, I find it a bit
>>>> frightening that any other code out there that relies on Longs being
>>> typeof
>>>> ?number? will break now, in particular because there is a lot of JDK API
>>>> that returns Long...
>>>> 
>>>> Regards,
>>>> J?rg
>>>> 
>>>> 
>>>> ---
>>>> 
>>>> Dipl. Inf. J?rg von Frantzius, Technical Director
>>>> 
>>>> E-Mail joerg.frantzius at aperto.com
>>>> 
>>>> Phone +49 30 283921-318
>>>> Fax +49 30 283921-29
>>>> 
>>>> Aperto AG ? An IBM Company
>>>> Chausseestra?e 5, D-10115 Berlin
>>>> http://www.aperto.com<http://www.aperto.de/>
>>>> http://www.facebook.com/aperto
>>>> https://www.xing.com/companies/apertoag
>>>> 
>>>> HRB 77049 B, AG Berlin Charlottenburg
>>>> Vorstand: Dirk Buddensiek (Vorsitzender), Kai Gro?mann, Stephan Haagen,
>>>> Daniel Simon
>>>> Aufsichtsrat: Matthew Candy (Vorsitzender)
>>>> 
>>>> 
>>> 
>> 
>> 
>> "Esta mensagem, incluindo seus anexos, pode conter informacoes
>> confidenciais e privilegiadas.
>> Se voce a recebeu por engano, solicitamos que a apague e avise o remetente
>> imediatamente.
>> Opinioes ou informacoes aqui contidas nao refletem necessariamente a
>> posicao oficial da Plusoft."
>> 
>> "Antes de imprimir, pense em sua responsabilidade e compromisso com o MEIO
>> AMBIENTE"
>> 
>> 


From szegedia at gmail.com  Thu Oct 13 11:05:25 2016
From: szegedia at gmail.com (Attila Szegedi)
Date: Thu, 13 Oct 2016 13:05:25 +0200
Subject: typeof Long is not 'number' anymore
In-Reply-To: <692A61DC-21D3-4F86-96EC-09CB8E03DD96@oracle.com>
References: <85A6A4E1-A03D-4770-91FD-00BEF601CB65@aperto.com>
	<CAL6R17D_4ovFR=aRAXfnFuYA2-ZmWLiLXMO_qu1H9-uN6z=i2Q@mail.gmail.com>
	<CACoP5y2+GTcts-GYdv=WtDr0iLYXdj+cTV01GexacGzSN0Bg9Q@mail.gmail.com>
	<CAL6R17A8oj7=HpHqyOuT9Vx7RnLDULEHn2jfucSDKeeWe95qpQ@mail.gmail.com>
	<692A61DC-21D3-4F86-96EC-09CB8E03DD96@oracle.com>
Message-ID: <F0B0F816-F159-4F9C-B0DA-34B250BFADAA@gmail.com>

I think Emilian?s example of File.length() is actually in favor of not converting Longs to doubles automatically. Although to be fair, 53 bits of double precision can still correctly represent a file length of up to cca. 8 petabytes if I?m not mistaken, so? probably Not a Problem For Most People? yet unless you run a data warehouse :-)

As a funny aside, I remember being back at Twitter around the time we crossed the 53th significant bit mark for unique IDs that were used for various entities internally (including tweet IDs) and had to change their representation in JSON from number to string otherwise some clients had trouble parsing ?em? It?s just the way JS is.

Attila.

> On 12 Oct 2016, at 19:08, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
> 
> I am sorry about the inconvenience this is causing. ECMA defines JavaScript numbers as 64 bit doubles, and Java longs do not fit into this without either losing precision for large values or breaking the spec elsewhere. We did a lot of soul-searching on this and don?t think there?s any other solution.
> 
> However, it is not too hard to work around this. A Long object can be converted to a number calling the global Number() function without new keyword, or, if that is too verbose, by just using the unary + operator:
> 
>    Number(javaLong) // converts javaLong to a number
>    +javaLong   // same
> 
> This will work seamlessly with older versions of Nashorn where javaLong is already considered a number, so no special casing is required. Again, I?m sorry for the inconvenience, but this is how things are and we are not planning to go back.
> 
> Hannes
> 
> 
>> Am 12.10.2016 um 17:58 schrieb Emilian Bold <emilian.bold at gmail.com>:
>> 
>> Jo?o, I actually remember your thread but I assumed it's about Long
>> instances. Somehow it didn't click that it's about long primitives too.
>> 
>> java.io.File.length() is something I easily see anybody using in some basic
>> Nashorn script without expecting the value to be corrupted.
>> 
>> 
>> --emi
>> 
>> On Wed, Oct 12, 2016 at 6:42 PM, Jo?o Paulo Varandas <
>> joaovarandas at inpaas.com> wrote:
>> 
>>> Joerg/Emilian.
>>> 
>>> This is a questioning we've raised some time ago.
>>> I still cannot upgrade from revision 91 because of the side effects of
>>> this change ...
>>> 
>>> It seems that we need some wrapping/unwrapping when working with 'Long's
>>> in Nashorn, I don't like this either, but it seems that there's a gap
>>> between Long, Double and JSNumber max values which was bringing a loss of
>>> precision with long values in Nashorn. Thus, Long is now "object" ...
>>> 
>>> Check out:
>>> http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-August/006450.html
>>> 
>>> 
>>> 
>>> 
>>> *Jo?o Paulo Varandas*+55 11 99889-2321
>>> joaovarandas at inpaas.com
>>> 
>>> 
>>> 2016-10-12 12:11 GMT-03:00 Emilian Bold <emilian.bold at gmail.com>:
>>> 
>>>> I just read a few of the bugs linked and it does seem worrisome. So,
>>>> Nashorn cannot reliably be used as a glue between Java code that uses
>>>> longs?
>>>> 
>>>> 
>>>> --emi
>>>> 
>>>> On Wed, Oct 12, 2016 at 5:10 PM, Frantzius, J?rg <
>>>> Joerg.Frantzius at aperto.com
>>>>> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> as of JDK 1.8.0_101, the following JUnit test fails:
>>>>> 
>>>>>   @Test
>>>>>   public void testLongIsNumber() {
>>>>>       jdk.nashorn.api.scripting.ScriptObjectMirror isNumberFunction =
>>>>> eval("function isNumber(arg) {\n" +
>>>>>           "    return typeof arg === 'number';\n" +
>>>>>           "}\n" +
>>>>>           "");
>>>>>       Object result = isNumberFunction.call(isNumberFunction, 1L);
>>>>>       assertTrue((boolean) result);
>>>>>   }
>>>>> 
>>>>> This breaks e.g. Nodyn, where Long numbers resulting from
>>>>> java.io.File.length() are passed into https://nodejs.org/api/util.
>>>>> html#util_util_isnumber_object , resulting in some ?if" clause now
>>>> taking
>>>>> the wrong turn. I guess this is a side-effect of
>>>>> https://bugs.openjdk.java.net/browse/JDK-8144020 .
>>>>> 
>>>>> While I?m probably able to patch this in Nodyn, I find it a bit
>>>>> frightening that any other code out there that relies on Longs being
>>>> typeof
>>>>> ?number? will break now, in particular because there is a lot of JDK API
>>>>> that returns Long...
>>>>> 
>>>>> Regards,
>>>>> J?rg
>>>>> 
>>>>> 
>>>>> ---
>>>>> 
>>>>> Dipl. Inf. J?rg von Frantzius, Technical Director
>>>>> 
>>>>> E-Mail joerg.frantzius at aperto.com
>>>>> 
>>>>> Phone +49 30 283921-318
>>>>> Fax +49 30 283921-29
>>>>> 
>>>>> Aperto AG ? An IBM Company
>>>>> Chausseestra?e 5, D-10115 Berlin
>>>>> http://www.aperto.com<http://www.aperto.de/>
>>>>> http://www.facebook.com/aperto
>>>>> https://www.xing.com/companies/apertoag
>>>>> 
>>>>> HRB 77049 B, AG Berlin Charlottenburg
>>>>> Vorstand: Dirk Buddensiek (Vorsitzender), Kai Gro?mann, Stephan Haagen,
>>>>> Daniel Simon
>>>>> Aufsichtsrat: Matthew Candy (Vorsitzender)
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>>> "Esta mensagem, incluindo seus anexos, pode conter informacoes
>>> confidenciais e privilegiadas.
>>> Se voce a recebeu por engano, solicitamos que a apague e avise o remetente
>>> imediatamente.
>>> Opinioes ou informacoes aqui contidas nao refletem necessariamente a
>>> posicao oficial da Plusoft."
>>> 
>>> "Antes de imprimir, pense em sua responsabilidade e compromisso com o MEIO
>>> AMBIENTE"
>>> 
>>> 
> 


From szegedia at gmail.com  Thu Oct 13 11:13:34 2016
From: szegedia at gmail.com (Attila Szegedi)
Date: Thu, 13 Oct 2016 13:13:34 +0200
Subject: RFR 8167614: Avoid module dependency from jdk.dynalink to
	jdk.internal.module of java.base module
In-Reply-To: <98c9502d-4cf0-e58b-1e95-7b7a0c81c493@oracle.com>
References: <601a2a17-7436-e380-aa86-ec7ceb0c4f4d@oracle.com>
	<ffba0592-8a9e-6a51-9b91-c078f2ac9592@oracle.com>
	<c6799d0f-e44c-9fe2-b9a8-59c76034e645@oracle.com>
	<c1d7e4a3-9202-2154-bbc3-d706db8ca5e4@oracle.com>
	<98c9502d-4cf0-e58b-1e95-7b7a0c81c493@oracle.com>
Message-ID: <B96E1CD8-4138-414E-A8BB-29B85CD8A9E8@gmail.com>

Looks good to me, +1.

It seems correct that it?s the responsibility of the users of Dynalink to add the read edges from their own modules.

Attila.

> On 12 Oct 2016, at 18:31, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Updated nashorn webrev:
> http://cr.openjdk.java.net/~sundar/8167614/nashorn/webrev.01/
> 
> Changed to use Layer.boot().findModule.
> 
> Thanks
> 
> -Sundar
> 
> 
> On 10/12/2016 9:42 PM, Alan Bateman wrote:
>> On 12/10/2016 16:33, Sundararajan Athijegannathan wrote:
>> 
>>> :
>>> 
>>> Dynalink used to automatically add those necessary add edges. With the
>>> current change, nashorn adds necessary read edges. CallerSensitive
>>> methods are found only in java.base, java.logging, java.sql and
>>> java.sql.rowset modules - the first two are always present [in nashorn's
>>> compact1 dependency world]. The later two are checked for presence and
>>> read-edges are added conditionally (see ScriptLoader.java changes).
>> JDK-8154346 tracks fixing java.sql.DriverManager, there are
>> compatibility concerns to changing it but it is being looked at.
>> 
>> I'm not familiar with the issue in the java.sql.rowset module but it
>> may be that the security checks in SerialJavaObject::getFields can be
>> re-visited (I don't know all the history on that).
>> 
>> 
>>> 
>>> Yes, I need boot layer modules only and I'll change that.
>>> 
>> Thanks.
>> 
>> -Alan.
> 


From emilian.bold at gmail.com  Thu Oct 13 11:31:46 2016
From: emilian.bold at gmail.com (Emilian Bold)
Date: Thu, 13 Oct 2016 14:31:46 +0300
Subject: typeof Long is not 'number' anymore
In-Reply-To: <F0B0F816-F159-4F9C-B0DA-34B250BFADAA@gmail.com>
References: <85A6A4E1-A03D-4770-91FD-00BEF601CB65@aperto.com>
	<CAL6R17D_4ovFR=aRAXfnFuYA2-ZmWLiLXMO_qu1H9-uN6z=i2Q@mail.gmail.com>
	<CACoP5y2+GTcts-GYdv=WtDr0iLYXdj+cTV01GexacGzSN0Bg9Q@mail.gmail.com>
	<CAL6R17A8oj7=HpHqyOuT9Vx7RnLDULEHn2jfucSDKeeWe95qpQ@mail.gmail.com>
	<692A61DC-21D3-4F86-96EC-09CB8E03DD96@oracle.com>
	<F0B0F816-F159-4F9C-B0DA-34B250BFADAA@gmail.com>
Message-ID: <CAL6R17BXaXXZ-r-tAaCx4abqrmEB17ozhQ6QxjXCfaLZwVURXA@mail.gmail.com>

Yes, I had to freshen up on floating point precision. It's odd to use a
double for a long value but you have no corruption up to 2^53.

So, indeed, this might be a problem for Google, but not for normal scripts.


--emi

On Thu, Oct 13, 2016 at 2:05 PM, Attila Szegedi <szegedia at gmail.com> wrote:

> I think Emilian?s example of File.length() is actually in favor of not
> converting Longs to doubles automatically. Although to be fair, 53 bits of
> double precision can still correctly represent a file length of up to cca.
> 8 petabytes if I?m not mistaken, so? probably Not a Problem For Most
> People? yet unless you run a data warehouse :-)
>
> As a funny aside, I remember being back at Twitter around the time we
> crossed the 53th significant bit mark for unique IDs that were used for
> various entities internally (including tweet IDs) and had to change their
> representation in JSON from number to string otherwise some clients had
> trouble parsing ?em? It?s just the way JS is.
>
> Attila.
>
> > On 12 Oct 2016, at 19:08, Hannes Walln?fer <hannes.wallnoefer at oracle.com>
> wrote:
> >
> > I am sorry about the inconvenience this is causing. ECMA defines
> JavaScript numbers as 64 bit doubles, and Java longs do not fit into this
> without either losing precision for large values or breaking the spec
> elsewhere. We did a lot of soul-searching on this and don?t think there?s
> any other solution.
> >
> > However, it is not too hard to work around this. A Long object can be
> converted to a number calling the global Number() function without new
> keyword, or, if that is too verbose, by just using the unary + operator:
> >
> >    Number(javaLong) // converts javaLong to a number
> >    +javaLong   // same
> >
> > This will work seamlessly with older versions of Nashorn where javaLong
> is already considered a number, so no special casing is required. Again,
> I?m sorry for the inconvenience, but this is how things are and we are not
> planning to go back.
> >
> > Hannes
> >
> >
> >> Am 12.10.2016 um 17:58 schrieb Emilian Bold <emilian.bold at gmail.com>:
> >>
> >> Jo?o, I actually remember your thread but I assumed it's about Long
> >> instances. Somehow it didn't click that it's about long primitives too.
> >>
> >> java.io.File.length() is something I easily see anybody using in some
> basic
> >> Nashorn script without expecting the value to be corrupted.
> >>
> >>
> >> --emi
> >>
> >> On Wed, Oct 12, 2016 at 6:42 PM, Jo?o Paulo Varandas <
> >> joaovarandas at inpaas.com> wrote:
> >>
> >>> Joerg/Emilian.
> >>>
> >>> This is a questioning we've raised some time ago.
> >>> I still cannot upgrade from revision 91 because of the side effects of
> >>> this change ...
> >>>
> >>> It seems that we need some wrapping/unwrapping when working with
> 'Long's
> >>> in Nashorn, I don't like this either, but it seems that there's a gap
> >>> between Long, Double and JSNumber max values which was bringing a loss
> of
> >>> precision with long values in Nashorn. Thus, Long is now "object" ...
> >>>
> >>> Check out:
> >>> http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-
> August/006450.html
> >>>
> >>>
> >>>
> >>>
> >>> *Jo?o Paulo Varandas*+55 11 99889-2321
> >>> joaovarandas at inpaas.com
> >>>
> >>>
> >>> 2016-10-12 12:11 GMT-03:00 Emilian Bold <emilian.bold at gmail.com>:
> >>>
> >>>> I just read a few of the bugs linked and it does seem worrisome. So,
> >>>> Nashorn cannot reliably be used as a glue between Java code that uses
> >>>> longs?
> >>>>
> >>>>
> >>>> --emi
> >>>>
> >>>> On Wed, Oct 12, 2016 at 5:10 PM, Frantzius, J?rg <
> >>>> Joerg.Frantzius at aperto.com
> >>>>> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> as of JDK 1.8.0_101, the following JUnit test fails:
> >>>>>
> >>>>>   @Test
> >>>>>   public void testLongIsNumber() {
> >>>>>       jdk.nashorn.api.scripting.ScriptObjectMirror isNumberFunction
> =
> >>>>> eval("function isNumber(arg) {\n" +
> >>>>>           "    return typeof arg === 'number';\n" +
> >>>>>           "}\n" +
> >>>>>           "");
> >>>>>       Object result = isNumberFunction.call(isNumberFunction, 1L);
> >>>>>       assertTrue((boolean) result);
> >>>>>   }
> >>>>>
> >>>>> This breaks e.g. Nodyn, where Long numbers resulting from
> >>>>> java.io.File.length() are passed into https://nodejs.org/api/util.
> >>>>> html#util_util_isnumber_object , resulting in some ?if" clause now
> >>>> taking
> >>>>> the wrong turn. I guess this is a side-effect of
> >>>>> https://bugs.openjdk.java.net/browse/JDK-8144020 .
> >>>>>
> >>>>> While I?m probably able to patch this in Nodyn, I find it a bit
> >>>>> frightening that any other code out there that relies on Longs being
> >>>> typeof
> >>>>> ?number? will break now, in particular because there is a lot of JDK
> API
> >>>>> that returns Long...
> >>>>>
> >>>>> Regards,
> >>>>> J?rg
> >>>>>
> >>>>>
> >>>>> ---
> >>>>>
> >>>>> Dipl. Inf. J?rg von Frantzius, Technical Director
> >>>>>
> >>>>> E-Mail joerg.frantzius at aperto.com
> >>>>>
> >>>>> Phone +49 30 283921-318
> >>>>> Fax +49 30 283921-29
> >>>>>
> >>>>> Aperto AG ? An IBM Company
> >>>>> Chausseestra?e 5, D-10115 Berlin
> >>>>> http://www.aperto.com<http://www.aperto.de/>
> >>>>> http://www.facebook.com/aperto
> >>>>> https://www.xing.com/companies/apertoag
> >>>>>
> >>>>> HRB 77049 B, AG Berlin Charlottenburg
> >>>>> Vorstand: Dirk Buddensiek (Vorsitzender), Kai Gro?mann, Stephan
> Haagen,
> >>>>> Daniel Simon
> >>>>> Aufsichtsrat: Matthew Candy (Vorsitzender)
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>> "Esta mensagem, incluindo seus anexos, pode conter informacoes
> >>> confidenciais e privilegiadas.
> >>> Se voce a recebeu por engano, solicitamos que a apague e avise o
> remetente
> >>> imediatamente.
> >>> Opinioes ou informacoes aqui contidas nao refletem necessariamente a
> >>> posicao oficial da Plusoft."
> >>>
> >>> "Antes de imprimir, pense em sua responsabilidade e compromisso com o
> MEIO
> >>> AMBIENTE"
> >>>
> >>>
> >
>
>

From esben at esbena.dk  Sun Oct 16 20:42:46 2016
From: esben at esbena.dk (Esben Andreasen)
Date: Sun, 16 Oct 2016 20:42:46 +0000
Subject: No subject
Message-ID: <CAE_ENxUDv3PToXW9iV-C-rA-pX7XHXUDhEk1FEbyBkEzdmP79A@mail.gmail.com>

Hi

I am not sure if this is a bug or feature of the Nashorn engine. But
it looks like some String-prototype methods are missing, yet the
methods are somehow present when used in the right way.

Minimal example: calling `startsWith` by using `call`:

```
1  $ jjs -v
2  jjs> String.prototype.startsWith.call('abc', 'ab')
3  <shell>:1 TypeError: Cannot read property "call" from undefined
```

Expected behavior:

Not a type error, for multiple reasons:

1. Other JavaScript engines do not throw a type error.
2. The equivalent code `"abc".startsWith("ab")` does not throw a type error.


Further investigation:

```
 1  $ jjs -v
 2  nashorn 1.8.0_101
 3  jjs> "abc".startsWith('ab')
 4  true
 5  jjs> "abc".startsWith
 6  [jdk.internal.dynalink.beans.OverloadedDynamicMethod
     boolean java.lang.String.startsWith(String,int)
     boolean java.lang.String.startsWith(String)
    ]
 7  jjs> "abc".startsWith.call("abc", "ab")
 8  <shell>:1 TypeError: "abc".startsWith.call is not a function
 9  jjs> typeof String.prototype.startsWith
10  undefined
11  jjs> String.prototype.split.call("abc", "b")
12  a,c
```

Interpretation:

It looks like `startsWith` is not present on the String-prototype, yet
it is present on the String-primitives. Other String-prototype methods
(`split`) are however present.

Further notes:

This also applies to `String.prototype.endsWith`.


Related bug/feature: primitive values are not wrapped properly:

```
1  $ jjs -v
2  jjs> typeof Object("abc").startsWith
3  undefined
```

-

Esben

From esben at esbena.dk  Sun Oct 16 20:50:58 2016
From: esben at esbena.dk (Esben Andreasen)
Date: Sun, 16 Oct 2016 20:50:58 +0000
Subject: Surprising Nashorn behavior for String methods
Message-ID: <CAE_ENxWOGpSDxQi9D4MzoEMO9zBp5KdFeFrGFLga8XsrDqQ0PQ@mail.gmail.com>

Hi

I am not sure if this is a bug or feature of the Nashorn engine. But
it looks like some String-prototype methods are missing, yet the
methods are somehow present when used in the right way.

Minimal example: calling `startsWith` by using `call`:

```
1  $ jjs -v
2  jjs> String.prototype.startsWith.call('abc', 'ab')
3  <shell>:1 TypeError: Cannot read property "call" from undefined
```

Expected behavior:

Not a type error, for multiple reasons:

1. Other JavaScript engines do not throw a type error.
2. The equivalent code `"abc".startsWith("ab")` does not throw a type error.


Further investigation:

```
 1  $ jjs -v
 2  nashorn 1.8.0_101
 3  jjs> "abc".startsWith('ab')
 4  true
 5  jjs> "abc".startsWith
 6  [jdk.internal.dynalink.beans.OverloadedDynamicMethod
     boolean java.lang.String.startsWith(String,int)
     boolean java.lang.String.startsWith(String)
    ]
 7  jjs> "abc".startsWith.call("abc", "ab")
 8  <shell>:1 TypeError: "abc".startsWith.call is not a function
 9  jjs> typeof String.prototype.startsWith
10  undefined
11  jjs> String.prototype.split.call("abc", "b")
12  a,c
```

Interpretation:

It looks like `startsWith` is not present on the String-prototype, yet
it is present on the String-primitives. Other String-prototype methods
(`split`) are however present.

Further notes:

This also applies to `String.prototype.endsWith`.


Related bug/feature: primitive values are not wrapped properly:

```
1  $ jjs -v
2  jjs> typeof Object("abc").startsWith
3  undefined
```

From sundararajan.athijegannathan at oracle.com  Mon Oct 17 04:48:15 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 17 Oct 2016 10:18:15 +0530
Subject: Surprising Nashorn behavior for String methods
In-Reply-To: <CAE_ENxWOGpSDxQi9D4MzoEMO9zBp5KdFeFrGFLga8XsrDqQ0PQ@mail.gmail.com>
References: <CAE_ENxWOGpSDxQi9D4MzoEMO9zBp5KdFeFrGFLga8XsrDqQ0PQ@mail.gmail.com>
Message-ID: <474911e3-504a-27dd-0a30-0e25d5a0b466@oracle.com>

Hi,

"startsWith" is non-standard extension (actually, it is Java method)

jjs> "hello".startsWith
[jdk.internal.dynalink.beans.OverloadedDynamicMethod
java.lang.String.startsWith]

"startsWith" is not an ECMAScript standard specified property of
String.prototype.  In Nashorn, you can call methods of java.lang.String
on JS strings.  "split" is an ECMAScript standard specified property of
String.prototype and hence you find it as "function" valued property of
String.prototype.

HTH,

-Sundar


On 10/17/2016 2:20 AM, Esben Andreasen wrote:
> Hi
>
> I am not sure if this is a bug or feature of the Nashorn engine. But
> it looks like some String-prototype methods are missing, yet the
> methods are somehow present when used in the right way.
>
> Minimal example: calling `startsWith` by using `call`:
>
> ```
> 1  $ jjs -v
> 2  jjs> String.prototype.startsWith.call('abc', 'ab')
> 3  <shell>:1 TypeError: Cannot read property "call" from undefined
> ```
>
> Expected behavior:
>
> Not a type error, for multiple reasons:
>
> 1. Other JavaScript engines do not throw a type error.
> 2. The equivalent code `"abc".startsWith("ab")` does not throw a type error.
>
>
> Further investigation:
>
> ```
>  1  $ jjs -v
>  2  nashorn 1.8.0_101
>  3  jjs> "abc".startsWith('ab')
>  4  true
>  5  jjs> "abc".startsWith
>  6  [jdk.internal.dynalink.beans.OverloadedDynamicMethod
>      boolean java.lang.String.startsWith(String,int)
>      boolean java.lang.String.startsWith(String)
>     ]
>  7  jjs> "abc".startsWith.call("abc", "ab")
>  8  <shell>:1 TypeError: "abc".startsWith.call is not a function
>  9  jjs> typeof String.prototype.startsWith
> 10  undefined
> 11  jjs> String.prototype.split.call("abc", "b")
> 12  a,c
> ```
>
> Interpretation:
>
> It looks like `startsWith` is not present on the String-prototype, yet
> it is present on the String-primitives. Other String-prototype methods
> (`split`) are however present.
>
> Further notes:
>
> This also applies to `String.prototype.endsWith`.
>
>
> Related bug/feature: primitive values are not wrapped properly:
>
> ```
> 1  $ jjs -v
> 2  jjs> typeof Object("abc").startsWith
> 3  undefined
> ```


From rieberandreas at gmail.com  Mon Oct 17 05:22:42 2016
From: rieberandreas at gmail.com (Andreas Rieber)
Date: Mon, 17 Oct 2016 07:22:42 +0200
Subject: Surprising Nashorn behavior for String methods
In-Reply-To: <474911e3-504a-27dd-0a30-0e25d5a0b466@oracle.com>
References: <CAE_ENxWOGpSDxQi9D4MzoEMO9zBp5KdFeFrGFLga8XsrDqQ0PQ@mail.gmail.com>
	<474911e3-504a-27dd-0a30-0e25d5a0b466@oracle.com>
Message-ID: <e05c1858-6d79-0962-c88a-d010539c06e7@gmail.com>

Hi Sundar,

startsWith is part of ECMAScript:

http://www.ecma-international.org/ecma-262/6.0/#sec-string.prototype.startswith

Not widely supported...

cheers
Andreas


On 17/10/2016 06:48, Sundararajan Athijegannathan wrote:
> Hi,
>
> "startsWith" is non-standard extension (actually, it is Java method)
>
> jjs> "hello".startsWith
> [jdk.internal.dynalink.beans.OverloadedDynamicMethod
> java.lang.String.startsWith]
>
> "startsWith" is not an ECMAScript standard specified property of
> String.prototype.  In Nashorn, you can call methods of java.lang.String
> on JS strings.  "split" is an ECMAScript standard specified property of
> String.prototype and hence you find it as "function" valued property of
> String.prototype.
>
> HTH,
>
> -Sundar
>
>
> On 10/17/2016 2:20 AM, Esben Andreasen wrote:
>> Hi
>>
>> I am not sure if this is a bug or feature of the Nashorn engine. But
>> it looks like some String-prototype methods are missing, yet the
>> methods are somehow present when used in the right way.
>>
>> Minimal example: calling `startsWith` by using `call`:
>>
>> ```
>> 1  $ jjs -v
>> 2  jjs> String.prototype.startsWith.call('abc', 'ab')
>> 3  <shell>:1 TypeError: Cannot read property "call" from undefined
>> ```
>>
>> Expected behavior:
>>
>> Not a type error, for multiple reasons:
>>
>> 1. Other JavaScript engines do not throw a type error.
>> 2. The equivalent code `"abc".startsWith("ab")` does not throw a type error.
>>
>>
>> Further investigation:
>>
>> ```
>>  1  $ jjs -v
>>  2  nashorn 1.8.0_101
>>  3  jjs> "abc".startsWith('ab')
>>  4  true
>>  5  jjs> "abc".startsWith
>>  6  [jdk.internal.dynalink.beans.OverloadedDynamicMethod
>>      boolean java.lang.String.startsWith(String,int)
>>      boolean java.lang.String.startsWith(String)
>>     ]
>>  7  jjs> "abc".startsWith.call("abc", "ab")
>>  8  <shell>:1 TypeError: "abc".startsWith.call is not a function
>>  9  jjs> typeof String.prototype.startsWith
>> 10  undefined
>> 11  jjs> String.prototype.split.call("abc", "b")
>> 12  a,c
>> ```
>>
>> Interpretation:
>>
>> It looks like `startsWith` is not present on the String-prototype, yet
>> it is present on the String-primitives. Other String-prototype methods
>> (`split`) are however present.
>>
>> Further notes:
>>
>> This also applies to `String.prototype.endsWith`.
>>
>>
>> Related bug/feature: primitive values are not wrapped properly:
>>
>> ```
>> 1  $ jjs -v
>> 2  jjs> typeof Object("abc").startsWith
>> 3  undefined
>> ```
>


From szegedia at gmail.com  Mon Oct 17 05:44:50 2016
From: szegedia at gmail.com (Attila Szegedi)
Date: Sun, 16 Oct 2016 22:44:50 -0700
Subject: 
In-Reply-To: <CAE_ENxUDv3PToXW9iV-C-rA-pX7XHXUDhEk1FEbyBkEzdmP79A@mail.gmail.com>
References: <CAE_ENxUDv3PToXW9iV-C-rA-pX7XHXUDhEk1FEbyBkEzdmP79A@mail.gmail.com>
Message-ID: <5FA6DB8D-FAC7-4C59-B283-5B3256EA6FC0@gmail.com>

it?s a side effect of the fact that primitive strings values in Nashorn are instances of java.lang.String, and the fact that with Nashorn you can invoke methods on Java objects, therefore ?startsWith? is a Java String method.

While Java methods also don?t inherit from Function.prototype (hence, you can?t call ?call? on them as you have correctly observed), implementations of Function.prototype.call and .apply are actually coded so that they do work on them with a not terribly obvious, but correct invocation:

var sw = "".startsWith
Function.prototype.call.call(sw, "abc", "a")

should return true. Note that since the expression fn.call.call is totally unbound from the fn that produced it, you can use any ?fn?; I usually use ?Function? for some semblance of clarity:

Function.call.call(sw, "abc", "a")

Finally, .startsWith is only present on primitive String values (as they?re java.lang.String), not on JS String objects, that?s why you were getting results you didn?t expect from ?typeof Object(string).startsWith?

HTH,
  Attila.


> On 16 Oct 2016, at 13:42, Esben Andreasen <esben at esbena.dk> wrote:
> 
> Hi
> 
> I am not sure if this is a bug or feature of the Nashorn engine. But
> it looks like some String-prototype methods are missing, yet the
> methods are somehow present when used in the right way.
> 
> Minimal example: calling `startsWith` by using `call`:
> 
> ```
> 1  $ jjs -v
> 2  jjs> String.prototype.startsWith.call('abc', 'ab')
> 3  <shell>:1 TypeError: Cannot read property "call" from undefined
> ```
> 
> Expected behavior:
> 
> Not a type error, for multiple reasons:
> 
> 1. Other JavaScript engines do not throw a type error.
> 2. The equivalent code `"abc".startsWith("ab")` does not throw a type error.
> 
> 
> Further investigation:
> 
> ```
> 1  $ jjs -v
> 2  nashorn 1.8.0_101
> 3  jjs> "abc".startsWith('ab')
> 4  true
> 5  jjs> "abc".startsWith
> 6  [jdk.internal.dynalink.beans.OverloadedDynamicMethod
>     boolean java.lang.String.startsWith(String,int)
>     boolean java.lang.String.startsWith(String)
>    ]
> 7  jjs> "abc".startsWith.call("abc", "ab")
> 8  <shell>:1 TypeError: "abc".startsWith.call is not a function
> 9  jjs> typeof String.prototype.startsWith
> 10  undefined
> 11  jjs> String.prototype.split.call("abc", "b")
> 12  a,c
> ```
> 
> Interpretation:
> 
> It looks like `startsWith` is not present on the String-prototype, yet
> it is present on the String-primitives. Other String-prototype methods
> (`split`) are however present.
> 
> Further notes:
> 
> This also applies to `String.prototype.endsWith`.
> 
> 
> Related bug/feature: primitive values are not wrapped properly:
> 
> ```
> 1  $ jjs -v
> 2  jjs> typeof Object("abc").startsWith
> 3  undefined
> ```
> 
> -
> 
> Esben


From emilian.bold at gmail.com  Mon Oct 17 05:48:26 2016
From: emilian.bold at gmail.com (Emilian Bold)
Date: Mon, 17 Oct 2016 08:48:26 +0300
Subject: Surprising Nashorn behavior for String methods
In-Reply-To: <e05c1858-6d79-0962-c88a-d010539c06e7@gmail.com>
References: <CAE_ENxWOGpSDxQi9D4MzoEMO9zBp5KdFeFrGFLga8XsrDqQ0PQ@mail.gmail.com>
	<474911e3-504a-27dd-0a30-0e25d5a0b466@oracle.com>
	<e05c1858-6d79-0962-c88a-d010539c06e7@gmail.com>
Message-ID: <CAL6R17Cm3Y+bBaV29zz6jTvsgFE=xW5n03ouKHCzd_jO0aGhwA@mail.gmail.com>

@Andreas: But Nashorn on JDK 8 does not implement ECMAScript 6.


--emi

On Mon, Oct 17, 2016 at 8:22 AM, Andreas Rieber <rieberandreas at gmail.com>
wrote:

> Hi Sundar,
>
> startsWith is part of ECMAScript:
>
> http://www.ecma-international.org/ecma-262/6.0/#sec-string.p
> rototype.startswith
>
> Not widely supported...
>
> cheers
> Andreas
>
>
>
> On 17/10/2016 06:48, Sundararajan Athijegannathan wrote:
>
>> Hi,
>>
>> "startsWith" is non-standard extension (actually, it is Java method)
>>
>> jjs> "hello".startsWith
>> [jdk.internal.dynalink.beans.OverloadedDynamicMethod
>> java.lang.String.startsWith]
>>
>> "startsWith" is not an ECMAScript standard specified property of
>> String.prototype.  In Nashorn, you can call methods of java.lang.String
>> on JS strings.  "split" is an ECMAScript standard specified property of
>> String.prototype and hence you find it as "function" valued property of
>> String.prototype.
>>
>> HTH,
>>
>> -Sundar
>>
>>
>> On 10/17/2016 2:20 AM, Esben Andreasen wrote:
>>
>>> Hi
>>>
>>> I am not sure if this is a bug or feature of the Nashorn engine. But
>>> it looks like some String-prototype methods are missing, yet the
>>> methods are somehow present when used in the right way.
>>>
>>> Minimal example: calling `startsWith` by using `call`:
>>>
>>> ```
>>> 1  $ jjs -v
>>> 2  jjs> String.prototype.startsWith.call('abc', 'ab')
>>> 3  <shell>:1 TypeError: Cannot read property "call" from undefined
>>> ```
>>>
>>> Expected behavior:
>>>
>>> Not a type error, for multiple reasons:
>>>
>>> 1. Other JavaScript engines do not throw a type error.
>>> 2. The equivalent code `"abc".startsWith("ab")` does not throw a type
>>> error.
>>>
>>>
>>> Further investigation:
>>>
>>> ```
>>>  1  $ jjs -v
>>>  2  nashorn 1.8.0_101
>>>  3  jjs> "abc".startsWith('ab')
>>>  4  true
>>>  5  jjs> "abc".startsWith
>>>  6  [jdk.internal.dynalink.beans.OverloadedDynamicMethod
>>>      boolean java.lang.String.startsWith(String,int)
>>>      boolean java.lang.String.startsWith(String)
>>>     ]
>>>  7  jjs> "abc".startsWith.call("abc", "ab")
>>>  8  <shell>:1 TypeError: "abc".startsWith.call is not a function
>>>  9  jjs> typeof String.prototype.startsWith
>>> 10  undefined
>>> 11  jjs> String.prototype.split.call("abc", "b")
>>> 12  a,c
>>> ```
>>>
>>> Interpretation:
>>>
>>> It looks like `startsWith` is not present on the String-prototype, yet
>>> it is present on the String-primitives. Other String-prototype methods
>>> (`split`) are however present.
>>>
>>> Further notes:
>>>
>>> This also applies to `String.prototype.endsWith`.
>>>
>>>
>>> Related bug/feature: primitive values are not wrapped properly:
>>>
>>> ```
>>> 1  $ jjs -v
>>> 2  jjs> typeof Object("abc").startsWith
>>> 3  undefined
>>> ```
>>>
>>
>>
>

From esben at esbena.dk  Mon Oct 17 07:11:39 2016
From: esben at esbena.dk (Esben Andreasen)
Date: Mon, 17 Oct 2016 07:11:39 +0000
Subject: 
In-Reply-To: <5FA6DB8D-FAC7-4C59-B283-5B3256EA6FC0@gmail.com>
References: <CAE_ENxUDv3PToXW9iV-C-rA-pX7XHXUDhEk1FEbyBkEzdmP79A@mail.gmail.com>
	<5FA6DB8D-FAC7-4C59-B283-5B3256EA6FC0@gmail.com>
Message-ID: <CAE_ENxWiu9HG7Mgn61+J5rH_kvSOEo0TEqoNdKahBr_XcPBcHA@mail.gmail.com>

Thanks. That makes sense.

Two follow-ups, if I may:

A.
Where can I read about such non-ECMA-standard features in Nashorn?


B.
ECMAScript 6 includes `String.prototype.startsWith`, but it is not
supported by Nashorn in ES6-mode:

```
1  $ jjs -version --language=es6
2  nashorn 1.8.0_101
3  jjs> typeof String.prototype.startsWith
4  undefined
```

And it is unclear whether Nashorn intends to support it yet
(https://bugs.openjdk.java.net/browse/JDK-8066046).
So, is it a deliberate omission?

---
Esben

On Mon, Oct 17, 2016 at 7:44 AM Attila Szegedi <szegedia at gmail.com> wrote:

> it?s a side effect of the fact that primitive strings values in Nashorn
> are instances of java.lang.String, and the fact that with Nashorn you can
> invoke methods on Java objects, therefore ?startsWith? is a Java String
> method.
>
> While Java methods also don?t inherit from Function.prototype (hence, you
> can?t call ?call? on them as you have correctly observed), implementations
> of Function.prototype.call and .apply are actually coded so that they do
> work on them with a not terribly obvious, but correct invocation:
>
> var sw = "".startsWith
> Function.prototype.call.call(sw, "abc", "a")
>
> should return true. Note that since the expression fn.call.call is totally
> unbound from the fn that produced it, you can use any ?fn?; I usually use
> ?Function? for some semblance of clarity:
>
> Function.call.call(sw, "abc", "a")
>
> Finally, .startsWith is only present on primitive String values (as
> they?re java.lang.String), not on JS String objects, that?s why you were
> getting results you didn?t expect from ?typeof Object(string).startsWith?
>
> HTH,
>   Attila.
>
>
> > On 16 Oct 2016, at 13:42, Esben Andreasen <esben at esbena.dk> wrote:
> >
> > Hi
> >
> > I am not sure if this is a bug or feature of the Nashorn engine. But
> > it looks like some String-prototype methods are missing, yet the
> > methods are somehow present when used in the right way.
> >
> > Minimal example: calling `startsWith` by using `call`:
> >
> > ```
> > 1  $ jjs -v
> > 2  jjs> String.prototype.startsWith.call('abc', 'ab')
> > 3  <shell>:1 TypeError: Cannot read property "call" from undefined
> > ```
> >
> > Expected behavior:
> >
> > Not a type error, for multiple reasons:
> >
> > 1. Other JavaScript engines do not throw a type error.
> > 2. The equivalent code `"abc".startsWith("ab")` does not throw a type
> error.
> >
> >
> > Further investigation:
> >
> > ```
> > 1  $ jjs -v
> > 2  nashorn 1.8.0_101
> > 3  jjs> "abc".startsWith('ab')
> > 4  true
> > 5  jjs> "abc".startsWith
> > 6  [jdk.internal.dynalink.beans.OverloadedDynamicMethod
> >     boolean java.lang.String.startsWith(String,int)
> >     boolean java.lang.String.startsWith(String)
> >    ]
> > 7  jjs> "abc".startsWith.call("abc", "ab")
> > 8  <shell>:1 TypeError: "abc".startsWith.call is not a function
> > 9  jjs> typeof String.prototype.startsWith
> > 10  undefined
> > 11  jjs> String.prototype.split.call("abc", "b")
> > 12  a,c
> > ```
> >
> > Interpretation:
> >
> > It looks like `startsWith` is not present on the String-prototype, yet
> > it is present on the String-primitives. Other String-prototype methods
> > (`split`) are however present.
> >
> > Further notes:
> >
> > This also applies to `String.prototype.endsWith`.
> >
> >
> > Related bug/feature: primitive values are not wrapped properly:
> >
> > ```
> > 1  $ jjs -v
> > 2  jjs> typeof Object("abc").startsWith
> > 3  undefined
> > ```
> >
> > -
> >
> > Esben
>
>

From sundararajan.athijegannathan at oracle.com  Mon Oct 17 10:12:43 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 17 Oct 2016 15:42:43 +0530
Subject: Surprising Nashorn behavior for String methods
In-Reply-To: <e05c1858-6d79-0962-c88a-d010539c06e7@gmail.com>
References: <CAE_ENxWOGpSDxQi9D4MzoEMO9zBp5KdFeFrGFLga8XsrDqQ0PQ@mail.gmail.com>
	<474911e3-504a-27dd-0a30-0e25d5a0b466@oracle.com>
	<e05c1858-6d79-0962-c88a-d010539c06e7@gmail.com>
Message-ID: <8346d0e6-c9fb-21e0-6243-f89f323634aa@oracle.com>

Hi Andreas,

Well, it is as of ES 6.0. For the most part, Nashorn still is only 5.1
compliant with few ES6 items thrown in jdk 9.

Also,  my answer was generic in the sense that there are function
properties available which are not in prototype [because of java extension].

-Sundar

On 10/17/2016 10:52 AM, Andreas Rieber wrote:
> Hi Sundar,
>
> startsWith is part of ECMAScript:
>
> http://www.ecma-international.org/ecma-262/6.0/#sec-string.prototype.startswith
>
>
> Not widely supported...
>
> cheers
> Andreas
>
>
> On 17/10/2016 06:48, Sundararajan Athijegannathan wrote:
>> Hi,
>>
>> "startsWith" is non-standard extension (actually, it is Java method)
>>
>> jjs> "hello".startsWith
>> [jdk.internal.dynalink.beans.OverloadedDynamicMethod
>> java.lang.String.startsWith]
>>
>> "startsWith" is not an ECMAScript standard specified property of
>> String.prototype.  In Nashorn, you can call methods of java.lang.String
>> on JS strings.  "split" is an ECMAScript standard specified property of
>> String.prototype and hence you find it as "function" valued property of
>> String.prototype.
>>
>> HTH,
>>
>> -Sundar
>>
>>
>> On 10/17/2016 2:20 AM, Esben Andreasen wrote:
>>> Hi
>>>
>>> I am not sure if this is a bug or feature of the Nashorn engine. But
>>> it looks like some String-prototype methods are missing, yet the
>>> methods are somehow present when used in the right way.
>>>
>>> Minimal example: calling `startsWith` by using `call`:
>>>
>>> ```
>>> 1  $ jjs -v
>>> 2  jjs> String.prototype.startsWith.call('abc', 'ab')
>>> 3  <shell>:1 TypeError: Cannot read property "call" from undefined
>>> ```
>>>
>>> Expected behavior:
>>>
>>> Not a type error, for multiple reasons:
>>>
>>> 1. Other JavaScript engines do not throw a type error.
>>> 2. The equivalent code `"abc".startsWith("ab")` does not throw a
>>> type error.
>>>
>>>
>>> Further investigation:
>>>
>>> ```
>>>  1  $ jjs -v
>>>  2  nashorn 1.8.0_101
>>>  3  jjs> "abc".startsWith('ab')
>>>  4  true
>>>  5  jjs> "abc".startsWith
>>>  6  [jdk.internal.dynalink.beans.OverloadedDynamicMethod
>>>      boolean java.lang.String.startsWith(String,int)
>>>      boolean java.lang.String.startsWith(String)
>>>     ]
>>>  7  jjs> "abc".startsWith.call("abc", "ab")
>>>  8  <shell>:1 TypeError: "abc".startsWith.call is not a function
>>>  9  jjs> typeof String.prototype.startsWith
>>> 10  undefined
>>> 11  jjs> String.prototype.split.call("abc", "b")
>>> 12  a,c
>>> ```
>>>
>>> Interpretation:
>>>
>>> It looks like `startsWith` is not present on the String-prototype, yet
>>> it is present on the String-primitives. Other String-prototype methods
>>> (`split`) are however present.
>>>
>>> Further notes:
>>>
>>> This also applies to `String.prototype.endsWith`.
>>>
>>>
>>> Related bug/feature: primitive values are not wrapped properly:
>>>
>>> ```
>>> 1  $ jjs -v
>>> 2  jjs> typeof Object("abc").startsWith
>>> 3  undefined
>>> ```
>>
>


From hannes.wallnoefer at oracle.com  Mon Oct 17 10:21:29 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Mon, 17 Oct 2016 12:21:29 +0200
Subject: 
In-Reply-To: <CAE_ENxWiu9HG7Mgn61+J5rH_kvSOEo0TEqoNdKahBr_XcPBcHA@mail.gmail.com>
References: <CAE_ENxUDv3PToXW9iV-C-rA-pX7XHXUDhEk1FEbyBkEzdmP79A@mail.gmail.com>
	<5FA6DB8D-FAC7-4C59-B283-5B3256EA6FC0@gmail.com>
	<CAE_ENxWiu9HG7Mgn61+J5rH_kvSOEo0TEqoNdKahBr_XcPBcHA@mail.gmail.com>
Message-ID: <98E84CEE-B1AA-4B29-A127-A5DE46D857D9@oracle.com>

Hi Esben,


> Am 17.10.2016 um 09:11 schrieb Esben Andreasen <esben at esbena.dk>:
> 
> A.
> Where can I read about such non-ECMA-standard features in Nashorn?
> 

https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions

I don?t think the string methods from java.lang.String are contained in that page because, as Attila said, it is a side effect of using java.lang.String as JS string representation and transparently exposing Java methods to scripts.

> B.
> ECMAScript 6 includes `String.prototype.startsWith`, but it is not
> supported by Nashorn in ES6-mode:
> 
> ```
> 1  $ jjs -version --language=es6
> 2  nashorn 1.8.0_101
> 3  jjs> typeof String.prototype.startsWith
> 4  undefined
> ```
> 
> And it is unclear whether Nashorn intends to support it yet
> (https://bugs.openjdk.java.net/browse/JDK-8066046).
> So, is it a deliberate omission?

We?ll only implement some ES6 features in the initial JDK 9 release, and the String methods are not among them. 

Hannes


> ---
> Esben
> 
> On Mon, Oct 17, 2016 at 7:44 AM Attila Szegedi <szegedia at gmail.com> wrote:
> 
>> it?s a side effect of the fact that primitive strings values in Nashorn
>> are instances of java.lang.String, and the fact that with Nashorn you can
>> invoke methods on Java objects, therefore ?startsWith? is a Java String
>> method.
>> 
>> While Java methods also don?t inherit from Function.prototype (hence, you
>> can?t call ?call? on them as you have correctly observed), implementations
>> of Function.prototype.call and .apply are actually coded so that they do
>> work on them with a not terribly obvious, but correct invocation:
>> 
>> var sw = "".startsWith
>> Function.prototype.call.call(sw, "abc", "a")
>> 
>> should return true. Note that since the expression fn.call.call is totally
>> unbound from the fn that produced it, you can use any ?fn?; I usually use
>> ?Function? for some semblance of clarity:
>> 
>> Function.call.call(sw, "abc", "a")
>> 
>> Finally, .startsWith is only present on primitive String values (as
>> they?re java.lang.String), not on JS String objects, that?s why you were
>> getting results you didn?t expect from ?typeof Object(string).startsWith?
>> 
>> HTH,
>>  Attila.
>> 
>> 
>>> On 16 Oct 2016, at 13:42, Esben Andreasen <esben at esbena.dk> wrote:
>>> 
>>> Hi
>>> 
>>> I am not sure if this is a bug or feature of the Nashorn engine. But
>>> it looks like some String-prototype methods are missing, yet the
>>> methods are somehow present when used in the right way.
>>> 
>>> Minimal example: calling `startsWith` by using `call`:
>>> 
>>> ```
>>> 1  $ jjs -v
>>> 2  jjs> String.prototype.startsWith.call('abc', 'ab')
>>> 3  <shell>:1 TypeError: Cannot read property "call" from undefined
>>> ```
>>> 
>>> Expected behavior:
>>> 
>>> Not a type error, for multiple reasons:
>>> 
>>> 1. Other JavaScript engines do not throw a type error.
>>> 2. The equivalent code `"abc".startsWith("ab")` does not throw a type
>> error.
>>> 
>>> 
>>> Further investigation:
>>> 
>>> ```
>>> 1  $ jjs -v
>>> 2  nashorn 1.8.0_101
>>> 3  jjs> "abc".startsWith('ab')
>>> 4  true
>>> 5  jjs> "abc".startsWith
>>> 6  [jdk.internal.dynalink.beans.OverloadedDynamicMethod
>>>    boolean java.lang.String.startsWith(String,int)
>>>    boolean java.lang.String.startsWith(String)
>>>   ]
>>> 7  jjs> "abc".startsWith.call("abc", "ab")
>>> 8  <shell>:1 TypeError: "abc".startsWith.call is not a function
>>> 9  jjs> typeof String.prototype.startsWith
>>> 10  undefined
>>> 11  jjs> String.prototype.split.call("abc", "b")
>>> 12  a,c
>>> ```
>>> 
>>> Interpretation:
>>> 
>>> It looks like `startsWith` is not present on the String-prototype, yet
>>> it is present on the String-primitives. Other String-prototype methods
>>> (`split`) are however present.
>>> 
>>> Further notes:
>>> 
>>> This also applies to `String.prototype.endsWith`.
>>> 
>>> 
>>> Related bug/feature: primitive values are not wrapped properly:
>>> 
>>> ```
>>> 1  $ jjs -v
>>> 2  jjs> typeof Object("abc").startsWith
>>> 3  undefined
>>> ```
>>> 
>>> -
>>> 
>>> Esben
>> 
>> 


From szegedia at gmail.com  Mon Oct 17 15:27:40 2016
From: szegedia at gmail.com (Attila Szegedi)
Date: Mon, 17 Oct 2016 08:27:40 -0700
Subject: 
In-Reply-To: <98E84CEE-B1AA-4B29-A127-A5DE46D857D9@oracle.com>
References: <CAE_ENxUDv3PToXW9iV-C-rA-pX7XHXUDhEk1FEbyBkEzdmP79A@mail.gmail.com>
	<5FA6DB8D-FAC7-4C59-B283-5B3256EA6FC0@gmail.com>
	<CAE_ENxWiu9HG7Mgn61+J5rH_kvSOEo0TEqoNdKahBr_XcPBcHA@mail.gmail.com>
	<98E84CEE-B1AA-4B29-A127-A5DE46D857D9@oracle.com>
Message-ID: <A9A0DF32-FA5D-41C5-B231-90F7FC3F2E4B@gmail.com>


> On 17 Oct 2016, at 03:21, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
> 
> Hi Esben,
> 
> 
>> Am 17.10.2016 um 09:11 schrieb Esben Andreasen <esben at esbena.dk <mailto:esben at esbena.dk>>:
>> 
>> A.
>> Where can I read about such non-ECMA-standard features in Nashorn?
>> 
> 
> https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions <https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions>
> 
> I don?t think the string methods from java.lang.String are contained in that page because, as Attila said, it is a side effect of using java.lang.String as JS string representation and transparently exposing Java methods to scripts.

I was thinking that maybe we shoud switch off Java methods on Nashorn primitives with --no-java. A quick test shows we don?t do that now.

Attila.


From hannes.wallnoefer at oracle.com  Mon Oct 17 16:17:35 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Mon, 17 Oct 2016 18:17:35 +0200
Subject: 
In-Reply-To: <A9A0DF32-FA5D-41C5-B231-90F7FC3F2E4B@gmail.com>
References: <CAE_ENxUDv3PToXW9iV-C-rA-pX7XHXUDhEk1FEbyBkEzdmP79A@mail.gmail.com>
	<5FA6DB8D-FAC7-4C59-B283-5B3256EA6FC0@gmail.com>
	<CAE_ENxWiu9HG7Mgn61+J5rH_kvSOEo0TEqoNdKahBr_XcPBcHA@mail.gmail.com>
	<98E84CEE-B1AA-4B29-A127-A5DE46D857D9@oracle.com>
	<A9A0DF32-FA5D-41C5-B231-90F7FC3F2E4B@gmail.com>
Message-ID: <9DB37C6F-047D-42FF-8DA6-8D6E1E092D76@oracle.com>

In fact there's https://bugs.openjdk.java.net/browse/JDK-8157723, which was filed by you and waiting for me. I actually dug it up earlier today. The fix you suggested seems to be working, so it looks like we should do this.

Hannes


> Am 17.10.2016 um 17:27 schrieb Attila Szegedi <szegedia at gmail.com>:
> 
>> 
>> On 17 Oct 2016, at 03:21, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
>> 
>> Hi Esben,
>> 
>> 
>>> Am 17.10.2016 um 09:11 schrieb Esben Andreasen <esben at esbena.dk>:
>>> 
>>> A.
>>> Where can I read about such non-ECMA-standard features in Nashorn?
>>> 
>> 
>> https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions
>> 
>> I don?t think the string methods from java.lang.String are contained in that page because, as Attila said, it is a side effect of using java.lang.String as JS string representation and transparently exposing Java methods to scripts.
> 
> I was thinking that maybe we shoud switch off Java methods on Nashorn primitives with --no-java. A quick test shows we don?t do that now.
> 
> Attila.


From sundararajan.athijegannathan at oracle.com  Mon Oct 17 16:26:57 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 17 Oct 2016 21:56:57 +0530
Subject: Java primitives should be disabled on JS objects when --no-java
	is used
In-Reply-To: <9DB37C6F-047D-42FF-8DA6-8D6E1E092D76@oracle.com>
References: <CAE_ENxUDv3PToXW9iV-C-rA-pX7XHXUDhEk1FEbyBkEzdmP79A@mail.gmail.com>
	<5FA6DB8D-FAC7-4C59-B283-5B3256EA6FC0@gmail.com>
	<CAE_ENxWiu9HG7Mgn61+J5rH_kvSOEo0TEqoNdKahBr_XcPBcHA@mail.gmail.com>
	<98E84CEE-B1AA-4B29-A127-A5DE46D857D9@oracle.com>
	<A9A0DF32-FA5D-41C5-B231-90F7FC3F2E4B@gmail.com>
	<9DB37C6F-047D-42FF-8DA6-8D6E1E092D76@oracle.com>
Message-ID: <cf92c91f-a548-d550-bbb1-33c78e371e6b@oracle.com>

[just fixing title so that nashorn-dev archive's list is readable in future]

-Sundar

On 10/17/2016 9:47 PM, Hannes Walln?fer wrote:
> In fact there's https://bugs.openjdk.java.net/browse/JDK-8157723, which was filed by you and waiting for me. I actually dug it up earlier today. The fix you suggested seems to be working, so it looks like we should do this.
>
> Hannes
>
>
>> Am 17.10.2016 um 17:27 schrieb Attila Szegedi <szegedia at gmail.com>:
>>
>>> On 17 Oct 2016, at 03:21, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
>>>
>>> Hi Esben,
>>>
>>>
>>>> Am 17.10.2016 um 09:11 schrieb Esben Andreasen <esben at esbena.dk>:
>>>>
>>>> A.
>>>> Where can I read about such non-ECMA-standard features in Nashorn?
>>>>
>>> https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions
>>>
>>> I don?t think the string methods from java.lang.String are contained in that page because, as Attila said, it is a side effect of using java.lang.String as JS string representation and transparently exposing Java methods to scripts.
>> I was thinking that maybe we shoud switch off Java methods on Nashorn primitives with --no-java. A quick test shows we don?t do that now.
>>
>> Attila.


From sundararajan.athijegannathan at oracle.com  Tue Oct 18 11:36:03 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Tue, 18 Oct 2016 17:06:03 +0530
Subject: RFR 8071678: javax.script.ScriptContext setAttribute method should
	clarify behavior when GLOBAL_SCOPE is used and global scope object is
	null
Message-ID: <27740553-a8b2-afde-1cde-4afbdb32b3e2@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8071678/webrev.00/ for
https://bugs.openjdk.java.net/browse/JDK-8071678

Thanks,

-Sundar


From james.laskey at oracle.com  Tue Oct 18 11:38:21 2016
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Tue, 18 Oct 2016 08:38:21 -0300
Subject: RFR 8071678: javax.script.ScriptContext setAttribute method
	should clarify behavior when GLOBAL_SCOPE is used and global scope
	object is null
In-Reply-To: <27740553-a8b2-afde-1cde-4afbdb32b3e2@oracle.com>
References: <27740553-a8b2-afde-1cde-4afbdb32b3e2@oracle.com>
Message-ID: <0E4B95F2-A59F-481D-ABAA-AA81111E5060@oracle.com>

+1

> On Oct 18, 2016, at 8:36 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8071678/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8071678
> 
> Thanks,
> 
> -Sundar
> 


From hannes.wallnoefer at oracle.com  Tue Oct 18 11:44:37 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Tue, 18 Oct 2016 13:44:37 +0200
Subject: RFR 8071678: javax.script.ScriptContext setAttribute method
	should clarify behavior when GLOBAL_SCOPE is used and global
	scope object is null
In-Reply-To: <27740553-a8b2-afde-1cde-4afbdb32b3e2@oracle.com>
References: <27740553-a8b2-afde-1cde-4afbdb32b3e2@oracle.com>
Message-ID: <236D22DD-F13C-4EC8-8D17-1299038EE07B@oracle.com>

+1

Hannes

> Am 18.10.2016 um 13:36 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
> 
> Please review http://cr.openjdk.java.net/~sundar/8071678/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8071678
> 
> Thanks,
> 
> -Sundar
> 


From sundararajan.athijegannathan at oracle.com  Wed Oct 19 05:06:46 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 19 Oct 2016 10:36:46 +0530
Subject: RFR 8071588: The spec for
	javax.script.ScriptEngineFactory.getProgram() should specify NPEs
	thrown
Message-ID: <12a836e8-89c6-642c-b199-061e0feb0ff4@oracle.com>

Please review.

Bug: https://bugs.openjdk.java.net/browse/JDK-8071588

jdk webrev: http://cr.openjdk.java.net/~sundar/8071588/jdk/webrev.00/

nashorn webrev:
http://cr.openjdk.java.net/~sundar/8071588/nashorn/webrev.00/

Thanks

-Sundar


From hannes.wallnoefer at oracle.com  Wed Oct 19 07:07:40 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Wed, 19 Oct 2016 09:07:40 +0200
Subject: RFR 8071588: The spec for
	javax.script.ScriptEngineFactory.getProgram() should specify
	NPEs thrown
In-Reply-To: <12a836e8-89c6-642c-b199-061e0feb0ff4@oracle.com>
References: <12a836e8-89c6-642c-b199-061e0feb0ff4@oracle.com>
Message-ID: <8A0EF75C-ED19-46D7-8D89-A3A54AF2EF41@oracle.com>

+1

Hannes

> Am 19.10.2016 um 07:06 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
> 
> Please review.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8071588
> 
> jdk webrev: http://cr.openjdk.java.net/~sundar/8071588/jdk/webrev.00/
> 
> nashorn webrev:
> http://cr.openjdk.java.net/~sundar/8071588/nashorn/webrev.00/
> 
> Thanks
> 
> -Sundar
> 


From Alan.Bateman at oracle.com  Wed Oct 19 07:12:57 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 19 Oct 2016 08:12:57 +0100
Subject: RFR 8071588: The spec for
	javax.script.ScriptEngineFactory.getProgram() should specify NPEs
	thrown
In-Reply-To: <12a836e8-89c6-642c-b199-061e0feb0ff4@oracle.com>
References: <12a836e8-89c6-642c-b199-061e0feb0ff4@oracle.com>
Message-ID: <91d155ec-6018-6606-6941-85180cf477e7@oracle.com>

On 19/10/2016 06:06, Sundararajan Athijegannathan wrote:

> Please review.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8071588
>
> jdk webrev: http://cr.openjdk.java.net/~sundar/8071588/jdk/webrev.00/
>
> nashorn webrev:
> http://cr.openjdk.java.net/~sundar/8071588/nashorn/webrev.00/
>
This looks okay (except the spurious blank line after the class 
comment). It's a spec change that will need to be tracked.

-Alan

From sundararajan.athijegannathan at oracle.com  Wed Oct 19 07:55:22 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 19 Oct 2016 13:25:22 +0530
Subject: RFR 8071588: The spec for
	javax.script.ScriptEngineFactory.getProgram()
	should specify NPEs thrown
In-Reply-To: <91d155ec-6018-6606-6941-85180cf477e7@oracle.com>
References: <12a836e8-89c6-642c-b199-061e0feb0ff4@oracle.com>
	<91d155ec-6018-6606-6941-85180cf477e7@oracle.com>
Message-ID: <580726EA.9070102@oracle.com>

Hi Alan,

Thanks for your review. Yes, spec. change is being tracked. I'll remove 
that whitespace after doc comment of getProgram method and push it.

PS. Updated webrev for the record: 
http://cr.openjdk.java.net/~sundar/8071588/jdk/webrev.01/

Thanks,
-Sundar

On 19/10/16, 12:42 PM, Alan Bateman wrote:
> On 19/10/2016 06:06, Sundararajan Athijegannathan wrote:
>
>> Please review.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071588
>>
>> jdk webrev: http://cr.openjdk.java.net/~sundar/8071588/jdk/webrev.00/
>>
>> nashorn webrev:
>> http://cr.openjdk.java.net/~sundar/8071588/nashorn/webrev.00/
>>
> This looks okay (except the spurious blank line after the class 
> comment). It's a spec change that will need to be tracked.
>
> -Alan

From hannes.wallnoefer at oracle.com  Wed Oct 19 09:41:42 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Wed, 19 Oct 2016 11:41:42 +0200
Subject: RFR: 8168146 : Infinite recursion in Uint8ClampedArray.set
Message-ID: <76491A13-9EF4-4B89-B779-279EE398A9C9@oracle.com>

Please review:

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

The (int) cast is all that?s needed to fix the bug. I also reviewed the setter for long values which isn?t used anymore.

Thanks, 
Hannes

From emilian.bold at gmail.com  Wed Oct 19 10:24:32 2016
From: emilian.bold at gmail.com (Emilian Bold)
Date: Wed, 19 Oct 2016 13:24:32 +0300
Subject: RFR: 8168146 : Infinite recursion in Uint8ClampedArray.set
In-Reply-To: <76491A13-9EF4-4B89-B779-279EE398A9C9@oracle.com>
References: <76491A13-9EF4-4B89-B779-279EE398A9C9@oracle.com>
Message-ID: <CAL6R17B0SYiccjJQK3muJ1n=cdOmoU8P58TT00PU=xpOUr+HYQ@mail.gmail.com>

Not a committer but the patch was easy to understand, so +1 unbinding.

Seems to me this was bound to happen due to boxing and overloaded methods
and have int and Object arguments.






--emi

On Wed, Oct 19, 2016 at 12:41 PM, Hannes Walln?fer <
hannes.wallnoefer at oracle.com> wrote:

> Please review:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8168146
> Webrev: http://cr.openjdk.java.net/~hannesw/8168146/webrev/
>
> The (int) cast is all that?s needed to fix the bug. I also reviewed the
> setter for long values which isn?t used anymore.
>
> Thanks,
> Hannes

From sundararajan.athijegannathan at oracle.com  Wed Oct 19 10:48:31 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 19 Oct 2016 16:18:31 +0530
Subject: RFR: 8168146 : Infinite recursion in Uint8ClampedArray.set
In-Reply-To: <76491A13-9EF4-4B89-B779-279EE398A9C9@oracle.com>
References: <76491A13-9EF4-4B89-B779-279EE398A9C9@oracle.com>
Message-ID: <6860d6c3-3554-3d72-2f48-d108c9c69f6e@oracle.com>

+1

-Sundar


On 10/19/2016 3:11 PM, Hannes Walln?fer wrote:
> Please review:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8168146
> Webrev: http://cr.openjdk.java.net/~hannesw/8168146/webrev/
>
> The (int) cast is all that?s needed to fix the bug. I also reviewed the setter for long values which isn?t used anymore.
>
> Thanks, 
> Hannes


From hannes.wallnoefer at oracle.com  Wed Oct 19 12:52:24 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Wed, 19 Oct 2016 14:52:24 +0200
Subject: RFR: 8168140: TypedArrays should implement ES6 iterator protocol
Message-ID: <76F5B25C-4DB5-41CC-8D55-B366FA4BD0D2@oracle.com>

Please review:

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

I tried to tweak nasgen to allow me to define the new prototype functions just in the common ArrayBufferView base class, but this turned out to be very complicated so I kept it simple and redundant. 

Thanks,
Hannes

From sundararajan.athijegannathan at oracle.com  Thu Oct 20 03:50:32 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 20 Oct 2016 09:20:32 +0530
Subject: RFR: 8168140: TypedArrays should implement ES6 iterator protocol
In-Reply-To: <76F5B25C-4DB5-41CC-8D55-B366FA4BD0D2@oracle.com>
References: <76F5B25C-4DB5-41CC-8D55-B366FA4BD0D2@oracle.com>
Message-ID: <e1020975-12d4-276b-129c-903cc7550770@oracle.com>

Could this:

+ return new ArrayIterator(Global.toObject(self),
AbstractIterator.IterationKind.VALUE, Global.instance());


be in static utility method somewhere and be called from everywhere?

Thanks,
-Sundar

On 10/19/2016 6:22 PM, Hannes Walln?fer wrote:
> Please review:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8168140
> Webrev: http://cr.openjdk.java.net/~hannesw/8168140/webrev.00/
>
> I tried to tweak nasgen to allow me to define the new prototype functions just in the common ArrayBufferView base class, but this turned out to be very complicated so I kept it simple and redundant. 
>
> Thanks,
> Hannes


From hannes.wallnoefer at oracle.com  Thu Oct 20 16:06:27 2016
From: hannes.wallnoefer at oracle.com (=?windows-1252?Q?Hannes_Walln=F6fer?=)
Date: Thu, 20 Oct 2016 18:06:27 +0200
Subject: RFR: 8168140: TypedArrays should implement ES6 iterator protocol
In-Reply-To: <e1020975-12d4-276b-129c-903cc7550770@oracle.com>
References: <76F5B25C-4DB5-41CC-8D55-B366FA4BD0D2@oracle.com>
	<e1020975-12d4-276b-129c-903cc7550770@oracle.com>
Message-ID: <E5FB9BDD-ECA0-4F81-90EC-BF4C96847368@oracle.com>

Thanks, Sundar. I uploaded a new webrev with static utility methods for all array iterators:

http://cr.openjdk.java.net/~hannesw/8168140/webrev.01/

Also, I removed the ?values" methods from typed arrays. We don?t yet support other TypedArray methods specified in ES6, and the purpose of this patch is to just support for-of loops for which only the @@iterator method is needed. I also updated the Jira description to reflect this.

Hannes


> Am 20.10.2016 um 05:50 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
> 
> Could this:
> 
> + return new ArrayIterator(Global.toObject(self),
> AbstractIterator.IterationKind.VALUE, Global.instance());
> 
> 
> be in static utility method somewhere and be called from everywhere?
> 
> Thanks,
> -Sundar
> 
> On 10/19/2016 6:22 PM, Hannes Walln?fer wrote:
>> Please review:
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8168140
>> Webrev: http://cr.openjdk.java.net/~hannesw/8168140/webrev.00/
>> 
>> I tried to tweak nasgen to allow me to define the new prototype functions just in the common ArrayBufferView base class, but this turned out to be very complicated so I kept it simple and redundant. 
>> 
>> Thanks,
>> Hannes
> 


From sundararajan.athijegannathan at oracle.com  Thu Oct 20 16:09:17 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 20 Oct 2016 21:39:17 +0530
Subject: RFR: 8168140: TypedArrays should implement ES6 iterator protocol
In-Reply-To: <E5FB9BDD-ECA0-4F81-90EC-BF4C96847368@oracle.com>
References: <76F5B25C-4DB5-41CC-8D55-B366FA4BD0D2@oracle.com>
	<e1020975-12d4-276b-129c-903cc7550770@oracle.com>
	<E5FB9BDD-ECA0-4F81-90EC-BF4C96847368@oracle.com>
Message-ID: <c66172ca-b7f0-a806-20e0-c1b772a32dc0@oracle.com>

+1

-Sundar


On 10/20/2016 9:36 PM, Hannes Walln?fer wrote:
> Thanks, Sundar. I uploaded a new webrev with static utility methods for all array iterators:
>
> http://cr.openjdk.java.net/~hannesw/8168140/webrev.01/
>
> Also, I removed the ?values" methods from typed arrays. We don?t yet support other TypedArray methods specified in ES6, and the purpose of this patch is to just support for-of loops for which only the @@iterator method is needed. I also updated the Jira description to reflect this.
>
> Hannes
>
>
>> Am 20.10.2016 um 05:50 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
>>
>> Could this:
>>
>> + return new ArrayIterator(Global.toObject(self),
>> AbstractIterator.IterationKind.VALUE, Global.instance());
>>
>>
>> be in static utility method somewhere and be called from everywhere?
>>
>> Thanks,
>> -Sundar
>>
>> On 10/19/2016 6:22 PM, Hannes Walln?fer wrote:
>>> Please review:
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8168140
>>> Webrev: http://cr.openjdk.java.net/~hannesw/8168140/webrev.00/
>>>
>>> I tried to tweak nasgen to allow me to define the new prototype functions just in the common ArrayBufferView base class, but this turned out to be very complicated so I kept it simple and redundant. 
>>>
>>> Thanks,
>>> Hannes


From marcus at lagergren.net  Fri Oct 21 05:31:07 2016
From: marcus at lagergren.net (Marcus Lagergren)
Date: Fri, 21 Oct 2016 07:31:07 +0200
Subject: RFR: 8168140: TypedArrays should implement ES6 iterator protocol
In-Reply-To: <E5FB9BDD-ECA0-4F81-90EC-BF4C96847368@oracle.com>
References: <76F5B25C-4DB5-41CC-8D55-B366FA4BD0D2@oracle.com>
	<e1020975-12d4-276b-129c-903cc7550770@oracle.com>
	<E5FB9BDD-ECA0-4F81-90EC-BF4C96847368@oracle.com>
Message-ID: <CB714290-4FA1-49AD-BE87-6B7F3667ED6D@lagergren.net>

+1

> On 20 Oct 2016, at 18:06, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
> 
> Thanks, Sundar. I uploaded a new webrev with static utility methods for all array iterators:
> 
> http://cr.openjdk.java.net/~hannesw/8168140/webrev.01/
> 
> Also, I removed the ?values" methods from typed arrays. We don?t yet support other TypedArray methods specified in ES6, and the purpose of this patch is to just support for-of loops for which only the @@iterator method is needed. I also updated the Jira description to reflect this.
> 
> Hannes
> 
> 
>> Am 20.10.2016 um 05:50 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
>> 
>> Could this:
>> 
>> + return new ArrayIterator(Global.toObject(self),
>> AbstractIterator.IterationKind.VALUE, Global.instance());
>> 
>> 
>> be in static utility method somewhere and be called from everywhere?
>> 
>> Thanks,
>> -Sundar
>> 
>> On 10/19/2016 6:22 PM, Hannes Walln?fer wrote:
>>> Please review:
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8168140
>>> Webrev: http://cr.openjdk.java.net/~hannesw/8168140/webrev.00/
>>> 
>>> I tried to tweak nasgen to allow me to define the new prototype functions just in the common ArrayBufferView base class, but this turned out to be very complicated so I kept it simple and redundant. 
>>> 
>>> Thanks,
>>> Hannes
>> 
> 


From hannes.wallnoefer at oracle.com  Fri Oct 21 15:21:12 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Fri, 21 Oct 2016 17:21:12 +0200
Subject: RFR: 8164708: String.prototype.replace replaces empty match twice
Message-ID: <A2BDBE52-FBBB-4803-9B67-EEB0056D82C7@oracle.com>

Please review:

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

We need to always advance the index of a global replace if previous match string was empty. It seems like this is a spec bug in ES5 that was fixed in ES6.

Thanks,
Hannes

From sundararajan.athijegannathan at oracle.com  Mon Oct 24 10:40:03 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 24 Oct 2016 16:10:03 +0530
Subject: RFR: 8164708: String.prototype.replace replaces empty match twice
In-Reply-To: <A2BDBE52-FBBB-4803-9B67-EEB0056D82C7@oracle.com>
References: <A2BDBE52-FBBB-4803-9B67-EEB0056D82C7@oracle.com>
Message-ID: <9e0ab609-80e6-d9ab-5f0f-bdd154d511ff@oracle.com>

+1

-Sundar


On 10/21/2016 8:51 PM, Hannes Walln?fer wrote:
> Please review:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8164708
> Webrev: http://cr.openjdk.java.net/~hannesw/8164708/webrev/
>
> We need to always advance the index of a global replace if previous match string was empty. It seems like this is a spec bug in ES5 that was fixed in ES6.
>
> Thanks,
> Hannes


From szegedia at gmail.com  Mon Oct 24 11:12:41 2016
From: szegedia at gmail.com (Attila Szegedi)
Date: Mon, 24 Oct 2016 04:12:41 -0700
Subject: RFR: 8164708: String.prototype.replace replaces empty match twice
In-Reply-To: <9e0ab609-80e6-d9ab-5f0f-bdd154d511ff@oracle.com>
References: <A2BDBE52-FBBB-4803-9B67-EEB0056D82C7@oracle.com>
	<9e0ab609-80e6-d9ab-5f0f-bdd154d511ff@oracle.com>
Message-ID: <CAMYVXdsy-bv3saWpdHcwkJiwC0sMTxnHiaZHAHuBDnsu7WNT6w@mail.gmail.com>

+1

On Monday, October 24, 2016, Sundararajan Athijegannathan <
sundararajan.athijegannathan at oracle.com> wrote:

> +1
>
> -Sundar
>
>
> On 10/21/2016 8:51 PM, Hannes Walln?fer wrote:
> > Please review:
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8164708
> > Webrev: http://cr.openjdk.java.net/~hannesw/8164708/webrev/
> >
> > We need to always advance the index of a global replace if previous
> match string was empty. It seems like this is a spec bug in ES5 that was
> fixed in ES6.
> >
> > Thanks,
> > Hannes
>
>

From ravikirans1271 at gmail.com  Tue Oct 25 12:20:33 2016
From: ravikirans1271 at gmail.com (RAVI KIRAN)
Date: Tue, 25 Oct 2016 17:50:33 +0530
Subject: Help Needed To Build a standard Nashorn JAR File
Message-ID: <CACVM532HfavQPoGKQH4vSuvFB4nimb4nToJQMGnc95Pz8tqhzA@mail.gmail.com>

Hello Team,

Good Evening. Hope you all doing great. I have been going through some of
videos and blogs to understand Nashorn. We have requirement to upgrade
Existing Java Script Engine(Rhino) to Nashorn.

Current Rhino script engine is encapsulated as jar file and placed in our
Integration environment where the JAR file is used to build Java Interfaces

Now Request is to replace Rhino jar with Nashorn JAR and existing code
should work as expected. Hence I need help to Build a Nashorn JAR file
which has all calsses  imported from Java 1.8. Though i found some blog
about building Nashorn which is not much clear to me

*https://wiki.openjdk.java.net/display/Nashorn/Building+Nashorn
<https://wiki.openjdk.java.net/display/Nashorn/Building+Nashorn>*

We use Linux environment and Nashorn JAR should be built on the same

I couldn't find standard Nashorn JAR for download. Please assist how can i
Build a Jar File in detail or can i download it from any specific location.

Suggestion of Building new JAR is highly Appreciated.

Thanks for your understanding

Regards
Ravi kiran

From hannes.wallnoefer at oracle.com  Tue Oct 25 12:32:44 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Tue, 25 Oct 2016 14:32:44 +0200
Subject: RFR: 8157723: --no-java should disable POJO methods on JS primitives
Message-ID: <2D83F79C-AF5E-44C7-B050-B712AAFE828D@oracle.com>

Please review:

Bug: http://cr.openjdk.java.net/~hannesw/8157723/webrev/
Webrev: http://cr.openjdk.java.net/~hannesw/8157723/webrev/

Thanks,
Hannes

From emilian.bold at gmail.com  Tue Oct 25 12:36:02 2016
From: emilian.bold at gmail.com (Emilian Bold)
Date: Tue, 25 Oct 2016 15:36:02 +0300
Subject: Help Needed To Build a standard Nashorn JAR File
In-Reply-To: <CACVM532HfavQPoGKQH4vSuvFB4nimb4nToJQMGnc95Pz8tqhzA@mail.gmail.com>
References: <CACVM532HfavQPoGKQH4vSuvFB4nimb4nToJQMGnc95Pz8tqhzA@mail.gmail.com>
Message-ID: <CAL6R17BWTK41Mty47s5-0rLdnRDkWGAH8q5tvcWNGjYFafRRNQ@mail.gmail.com>

Why are you trying to do this? Nashorn should be part of the JRE.

Which JRE/JDK are you using?


--emi

On Tue, Oct 25, 2016 at 3:20 PM, RAVI KIRAN <ravikirans1271 at gmail.com>
wrote:

> Hello Team,
>
> Good Evening. Hope you all doing great. I have been going through some of
> videos and blogs to understand Nashorn. We have requirement to upgrade
> Existing Java Script Engine(Rhino) to Nashorn.
>
> Current Rhino script engine is encapsulated as jar file and placed in our
> Integration environment where the JAR file is used to build Java Interfaces
>
> Now Request is to replace Rhino jar with Nashorn JAR and existing code
> should work as expected. Hence I need help to Build a Nashorn JAR file
> which has all calsses  imported from Java 1.8. Though i found some blog
> about building Nashorn which is not much clear to me
>
> *https://wiki.openjdk.java.net/display/Nashorn/Building+Nashorn
> <https://wiki.openjdk.java.net/display/Nashorn/Building+Nashorn>*
>
> We use Linux environment and Nashorn JAR should be built on the same
>
> I couldn't find standard Nashorn JAR for download. Please assist how can i
> Build a Jar File in detail or can i download it from any specific location.
>
> Suggestion of Building new JAR is highly Appreciated.
>
> Thanks for your understanding
>
> Regards
> Ravi kiran
>

From sundararajan.athijegannathan at oracle.com  Tue Oct 25 13:10:07 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Tue, 25 Oct 2016 18:40:07 +0530
Subject: Help Needed To Build a standard Nashorn JAR File
In-Reply-To: <CAL6R17BWTK41Mty47s5-0rLdnRDkWGAH8q5tvcWNGjYFafRRNQ@mail.gmail.com>
References: <CACVM532HfavQPoGKQH4vSuvFB4nimb4nToJQMGnc95Pz8tqhzA@mail.gmail.com>
	<CAL6R17BWTK41Mty47s5-0rLdnRDkWGAH8q5tvcWNGjYFafRRNQ@mail.gmail.com>
Message-ID: <ba6f610a-c18e-e00b-c2e0-6237651e9f12@oracle.com>

That's right! You don't need to do anything special to use nashorn with
jdk8u release. Nashorn.jar is already part of JRE of 8u.

-Sundar

On 10/25/2016 6:06 PM, Emilian Bold wrote:
> Why are you trying to do this? Nashorn should be part of the JRE.
>
> Which JRE/JDK are you using?
>
>
> --emi
>
> On Tue, Oct 25, 2016 at 3:20 PM, RAVI KIRAN <ravikirans1271 at gmail.com>
> wrote:
>
>> Hello Team,
>>
>> Good Evening. Hope you all doing great. I have been going through some of
>> videos and blogs to understand Nashorn. We have requirement to upgrade
>> Existing Java Script Engine(Rhino) to Nashorn.
>>
>> Current Rhino script engine is encapsulated as jar file and placed in our
>> Integration environment where the JAR file is used to build Java Interfaces
>>
>> Now Request is to replace Rhino jar with Nashorn JAR and existing code
>> should work as expected. Hence I need help to Build a Nashorn JAR file
>> which has all calsses  imported from Java 1.8. Though i found some blog
>> about building Nashorn which is not much clear to me
>>
>> *https://wiki.openjdk.java.net/display/Nashorn/Building+Nashorn
>> <https://wiki.openjdk.java.net/display/Nashorn/Building+Nashorn>*
>>
>> We use Linux environment and Nashorn JAR should be built on the same
>>
>> I couldn't find standard Nashorn JAR for download. Please assist how can i
>> Build a Jar File in detail or can i download it from any specific location.
>>
>> Suggestion of Building new JAR is highly Appreciated.
>>
>> Thanks for your understanding
>>
>> Regards
>> Ravi kiran
>>


From hannes.wallnoefer at oracle.com  Tue Oct 25 14:45:24 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Tue, 25 Oct 2016 16:45:24 +0200
Subject: RFR: 8148924: Inconsistent "this" context in JSAdapter adaptee
	function calls
Message-ID: <B711CF23-C13D-48B5-B749-DF6B213BE82F@oracle.com>

Please review:

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

Thanks,
Hannes

From szegedia at gmail.com  Wed Oct 26 10:48:46 2016
From: szegedia at gmail.com (Attila Szegedi)
Date: Wed, 26 Oct 2016 12:48:46 +0200
Subject: Review request for JDK-8168005: Introduce namespaces for GET,
	SET Dynalink operations
Message-ID: <C8D20E7E-2703-4010-8F9B-1D3C9F4CE087@gmail.com>

Please review JDK-8168005 "Introduce namespaces for GET, SET Dynalink operations" at <http://cr.openjdk.java.net/~attila/8168005/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8168005>

The JIRA issue has detailed rationale for the change. The diff is moderately large, but the Dynalink API changes are only a part of it, the rest is adjusting Nashorn, code examples, and tests to the changed API.

Thanks,
  Attila.


From sundararajan.athijegannathan at oracle.com  Wed Oct 26 15:18:18 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 26 Oct 2016 20:48:18 +0530
Subject: Review request for JDK-8168005: Introduce namespaces for GET, SET
	Dynalink operations
In-Reply-To: <C8D20E7E-2703-4010-8F9B-1D3C9F4CE087@gmail.com>
References: <C8D20E7E-2703-4010-8F9B-1D3C9F4CE087@gmail.com>
Message-ID: <4944e3da-6fc4-0463-d348-3b0a72da62b4@oracle.com>

+1

-Sundar


On 10/26/2016 4:18 PM, Attila Szegedi wrote:
> Please review JDK-8168005 "Introduce namespaces for GET, SET Dynalink operations" at <http://cr.openjdk.java.net/~attila/8168005/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8168005>
>
> The JIRA issue has detailed rationale for the change. The diff is moderately large, but the Dynalink API changes are only a part of it, the rest is adjusting Nashorn, code examples, and tests to the changed API.
>
> Thanks,
>   Attila.
>


From andreas.woess at oracle.com  Wed Oct 26 16:30:49 2016
From: andreas.woess at oracle.com (Andreas Woess)
Date: Wed, 26 Oct 2016 18:30:49 +0200
Subject: Review request for JDK-8168005: Introduce namespaces for GET, SET
	Dynalink operations
In-Reply-To: <C8D20E7E-2703-4010-8F9B-1D3C9F4CE087@gmail.com>
References: <C8D20E7E-2703-4010-8F9B-1D3C9F4CE087@gmail.com>
Message-ID: <f3680b05-976e-1d8a-2ce8-cc547c142180@oracle.com>

Not a review, but one remark: it does not make sense that NamedOperation
is a final class given the protected changeNameInternal method.
Also, in the javadoc of this class: "The contract for these operation is"

Regards,
 Andreas

On 2016-10-26 12:48, Attila Szegedi wrote:
> Please review JDK-8168005 "Introduce namespaces for GET, SET Dynalink operations" at <http://cr.openjdk.java.net/~attila/8168005/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8168005>
>
> The JIRA issue has detailed rationale for the change. The diff is moderately large, but the Dynalink API changes are only a part of it, the rest is adjusting Nashorn, code examples, and tests to the changed API.
>
> Thanks,
>   Attila.
>


From szegedia at gmail.com  Wed Oct 26 16:43:41 2016
From: szegedia at gmail.com (Attila Szegedi)
Date: Wed, 26 Oct 2016 18:43:41 +0200
Subject: Review request for JDK-8168005: Introduce namespaces for GET,
	SET Dynalink operations
In-Reply-To: <f3680b05-976e-1d8a-2ce8-cc547c142180@oracle.com>
References: <C8D20E7E-2703-4010-8F9B-1D3C9F4CE087@gmail.com>
	<f3680b05-976e-1d8a-2ce8-cc547c142180@oracle.com>
Message-ID: <206BD2F8-1B9A-4419-952B-143BEFDED0FE@gmail.com>

Hi Andreas,

you?re of course right about NamedOperation finality, that?s an oversight on my part. Also thanks for catching the documentation error. I?ll fix both.

Thanks,
  Attila.

> On 26 Oct 2016, at 18:30, Andreas Woess <andreas.woess at oracle.com> wrote:
> 
> Not a review, but one remark: it does not make sense that NamedOperation
> is a final class given the protected changeNameInternal method.
> Also, in the javadoc of this class: "The contract for these operation is"
> 
> Regards,
> Andreas
> 
> On 2016-10-26 12:48, Attila Szegedi wrote:
>> Please review JDK-8168005 "Introduce namespaces for GET, SET Dynalink operations" at <http://cr.openjdk.java.net/~attila/8168005/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8168005>
>> 
>> The JIRA issue has detailed rationale for the change. The diff is moderately large, but the Dynalink API changes are only a part of it, the rest is adjusting Nashorn, code examples, and tests to the changed API.
>> 
>> Thanks,
>>  Attila.
>> 
> 


From hannes.wallnoefer at oracle.com  Thu Oct 27 13:05:17 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Thu, 27 Oct 2016 15:05:17 +0200
Subject: Review request for JDK-8168005: Introduce namespaces for GET, SET
	Dynalink operations
In-Reply-To: <C8D20E7E-2703-4010-8F9B-1D3C9F4CE087@gmail.com>
References: <C8D20E7E-2703-4010-8F9B-1D3C9F4CE087@gmail.com>
Message-ID: <CF828584-196D-422E-9F46-9E9597000E01@oracle.com>

Hi Attila,

this looks good. Very nice work, the new API is indeed much nicer!

Hannes

> Am 26.10.2016 um 12:48 schrieb Attila Szegedi <szegedia at gmail.com>:
> 
> Please review JDK-8168005 "Introduce namespaces for GET, SET Dynalink operations" at <http://cr.openjdk.java.net/~attila/8168005/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8168005>
> 
> The JIRA issue has detailed rationale for the change. The diff is moderately large, but the Dynalink API changes are only a part of it, the rest is adjusting Nashorn, code examples, and tests to the changed API.
> 
> Thanks,
>  Attila.
> 


From james.laskey at oracle.com  Fri Oct 28 13:53:57 2016
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Fri, 28 Oct 2016 10:53:57 -0300
Subject: RFR: 8148924: Inconsistent "this" context in JSAdapter adaptee
	function calls
In-Reply-To: <B711CF23-C13D-48B5-B749-DF6B213BE82F@oracle.com>
References: <B711CF23-C13D-48B5-B749-DF6B213BE82F@oracle.com>
Message-ID: <BE3AE7AD-2BA0-4DC6-8818-EFC947271616@oracle.com>

+1

> On Oct 25, 2016, at 11:45 AM, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8148924
> Webrev: http://cr.openjdk.java.net/~hannesw/8148924/webrev/
> 
> Thanks,
> Hannes


From pmlopes at gmail.com  Fri Oct 28 14:05:55 2016
From: pmlopes at gmail.com (Paulo Lopes)
Date: Fri, 28 Oct 2016 16:05:55 +0200
Subject: dynalink alternative for jdk8
Message-ID: <CAPdn05-SPuSYN_UyMWmC+zEf0Rw1xkiyvMOxDQGdEhxjxzCcJg@mail.gmail.com>

Hi everyone,

I'm working with eclipse vert.x project javascript support and one
thing we would like to achieve was to simplify our bindings code by
having what could be done with dynalink to provide "automatic"
conversion between:

JSObject <--> io.vertx.core.json.JsonObject

We do not want to introduce helper functions to the end user like:

var java_type_object = Java.type(...);

java_type_object.someMethod(to_native({k: 1}));

but we would like to have:

java_type_object.someMethod({k: 1});


Currently we have a code generator that writes a full wrapper for the
vert.x API that will do this translation, but this has several
limitations, we must force a very restricted set of types to be used in
public APIs, there's a build step for each module, introduces potential
bugs if the generated code is not correct.

After reading the Dynalink API and examples from JDK9 it seems that
this could be done with it since one could write a linker from JSObject
properties to JsonObject and vice-versa but this is not present on
JDK8.

Even though dynalink was present on JDK8 the service loader is not
present or at least should not be used.

So my question is, what alternatives/suggestions do you have to achieve
this?

I'm thinking of something like groovy metaprogramming but that would
also require dynalink, or not?

For the sake of completeness I must say that JsonObject/JsonArray do
not implement java.util.Map/java.util.List interfaces so one cannot
rely on the fact that nashorn would internally handle those for us.

Best regards,
Paulo

From szegedia at gmail.com  Fri Oct 28 15:43:43 2016
From: szegedia at gmail.com (Attila Szegedi)
Date: Fri, 28 Oct 2016 17:43:43 +0200
Subject: RFR: 8148924: Inconsistent "this" context in JSAdapter adaptee
	function calls
In-Reply-To: <B711CF23-C13D-48B5-B749-DF6B213BE82F@oracle.com>
References: <B711CF23-C13D-48B5-B749-DF6B213BE82F@oracle.com>
Message-ID: <439E80DF-8FBD-4844-8F00-6D435E0C1DF7@gmail.com>

+1

> On 25 Oct 2016, at 16:45, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8148924
> Webrev: http://cr.openjdk.java.net/~hannesw/8148924/webrev/
> 
> Thanks,
> Hannes


From szegedia at gmail.com  Fri Oct 28 15:44:32 2016
From: szegedia at gmail.com (Attila Szegedi)
Date: Fri, 28 Oct 2016 17:44:32 +0200
Subject: Review request for JDK-8168005: Introduce namespaces for GET,
	SET Dynalink operations
In-Reply-To: <CF828584-196D-422E-9F46-9E9597000E01@oracle.com>
References: <C8D20E7E-2703-4010-8F9B-1D3C9F4CE087@gmail.com>
	<CF828584-196D-422E-9F46-9E9597000E01@oracle.com>
Message-ID: <C5B21F71-746D-4729-BE4F-4E10BAF5B84E@gmail.com>

Thank you; can I consider this an approval on your part?

> On 27 Oct 2016, at 15:05, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
> 
> Hi Attila,
> 
> this looks good. Very nice work, the new API is indeed much nicer!
> 
> Hannes
> 
>> Am 26.10.2016 um 12:48 schrieb Attila Szegedi <szegedia at gmail.com>:
>> 
>> Please review JDK-8168005 "Introduce namespaces for GET, SET Dynalink operations" at <http://cr.openjdk.java.net/~attila/8168005/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8168005>
>> 
>> The JIRA issue has detailed rationale for the change. The diff is moderately large, but the Dynalink API changes are only a part of it, the rest is adjusting Nashorn, code examples, and tests to the changed API.
>> 
>> Thanks,
>> Attila.
>> 
> 


From hannes.wallnoefer at oracle.com  Fri Oct 28 16:18:09 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Fri, 28 Oct 2016 18:18:09 +0200
Subject: Review request for JDK-8168005: Introduce namespaces for GET, SET
	Dynalink operations
In-Reply-To: <C5B21F71-746D-4729-BE4F-4E10BAF5B84E@gmail.com>
References: <C8D20E7E-2703-4010-8F9B-1D3C9F4CE087@gmail.com>
	<CF828584-196D-422E-9F46-9E9597000E01@oracle.com>
	<C5B21F71-746D-4729-BE4F-4E10BAF5B84E@gmail.com>
Message-ID: <F05B50A2-1542-4EC9-9312-48EF2912D4F4@oracle.com>


> Am 28.10.2016 um 17:44 schrieb Attila Szegedi <szegedia at gmail.com>:
> 
> Thank you; can I consider this an approval on your part?

Yes. Sorry for omitting the +1. :)

Hannes

> 
>> On 27 Oct 2016, at 15:05, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
>> 
>> Hi Attila,
>> 
>> this looks good. Very nice work, the new API is indeed much nicer!
>> 
>> Hannes
>> 
>>> Am 26.10.2016 um 12:48 schrieb Attila Szegedi <szegedia at gmail.com>:
>>> 
>>> Please review JDK-8168005 "Introduce namespaces for GET, SET Dynalink operations" at <http://cr.openjdk.java.net/~attila/8168005/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8168005>
>>> 
>>> The JIRA issue has detailed rationale for the change. The diff is moderately large, but the Dynalink API changes are only a part of it, the rest is adjusting Nashorn, code examples, and tests to the changed API.
>>> 
>>> Thanks,
>>> Attila.
>>> 
>> 
>