From emilian.bold at gmail.com  Wed Aug  3 08:15:04 2016
From: emilian.bold at gmail.com (Emilian Bold)
Date: Wed, 3 Aug 2016 11:15:04 +0300
Subject: Nashorn comment nodes in the syntax tree
In-Reply-To: <08d3c097-62fc-48bf-ded1-b8036b4715a5@oracle.com>
References: <08d3c097-62fc-48bf-ded1-b8036b4715a5@oracle.com>
Message-ID: <CAL6R17Cg6ueWp2FSukw8ijV-JkM=5S+52bMVyS--G_0zf3hE8w@mail.gmail.com>

>
> Also, please note that jdk.nashorn.internal.* packages are not APIs and
> therefore please avoid using those. Please use nashorn parser API
> defined by JEP 236 [ http://openjdk.java.net/jeps/236 ]


I cannot use JEP 236 yet because it's only part of Java 9 and it's not
being backported to JDK 8 (why??).

And I cannot use Java 9 because it hasn't been released yet.  Even if it
would be, no company would instantly pick it up, especially with the big
changes/breakages introduced by modules.

So my only choice is to use JDK 8 with jdk.nashorn.internal.* while trying
to keep an eye and maintain future compatibility with the JEP 236 Tree API.

Yes, comments are swallowed (by design). But, I initially though that
> disturbs line & column number info. [i.e., position of various trees].
> i.e., that was the bug you reported. That does not seem to be the case.


Could you tell me which classes produce the correct offsets in JDK 9
compared to JDK 8?

I have executed my test with Java 9 using the jdk.nashorn.internal.*
packages and the test still fails. Actually, it seems to me with JDK 9
functionNode.getStart() == functionNode.getFinish() so I'm not certain
where the offsets are stored now.



--emi

On Fri, Jul 22, 2016 at 10:38 AM, Sundararajan Athijegannathan <
sundararajan.athijegannathan at oracle.com> wrote:

> Hi,
>
> Yes, comments are swallowed (by design). But, I initially though that
> disturbs line & column number info. [i.e., position of various trees].
> i.e., that was the bug you reported. That does not seem to be the case.
>
> I wrote a simple sample and checked with jjs in jdk9 build. You can
> check start and end line/column numbers of subtrees (function,
> expression statement) are correct.
>
> Also, please note that jdk.nashorn.internal.* packages are not APIs and
> therefore please avoid using those. Please use nashorn parser API
> defined by JEP 236 [ http://openjdk.java.net/jeps/236 ]
>
> #-scripting needed
>
> var Parser = Java.type("jdk.nashorn.api.tree.Parser")
> var p = Parser.create();
> var cu = p.parse("t.js", <<EOF
> /* start script comment */
>
>   function hello(){
>  return 'world';
> }
>
> //some comment
>     hello();
> EOF, print);
>
> var src = cu.sourceElements;
> var itr = src.iterator();
> var lm = cu.lineMap;
> while (itr.hasNext()) {
>    var tree = itr.next();
>    var start = tree.startPosition;
>    var end = tree.endPosition;
>    print(tree.kind,
>      lm.getLineNumber(start),
>      lm.getColumnNumber(start),
>      lm.getLineNumber(end),
>      lm.getColumnNumber(end));
> }
>
>
> Output:
>
> FUNCTION 3 2 5 1
> EXPRESSION_STATEMENT 8 4 8 11
>
> PS. please check line & column w.r.t beginning of test script parsed.
> i.e., the heredoc starting point.
>
> -Sundar
>
>

From emilian.bold at gmail.com  Wed Aug  3 09:08:15 2016
From: emilian.bold at gmail.com (Emilian Bold)
Date: Wed, 3 Aug 2016 12:08:15 +0300
Subject: Tree API (JEP 236): fine grained offsets (for eg. SwitchTree)
Message-ID: <CAL6R17DTO-NFGFTtbc3dPSrG-meiG5k-5tXUztXPqcam33CEZA@mail.gmail.com>

Hello,

Since JEP 236 is designed to help with editing I believe the Tree API
should provide more offsets info about the whole statement.

For example SwitchTree covers the switch statement:

switch ( expression ) {
     cases
}

but it is impossible to determine the offsets of the curly braces or of the
round brackets.

The closing curly brace is clearly located at SwitchTree.getEndPosition.

But the first curly brace has an unknown offset somewhere between
SwitchTree.getExpression(). getEndPosition() + 1 and the getStartPosition
of the 1st CaseTree.

Obviously exact offsets are necessary to provide matching brace
highlighting or code folding for the switch expression in an editor.

Ideally SwitchTree would have contained a (Switch)BlockTree which in turn
would have contained the list of CaseTree-s.

For the round brackets, SwitchTree.getExpression() could have returned
a ParenthesizedTree instead.

PS: I wonder, would it be possible to guarantee that there is a way to
re-generate the exact input string based on the (CompilationUnit)Tree?
Because this is what seems necessary for an editor or for
minimally-invasive source-code processing tools.

--emi

From sundararajan.athijegannathan at oracle.com  Thu Aug  4 05:09:41 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 4 Aug 2016 10:39:41 +0530
Subject: Nashorn comment nodes in the syntax tree
In-Reply-To: <CAL6R17Cg6ueWp2FSukw8ijV-JkM=5S+52bMVyS--G_0zf3hE8w@mail.gmail.com>
References: <08d3c097-62fc-48bf-ded1-b8036b4715a5@oracle.com>
	<CAL6R17Cg6ueWp2FSukw8ijV-JkM=5S+52bMVyS--G_0zf3hE8w@mail.gmail.com>
Message-ID: <ccd86ca3-697a-2641-005c-c58f77307bca@oracle.com>

I checked only the jdk.nashorn.api.tree.* (parser API) classes in jdk9.
Unfortunately, we'll not be able to support fixes on
jdk.nashorn.internal.* :(

-Sundar


On 8/3/2016 1:45 PM, Emilian Bold wrote:
>
>     Also, please note that jdk.nashorn.internal.* packages are not
>     APIs and
>     therefore please avoid using those. Please use nashorn parser API
>     defined by JEP 236 [ http://openjdk.java.net/jeps/236 ]
>
>
> I cannot use JEP 236 yet because it's only part of Java 9 and it's not
> being backported to JDK 8 (why??).
>
> And I cannot use Java 9 because it hasn't been released yet.  Even if
> it would be, no company would instantly pick it up, especially with
> the big changes/breakages introduced by modules.
>
> So my only choice is to use JDK 8 with jdk.nashorn.internal.* while
> trying to keep an eye and maintain future compatibility with the JEP
> 236 Tree API.
>
>     Yes, comments are swallowed (by design). But, I initially though that
>     disturbs line & column number info. [i.e., position of various trees].
>     i.e., that was the bug you reported. That does not seem to be the
>     case.
>
>
> Could you tell me which classes produce the correct offsets in JDK 9
> compared to JDK 8?
>
> I have executed my test with Java 9 using the jdk.nashorn.internal.*
> packages and the test still fails. Actually, it seems to me with JDK 9
> functionNode.getStart() == functionNode.getFinish() so I'm not certain
> where the offsets are stored now.
>
>
>
> --emi
>
> On Fri, Jul 22, 2016 at 10:38 AM, Sundararajan Athijegannathan
> <sundararajan.athijegannathan at oracle.com
> <mailto:sundararajan.athijegannathan at oracle.com>> wrote:
>
>     Hi,
>
>     Yes, comments are swallowed (by design). But, I initially though that
>     disturbs line & column number info. [i.e., position of various trees].
>     i.e., that was the bug you reported. That does not seem to be the
>     case.
>
>     I wrote a simple sample and checked with jjs in jdk9 build. You can
>     check start and end line/column numbers of subtrees (function,
>     expression statement) are correct.
>
>     Also, please note that jdk.nashorn.internal.* packages are not
>     APIs and
>     therefore please avoid using those. Please use nashorn parser API
>     defined by JEP 236 [ http://openjdk.java.net/jeps/236 ]
>
>     #-scripting needed
>
>     var Parser = Java.type("jdk.nashorn.api.tree.Parser")
>     var p = Parser.create();
>     var cu = p.parse("t.js", <<EOF
>     /* start script comment */
>
>       function hello(){
>      return 'world';
>     }
>
>     //some comment
>         hello();
>     EOF, print);
>
>     var src = cu.sourceElements;
>     var itr = src.iterator();
>     var lm = cu.lineMap;
>     while (itr.hasNext()) {
>        var tree = itr.next();
>        var start = tree.startPosition;
>        var end = tree.endPosition;
>        print(tree.kind,
>          lm.getLineNumber(start),
>          lm.getColumnNumber(start),
>          lm.getLineNumber(end),
>          lm.getColumnNumber(end));
>     }
>
>
>     Output:
>
>     FUNCTION 3 2 5 1
>     EXPRESSION_STATEMENT 8 4 8 11
>
>     PS. please check line & column w.r.t beginning of test script parsed.
>     i.e., the heredoc starting point.
>
>     -Sundar
>
>


From sundararajan.athijegannathan at oracle.com  Thu Aug  4 05:11:47 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 4 Aug 2016 10:41:47 +0530
Subject: Tree API (JEP 236): fine grained offsets (for eg. SwitchTree)
In-Reply-To: <CAL6R17DTO-NFGFTtbc3dPSrG-meiG5k-5tXUztXPqcam33CEZA@mail.gmail.com>
References: <CAL6R17DTO-NFGFTtbc3dPSrG-meiG5k-5tXUztXPqcam33CEZA@mail.gmail.com>
Message-ID: <87f36a59-d29c-a8f1-8dbc-f9d7eafdd5f8@oracle.com>

hmm.. not sure if Abstract syntax tree Parser API should provide offsets
of "(", "}" etc.  This API is modeled after javac's tree API - I don't
think even that goes to that level of representation of the source code...

-Sundar


On 8/3/2016 2:38 PM, Emilian Bold wrote:
> Hello,
>
> Since JEP 236 is designed to help with editing I believe the Tree API
> should provide more offsets info about the whole statement.
>
> For example SwitchTree covers the switch statement:
>
> switch ( expression ) {
>      cases
> }
>
> but it is impossible to determine the offsets of the curly braces or of the
> round brackets.
>
> The closing curly brace is clearly located at SwitchTree.getEndPosition.
>
> But the first curly brace has an unknown offset somewhere between
> SwitchTree.getExpression(). getEndPosition() + 1 and the getStartPosition
> of the 1st CaseTree.
>
> Obviously exact offsets are necessary to provide matching brace
> highlighting or code folding for the switch expression in an editor.
>
> Ideally SwitchTree would have contained a (Switch)BlockTree which in turn
> would have contained the list of CaseTree-s.
>
> For the round brackets, SwitchTree.getExpression() could have returned
> a ParenthesizedTree instead.
>
> PS: I wonder, would it be possible to guarantee that there is a way to
> re-generate the exact input string based on the (CompilationUnit)Tree?
> Because this is what seems necessary for an editor or for
> minimally-invasive source-code processing tools.
>
> --emi


From hannes.wallnoefer at oracle.com  Thu Aug  4 11:48:16 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Thu, 4 Aug 2016 13:48:16 +0200
Subject: RFR: 8162955: Activate anonymous class loading for small sources
Message-ID: <DC39583D-F511-4C1E-AD3A-0D414562A3FF@oracle.com>

Please review 8162955: Activate anonymous class loading for small sources.

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

The size threshold of 512 bytes I chose is arbitrary. It seems to fit all reported cases which consist of firing lots of one-liner scripts where quick loading is more important than optimization.

Thanks,
Hannes

From sundararajan.athijegannathan at oracle.com  Thu Aug  4 12:01:13 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 4 Aug 2016 17:31:13 +0530
Subject: RFR: 8162955: Activate anonymous class loading for small sources
In-Reply-To: <DC39583D-F511-4C1E-AD3A-0D414562A3FF@oracle.com>
References: <DC39583D-F511-4C1E-AD3A-0D414562A3FF@oracle.com>
Message-ID: <d899525f-83a1-3463-00c8-75e0b4cefa86@oracle.com>

Can we add a nashorn.* System property to configure ANON_CLASS_THRESHOLD
with the default being 512?

+1

-Sundar


On 8/4/2016 5:18 PM, Hannes Walln?fer wrote:
> Please review 8162955: Activate anonymous class loading for small sources.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8162955
> Webrev: http://cr.openjdk.java.net/~hannesw/8162955/webrev/
>
> The size threshold of 512 bytes I chose is arbitrary. It seems to fit all reported cases which consist of firing lots of one-liner scripts where quick loading is more important than optimization.
>
> Thanks,
> Hannes


From joaovarandas at inpaas.com  Thu Aug  4 13:48:54 2016
From: joaovarandas at inpaas.com (=?UTF-8?Q?Jo=C3=A3o_Paulo_Varandas?=)
Date: Thu, 4 Aug 2016 10:48:54 -0300
Subject: Unexpected equality behavior (java.lang.Long)
Message-ID: <CACoP5y2Xfo91oTFkUT9G-oZs+-WHb3a9wmBcnYT+bpPqSg5CZQ@mail.gmail.com>

Hi guys!

It seems that version 1.8.0_101 has a bug in equality for same java data
types (java.lang.Long).

Check that:
jjs> new java.lang.Long(10) == new java.lang.Long(10)
false

Oops!?

See the gist:
https://gist.github.com/joaovarandas/51567bd3b576d48a4c574d60d5a60ba3

The results for all types should be ...
==    true
===   true
equals true

But for java.lang.Long and java.math.BigDecimal:
==    false
===   false
equals true

Maybe we could expand the test to other classes too, but the issue ...
- It does happen in 1.8.0_101.
- It does not 1.8.0_91.
- It does happen with other classes (BigDecimal).
- It does not happen with String.
- It does not happen with Integer.


I understand this is not an expected behavior. For now I'm rolling back
to 1.8.0_91 in my environments.



Do you me to file a bug?

Thanks
J

-- 
"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 hannes.wallnoefer at oracle.com  Thu Aug  4 14:16:43 2016
From: hannes.wallnoefer at oracle.com (=?windows-1252?Q?Hannes_Walln=F6fer?=)
Date: Thu, 4 Aug 2016 16:16:43 +0200
Subject: RFR: 8162955: Activate anonymous class loading for small sources
In-Reply-To: <d899525f-83a1-3463-00c8-75e0b4cefa86@oracle.com>
References: <DC39583D-F511-4C1E-AD3A-0D414562A3FF@oracle.com>
	<d899525f-83a1-3463-00c8-75e0b4cefa86@oracle.com>
Message-ID: <2E908D19-0CED-4144-89D3-EF3494834A3D@oracle.com>

Thanks Sundar. 

I?ve uploaded a new webrev where the threshold is settable via nashorn.anonymous.classes.threshold system property. I also added a few lines in docs/DEVELOPER_README.

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

Hannes


> Am 04.08.2016 um 14:01 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
> 
> Can we add a nashorn.* System property to configure ANON_CLASS_THRESHOLD
> with the default being 512?
> 
> +1
> 
> -Sundar
> 
> 
> On 8/4/2016 5:18 PM, Hannes Walln?fer wrote:
>> Please review 8162955: Activate anonymous class loading for small sources.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162955
>> Webrev: http://cr.openjdk.java.net/~hannesw/8162955/webrev/
>> 
>> The size threshold of 512 bytes I chose is arbitrary. It seems to fit all reported cases which consist of firing lots of one-liner scripts where quick loading is more important than optimization.
>> 
>> Thanks,
>> Hannes
> 


From sundararajan.athijegannathan at oracle.com  Thu Aug  4 14:19:56 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 4 Aug 2016 19:49:56 +0530
Subject: RFR: 8162955: Activate anonymous class loading for small sources
In-Reply-To: <2E908D19-0CED-4144-89D3-EF3494834A3D@oracle.com>
References: <DC39583D-F511-4C1E-AD3A-0D414562A3FF@oracle.com>
	<d899525f-83a1-3463-00c8-75e0b4cefa86@oracle.com>
	<2E908D19-0CED-4144-89D3-EF3494834A3D@oracle.com>
Message-ID: <eaaeb47b-8293-2d60-c8b9-b5b869a34529@oracle.com>

+1

-Sundar


On 8/4/2016 7:46 PM, Hannes Walln?fer wrote:
> Thanks Sundar. 
>
> I?ve uploaded a new webrev where the threshold is settable via nashorn.anonymous.classes.threshold system property. I also added a few lines in docs/DEVELOPER_README.
>
> http://cr.openjdk.java.net/~hannesw/8162955/webrev.01/
>
> Hannes
>
>
>> Am 04.08.2016 um 14:01 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
>>
>> Can we add a nashorn.* System property to configure ANON_CLASS_THRESHOLD
>> with the default being 512?
>>
>> +1
>>
>> -Sundar
>>
>>
>> On 8/4/2016 5:18 PM, Hannes Walln?fer wrote:
>>> Please review 8162955: Activate anonymous class loading for small sources.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162955
>>> Webrev: http://cr.openjdk.java.net/~hannesw/8162955/webrev/
>>>
>>> The size threshold of 512 bytes I chose is arbitrary. It seems to fit all reported cases which consist of firing lots of one-liner scripts where quick loading is more important than optimization.
>>>
>>> Thanks,
>>> Hannes


From tomas at tzima.cz  Thu Aug  4 23:08:58 2016
From: tomas at tzima.cz (=?UTF-8?B?VG9tw6HFoSBaw61tYQ==?=)
Date: Fri, 5 Aug 2016 01:08:58 +0200
Subject: Unexpected equality behavior (java.lang.Long)
In-Reply-To: <CACoP5y2Xfo91oTFkUT9G-oZs+-WHb3a9wmBcnYT+bpPqSg5CZQ@mail.gmail.com>
References: <CACoP5y2Xfo91oTFkUT9G-oZs+-WHb3a9wmBcnYT+bpPqSg5CZQ@mail.gmail.com>
Message-ID: <57A3CB0A.3040809@tzima.cz>

A classical beginner's mistake. You are using Java objects and comparing 
references, not the values, so this is expected behavior. Simply compare 
the objects using equals().

On 4.8.2016 15:48, Jo?o Paulo Varandas wrote:
> Hi guys!
>
> It seems that version 1.8.0_101 has a bug in equality for same java data
> types (java.lang.Long).
>
> Check that:
> jjs> new java.lang.Long(10) == new java.lang.Long(10)
> false
>
> Oops!?
>
> See the gist:
> https://gist.github.com/joaovarandas/51567bd3b576d48a4c574d60d5a60ba3
>
> The results for all types should be ...
> ==    true
> ===   true
> equals true
>
> But for java.lang.Long and java.math.BigDecimal:
> ==    false
> ===   false
> equals true
>
> Maybe we could expand the test to other classes too, but the issue ...
> - It does happen in 1.8.0_101.
> - It does not 1.8.0_91.
> - It does happen with other classes (BigDecimal).
> - It does not happen with String.
> - It does not happen with Integer.
>
>
> I understand this is not an expected behavior. For now I'm rolling back
> to 1.8.0_91 in my environments.
>
>
>
> Do you me to file a bug?
>
> Thanks
> J
>



From joaovarandas at inpaas.com  Fri Aug  5 01:43:40 2016
From: joaovarandas at inpaas.com (=?UTF-8?Q?Jo=C3=A3o_Paulo_Varandas?=)
Date: Thu, 4 Aug 2016 22:43:40 -0300
Subject: Unexpected equality behavior (java.lang.Long)
In-Reply-To: <57A3CB0A.3040809@tzima.cz>
References: <CACoP5y2Xfo91oTFkUT9G-oZs+-WHb3a9wmBcnYT+bpPqSg5CZQ@mail.gmail.com>
	<57A3CB0A.3040809@tzima.cz>
Message-ID: <CACoP5y0d7+cow7WOQT+HGv+T5moest7BbG2FRdynqHiRm+sEyA@mail.gmail.com>

Sorry Tomas.

Either you did not read the message(which would be indeed a beginner's
mistake), or you are misleading the discussion.

What you said, about equality and references would be true if we were
talking about Java code. This is jdk8-nashorn's mailing list and I'm
talking about JavaScript evaluation inside the JVM.


Comparison operators inside the script engine follow JavaScript rules and
not Java rules.














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


2016-08-04 20:08 GMT-03:00 Tom?? Z?ma <tomas at tzima.cz>:

> A classical beginner's mistake. You are using Java objects and comparing
> references, not the values, so this is expected behavior. Simply compare
> the objects using equals().
>
>
> On 4.8.2016 15:48, Jo?o Paulo Varandas wrote:
>
>> Hi guys!
>>
>> It seems that version 1.8.0_101 has a bug in equality for same java data
>> types (java.lang.Long).
>>
>> Check that:
>> jjs> new java.lang.Long(10) == new java.lang.Long(10)
>> false
>>
>> Oops!?
>>
>> See the gist:
>> https://gist.github.com/joaovarandas/51567bd3b576d48a4c574d60d5a60ba3
>>
>> The results for all types should be ...
>> ==    true
>> ===   true
>> equals true
>>
>> But for java.lang.Long and java.math.BigDecimal:
>> ==    false
>> ===   false
>> equals true
>>
>> Maybe we could expand the test to other classes too, but the issue ...
>> - It does happen in 1.8.0_101.
>> - It does not 1.8.0_91.
>> - It does happen with other classes (BigDecimal).
>> - It does not happen with String.
>> - It does not happen with Integer.
>>
>>
>> I understand this is not an expected behavior. For now I'm rolling back
>> to 1.8.0_91 in my environments.
>>
>>
>>
>> Do you me to file a bug?
>>
>> Thanks
>> J
>>
>>
>
>

-- 
"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 joaovarandas at inpaas.com  Fri Aug  5 02:40:18 2016
From: joaovarandas at inpaas.com (=?UTF-8?Q?Jo=C3=A3o_Paulo_Varandas?=)
Date: Thu, 4 Aug 2016 23:40:18 -0300
Subject: Unexpected equality behavior (java.lang.Long)
In-Reply-To: <CACoP5y0d7+cow7WOQT+HGv+T5moest7BbG2FRdynqHiRm+sEyA@mail.gmail.com>
References: <CACoP5y2Xfo91oTFkUT9G-oZs+-WHb3a9wmBcnYT+bpPqSg5CZQ@mail.gmail.com>
	<57A3CB0A.3040809@tzima.cz>
	<CACoP5y0d7+cow7WOQT+HGv+T5moest7BbG2FRdynqHiRm+sEyA@mail.gmail.com>
Message-ID: <CACoP5y1O+-14nJUK37P1RFQT45DYNkjqBzf10FORiuNTTq6eBw@mail.gmail.com>

By the way, I just found out some bugs filed about Long objects:
https://bugs.openjdk.java.net/browse/JDK-8162771
https://bugs.openjdk.java.net/browse/JDK-8161665

And a twitter discussion:
https://twitter.com/provegard/status/755010492112986112

I'd like to bring this up again if we have more room for discussion ...
--

2 Long values returned from a database and sent to a javascript evaluation
code can't be compared the way it should in JavaScript...  If I have some
validation code, I don't know if the source is some JavaScript input
(number), or the source is a database query (object/Long/Integer/Double).

It's really hard to decide when sometimes x==y should be compared as
x.equals(y) and sometimes not... and sometimes, at the same point in code I
should do a lot of conditional operations, to resolve a simple
comparison... and that comparison does not work if the data source is a
Java object or a JavaScript object.

The problem with the current solution is that comparison between different
types would never work ...

Seeing that
jjs> new java.lang.Long(2147483648) == "2147483648"
returns true

But
jjs> new java.lang.Long(2147483648) == new java.lang.Long(2147483648)
returns false

Is something really hard to accept ...
And that "equals" approach will work ONLY if I compare Long to Long. And I
see this as a regression when talking about evaluating JavaScript code.



Sorry about the long post, but I would really appreciate if we could
revalidate this and think about what the current situation represents from
ecmascript's point of view.





-08-04 22:43 GMT-03:00 Jo?o Paulo Varandas <joaovarandas at inpaas.com>:

> Sorry Tomas.
>
> Either you did not read the message(which would be indeed a beginner's
> mistake), or you are misleading the discussion.
>
> What you said, about equality and references would be true if we were
> talking about Java code. This is jdk8-nashorn's mailing list and I'm
> talking about JavaScript evaluation inside the JVM.
>
>
> Comparison operators inside the script engine follow JavaScript rules and
> not Java rules.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Jo?o Paulo Varandas*+55 11 99889-2321
> joaovarandas at inpaas.com
>
>
> 2016-08-04 20:08 GMT-03:00 Tom?? Z?ma <tomas at tzima.cz>:
>
>> A classical beginner's mistake. You are using Java objects and comparing
>> references, not the values, so this is expected behavior. Simply compare
>> the objects using equals().
>>
>>
>> On 4.8.2016 15:48, Jo?o Paulo Varandas wrote:
>>
>>> Hi guys!
>>>
>>> It seems that version 1.8.0_101 has a bug in equality for same java data
>>> types (java.lang.Long).
>>>
>>> Check that:
>>> jjs> new java.lang.Long(10) == new java.lang.Long(10)
>>> false
>>>
>>> Oops!?
>>>
>>> See the gist:
>>> https://gist.github.com/joaovarandas/51567bd3b576d48a4c574d60d5a60ba3
>>>
>>> The results for all types should be ...
>>> ==    true
>>> ===   true
>>> equals true
>>>
>>> But for java.lang.Long and java.math.BigDecimal:
>>> ==    false
>>> ===   false
>>> equals true
>>>
>>> Maybe we could expand the test to other classes too, but the issue ...
>>> - It does happen in 1.8.0_101.
>>> - It does not 1.8.0_91.
>>> - It does happen with other classes (BigDecimal).
>>> - It does not happen with String.
>>> - It does not happen with Integer.
>>>
>>>
>>> I understand this is not an expected behavior. For now I'm rolling back
>>> to 1.8.0_91 in my environments.
>>>
>>>
>>>
>>> Do you me to file a bug?
>>>
>>> Thanks
>>> J
>>>
>>>
>>
>>
>

-- 
"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 hannes.wallnoefer at oracle.com  Fri Aug  5 13:45:55 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Fri, 5 Aug 2016 15:45:55 +0200
Subject: Unexpected equality behavior (java.lang.Long)
In-Reply-To: <CACoP5y1O+-14nJUK37P1RFQT45DYNkjqBzf10FORiuNTTq6eBw@mail.gmail.com>
References: <CACoP5y2Xfo91oTFkUT9G-oZs+-WHb3a9wmBcnYT+bpPqSg5CZQ@mail.gmail.com>
	<57A3CB0A.3040809@tzima.cz>
	<CACoP5y0d7+cow7WOQT+HGv+T5moest7BbG2FRdynqHiRm+sEyA@mail.gmail.com>
	<CACoP5y1O+-14nJUK37P1RFQT45DYNkjqBzf10FORiuNTTq6eBw@mail.gmail.com>
Message-ID: <B18B7EB2-D8DA-405B-AC77-76637B4C3802@oracle.com>

Hi Joao Paulo,

thanks for the report. 

We do realize that this change caused problems for a lot of people, and we are sorry for that, and thinking how we can improve things.

I still think we were right to remove longs as internal number representation. But maybe we went to far with this, and should allow people to deal with longs as numbers, assuming they are all right with an eventual loss of presentation. 

This needs some discussion and thinking and experimentation. I?ll get back to you after the weekend.

Hannes



> Am 05.08.2016 um 04:40 schrieb Jo?o Paulo Varandas <joaovarandas at inpaas.com>:
> 
> By the way, I just found out some bugs filed about Long objects:
> https://bugs.openjdk.java.net/browse/JDK-8162771
> https://bugs.openjdk.java.net/browse/JDK-8161665
> 
> And a twitter discussion:
> https://twitter.com/provegard/status/755010492112986112
> 
> I'd like to bring this up again if we have more room for discussion ...
> --
> 
> 2 Long values returned from a database and sent to a javascript evaluation code can't be compared the way it should in JavaScript...  If I have some validation code, I don't know if the source is some JavaScript input (number), or the source is a database query (object/Long/Integer/Double).
> 
> It's really hard to decide when sometimes x==y should be compared as x.equals(y) and sometimes not... and sometimes, at the same point in code I should do a lot of conditional operations, to resolve a simple comparison... and that comparison does not work if the data source is a Java object or a JavaScript object.
> 
> The problem with the current solution is that comparison between different types would never work ...
> 
> Seeing that
> jjs> new java.lang.Long(2147483648) == "2147483648"               
> returns true
> 
> But
> jjs> new java.lang.Long(2147483648) == new java.lang.Long(2147483648)
> returns false
> 
> Is something really hard to accept ...
> And that "equals" approach will work ONLY if I compare Long to Long. And I see this as a regression when talking about evaluating JavaScript code.
> 
> 
> 
> Sorry about the long post, but I would really appreciate if we could revalidate this and think about what the current situation represents from ecmascript's point of view.
> 
> 
> 
> 
> 
> -08-04 22:43 GMT-03:00 Jo?o Paulo Varandas <joaovarandas at inpaas.com>:
> Sorry Tomas.
> 
> Either you did not read the message(which would be indeed a beginner's mistake), or you are misleading the discussion.
> 
> What you said, about equality and references would be true if we were talking about Java code. This is jdk8-nashorn's mailing list and I'm talking about JavaScript evaluation inside the JVM. 
> 
> 
> Comparison operators inside the script engine follow JavaScript rules and not Java rules.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 	Jo?o Paulo Varandas
> +55 11 99889-2321
> joaovarandas at inpaas.com
> 
> 
> 2016-08-04 20:08 GMT-03:00 Tom?? Z?ma <tomas at tzima.cz>:
> A classical beginner's mistake. You are using Java objects and comparing references, not the values, so this is expected behavior. Simply compare the objects using equals().
> 
> 
> On 4.8.2016 15:48, Jo?o Paulo Varandas wrote:
> Hi guys!
> 
> It seems that version 1.8.0_101 has a bug in equality for same java data
> types (java.lang.Long).
> 
> Check that:
> jjs> new java.lang.Long(10) == new java.lang.Long(10)
> false
> 
> Oops!?
> 
> See the gist:
> https://gist.github.com/joaovarandas/51567bd3b576d48a4c574d60d5a60ba3
> 
> The results for all types should be ...
> ==    true
> ===   true
> equals true
> 
> But for java.lang.Long and java.math.BigDecimal:
> ==    false
> ===   false
> equals true
> 
> Maybe we could expand the test to other classes too, but the issue ...
> - It does happen in 1.8.0_101.
> - It does not 1.8.0_91.
> - It does happen with other classes (BigDecimal).
> - It does not happen with String.
> - It does not happen with Integer.
> 
> 
> I understand this is not an expected behavior. For now I'm rolling back
> to 1.8.0_91 in my environments.
> 
> 
> 
> Do you me to file a bug?
> 
> Thanks
> J
> 
> 
> 
> 
> 
> 
> "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 marcus at lagergren.net  Tue Aug  9 09:24:56 2016
From: marcus at lagergren.net (Marcus Lagergren)
Date: Tue, 9 Aug 2016 11:24:56 +0200
Subject: RFR: 8162955: Activate anonymous class loading for small sources
In-Reply-To: <DC39583D-F511-4C1E-AD3A-0D414562A3FF@oracle.com>
References: <DC39583D-F511-4C1E-AD3A-0D414562A3FF@oracle.com>
Message-ID: <9878FE30-E33E-45EA-A334-19C05D304EC1@lagergren.net>

Do you have any benchmark examples with better and worse results?

Just curious

/M

> On 04 Aug 2016, at 13:48, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
> 
> Please review 8162955: Activate anonymous class loading for small sources.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8162955
> Webrev: http://cr.openjdk.java.net/~hannesw/8162955/webrev/
> 
> The size threshold of 512 bytes I chose is arbitrary. It seems to fit all reported cases which consist of firing lots of one-liner scripts where quick loading is more important than optimization.
> 
> Thanks,
> Hannes


From hannes.wallnoefer at oracle.com  Tue Aug  9 10:10:03 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Tue, 9 Aug 2016 12:10:03 +0200
Subject: RFR: 8162955: Activate anonymous class loading for small sources
In-Reply-To: <9878FE30-E33E-45EA-A334-19C05D304EC1@lagergren.net>
References: <DC39583D-F511-4C1E-AD3A-0D414562A3FF@oracle.com>
	<9878FE30-E33E-45EA-A334-19C05D304EC1@lagergren.net>
Message-ID: <7BCF824F-EFBE-49A4-BA64-2ADFC2195C30@oracle.com>

It?s pretty drastic, and has gotten more pronounced in recent JDK 9 builds. Running test programs from the issues linked in the Jira description there?s somewhere between 30% and 100% speedup from using anonymous classes. 

Note that the intention has always been to use anonymous classes for short scripts, we just didn?t realize many users compile one-liners using the Java API.

Hannes


> Am 09.08.2016 um 11:24 schrieb Marcus Lagergren <marcus at lagergren.net>:
> 
> Do you have any benchmark examples with better and worse results?
> 
> Just curious
> 
> /M
> 
>> On 04 Aug 2016, at 13:48, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
>> 
>> Please review 8162955: Activate anonymous class loading for small sources.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162955
>> Webrev: http://cr.openjdk.java.net/~hannesw/8162955/webrev/
>> 
>> The size threshold of 512 bytes I chose is arbitrary. It seems to fit all reported cases which consist of firing lots of one-liner scripts where quick loading is more important than optimization.
>> 
>> Thanks,
>> Hannes
> 


From srinivas.dama at oracle.com  Wed Aug 10 09:10:23 2016
From: srinivas.dama at oracle.com (Srinivas Dama)
Date: Wed, 10 Aug 2016 02:10:23 -0700 (PDT)
Subject: RFR: 8134304: NPE in initialization of OptimisticTypesPersistence
Message-ID: <3ce43235-506d-481e-bf4d-87c952130007@default>

Hi,

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

Regards,
Srinivas

From srinivas.dama at oracle.com  Wed Aug 10 13:30:02 2016
From: srinivas.dama at oracle.com (Srinivas Dama)
Date: Wed, 10 Aug 2016 06:30:02 -0700 (PDT)
Subject: RFR: 8134304: NPE in initialization of OptimisticTypesPersistence
In-Reply-To: <3ce43235-506d-481e-bf4d-87c952130007@default>
References: <3ce43235-506d-481e-bf4d-87c952130007@default>
Message-ID: <716ebc5a-eb3b-44a8-84c3-d42a94bb3783@default>

Hi,

Please review http://cr.openjdk.java.net/~sdama/8134304/webrev.01/ 
for https://bugs.openjdk.java.net/browse/JDK-8134304 

Localized fix only to OptimisticTypesPersistence.java.

Regards,
Srinivas

-----Original Message-----
From: Srinivas Dama 
Sent: Wednesday, August 10, 2016 2:40 PM
To: Nashorn-dev
Subject: RFR: 8134304: NPE in initialization of OptimisticTypesPersistence

Hi,

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

Regards,
Srinivas

From hannes.wallnoefer at oracle.com  Wed Aug 10 13:59:58 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Wed, 10 Aug 2016 15:59:58 +0200
Subject: RFR: 8134304: NPE in initialization of OptimisticTypesPersistence
In-Reply-To: <716ebc5a-eb3b-44a8-84c3-d42a94bb3783@default>
References: <3ce43235-506d-481e-bf4d-87c952130007@default>
	<716ebc5a-eb3b-44a8-84c3-d42a94bb3783@default>
Message-ID: <6757080D-5C6F-4E14-B23A-924F5AF71267@oracle.com>

Looks good.

Hannes

> Am 10.08.2016 um 15:30 schrieb Srinivas Dama <srinivas.dama at oracle.com>:
> 
> Hi,
> 
> Please review http://cr.openjdk.java.net/~sdama/8134304/webrev.01/ 
> for https://bugs.openjdk.java.net/browse/JDK-8134304 
> 
> Localized fix only to OptimisticTypesPersistence.java.
> 
> Regards,
> Srinivas
> 
> -----Original Message-----
> From: Srinivas Dama 
> Sent: Wednesday, August 10, 2016 2:40 PM
> To: Nashorn-dev
> Subject: RFR: 8134304: NPE in initialization of OptimisticTypesPersistence
> 
> Hi,
> 
> Please review http://cr.openjdk.java.net/~sdama/8134304/webrev.00/ 
> for https://bugs.openjdk.java.net/browse/JDK-8134304 
> 
> Regards,
> Srinivas


From james.laskey at oracle.com  Wed Aug 10 14:01:30 2016
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Wed, 10 Aug 2016 11:01:30 -0300
Subject: RFR: 8134304: NPE in initialization of OptimisticTypesPersistence
In-Reply-To: <716ebc5a-eb3b-44a8-84c3-d42a94bb3783@default>
References: <3ce43235-506d-481e-bf4d-87c952130007@default>
	<716ebc5a-eb3b-44a8-84c3-d42a94bb3783@default>
Message-ID: <E22D79F4-358D-44C7-8998-E98D02A1C4AF@oracle.com>

+1

> On Aug 10, 2016, at 10:30 AM, Srinivas Dama <srinivas.dama at oracle.com> wrote:
> 
> Hi,
> 
> Please review http://cr.openjdk.java.net/~sdama/8134304/webrev.01/ 
> for https://bugs.openjdk.java.net/browse/JDK-8134304 
> 
> Localized fix only to OptimisticTypesPersistence.java.
> 
> Regards,
> Srinivas
> 
> -----Original Message-----
> From: Srinivas Dama 
> Sent: Wednesday, August 10, 2016 2:40 PM
> To: Nashorn-dev
> Subject: RFR: 8134304: NPE in initialization of OptimisticTypesPersistence
> 
> Hi,
> 
> Please review http://cr.openjdk.java.net/~sdama/8134304/webrev.00/ 
> for https://bugs.openjdk.java.net/browse/JDK-8134304 
> 
> Regards,
> Srinivas


From michael.haupt at oracle.com  Wed Aug 10 15:28:34 2016
From: michael.haupt at oracle.com (Michael Haupt)
Date: Wed, 10 Aug 2016 08:28:34 -0700
Subject: RFR: 8134304: NPE in initialization of OptimisticTypesPersistence
In-Reply-To: <716ebc5a-eb3b-44a8-84c3-d42a94bb3783@default>
References: <3ce43235-506d-481e-bf4d-87c952130007@default>
	<716ebc5a-eb3b-44a8-84c3-d42a94bb3783@default>
Message-ID: <7703D885-E7B1-4374-B3A2-023F6E2D169E@oracle.com>

Hi Srini,

thumbs up, and I'll be happy to sponsor the push.

Best,

Michael

> Am 10.08.2016 um 06:30 schrieb Srinivas Dama <srinivas.dama at oracle.com>:
> 
> Hi,
> 
> Please review http://cr.openjdk.java.net/~sdama/8134304/webrev.01/ 
> for https://bugs.openjdk.java.net/browse/JDK-8134304 
> 
> Localized fix only to OptimisticTypesPersistence.java.
> 
> Regards,
> Srinivas
> 
> -----Original Message-----
> From: Srinivas Dama 
> Sent: Wednesday, August 10, 2016 2:40 PM
> To: Nashorn-dev
> Subject: RFR: 8134304: NPE in initialization of OptimisticTypesPersistence
> 
> Hi,
> 
> Please review http://cr.openjdk.java.net/~sdama/8134304/webrev.00/ 
> for https://bugs.openjdk.java.net/browse/JDK-8134304 
> 
> Regards,
> Srinivas

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment


From marcus at lagergren.net  Sat Aug 13 18:23:05 2016
From: marcus at lagergren.net (Marcus Lagergren)
Date: Sat, 13 Aug 2016 20:23:05 +0200
Subject: RFR: 8162955: Activate anonymous class loading for small sources
In-Reply-To: <7BCF824F-EFBE-49A4-BA64-2ADFC2195C30@oracle.com>
References: <DC39583D-F511-4C1E-AD3A-0D414562A3FF@oracle.com>
	<9878FE30-E33E-45EA-A334-19C05D304EC1@lagergren.net>
	<7BCF824F-EFBE-49A4-BA64-2ADFC2195C30@oracle.com>
Message-ID: <53AF0878-662A-4357-AEF0-46058C304FC0@lagergren.net>

Interesting
+1

Is it possible to make this a flag with default ?on", and check in a microbenchmark that proves this?

Does this affect runtime performance, i.e. program execution speed, in any way that you can measure?

Regards
Marcus

> On 09 Aug 2016, at 12:10, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
> 
> It?s pretty drastic, and has gotten more pronounced in recent JDK 9 builds. Running test programs from the issues linked in the Jira description there?s somewhere between 30% and 100% speedup from using anonymous classes.
> 
> Note that the intention has always been to use anonymous classes for short scripts, we just didn?t realize many users compile one-liners using the Java API.
> 
> Hannes
> 
> 
>> Am 09.08.2016 um 11:24 schrieb Marcus Lagergren <marcus at lagergren.net>:
>> 
>> Do you have any benchmark examples with better and worse results?
>> 
>> Just curious
>> 
>> /M
>> 
>>> On 04 Aug 2016, at 13:48, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
>>> 
>>> Please review 8162955: Activate anonymous class loading for small sources.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162955
>>> Webrev: http://cr.openjdk.java.net/~hannesw/8162955/webrev/
>>> 
>>> The size threshold of 512 bytes I chose is arbitrary. It seems to fit all reported cases which consist of firing lots of one-liner scripts where quick loading is more important than optimization.
>>> 
>>> Thanks,
>>> Hannes
>> 
> 


From hannes.wallnoefer at oracle.com  Tue Aug 16 09:23:41 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Tue, 16 Aug 2016 11:23:41 +0200
Subject: Unexpected equality behavior (java.lang.Long)
In-Reply-To: <B18B7EB2-D8DA-405B-AC77-76637B4C3802@oracle.com>
References: <CACoP5y2Xfo91oTFkUT9G-oZs+-WHb3a9wmBcnYT+bpPqSg5CZQ@mail.gmail.com>
	<57A3CB0A.3040809@tzima.cz>
	<CACoP5y0d7+cow7WOQT+HGv+T5moest7BbG2FRdynqHiRm+sEyA@mail.gmail.com>
	<CACoP5y1O+-14nJUK37P1RFQT45DYNkjqBzf10FORiuNTTq6eBw@mail.gmail.com>
	<B18B7EB2-D8DA-405B-AC77-76637B4C3802@oracle.com>
Message-ID: <563909A9-709B-4BF5-BCF2-038599AFB022@oracle.com>

After exploring various options I don?t think there?s anything we can do to go back and treat longs like numbers in Nashorn. 

The ECMA spec is quite clear that there are numbers and object, and comparison of the latter is by reference, not value. So having some kind of in-between states is not really an option. Making longs numbers again would be quite a small and harmless change within the language (without reverting to longs as internal data type). Precision would be lowered to doubles for large longs, but that wouldn?t be a problem for most users.

However, the problems starts where longs as numbers inherit from Number.prototype. Of course, all methods in Number.prototype are specified for double values, and the toString methods collides with toString in java.lang.Long. Having a toString method that rounds large longs to the nearest double value is a no-go. Nor is extending all methods in Number.prototype to handle longs are viable options.

There is one issue we need to fix to improve handling of longs and other instances of java.lang.Number though (thanks to Attila for first pointing this out): Currently, java.lang.Numbers not treated as numbers in the ToPrimitive operation with Number hint. This means less-than/greater-than operators will treat those number objects as strings instead of converting to double. I filed a bug for this, and will back port it to JDK 8u:

https://bugs.openjdk.java.net/browse/JDK-8163945

All things considered, there are some things that make me think the situation is not as bad as some seem to believe. For one, the new treatment of Longs (with the fix for the bug above) is consistent with how JavaScript Number objects/wrappers are treated. Comparing two Number wrappers for the same value will also evaluate to false with both == and === operators, while comparing them to the primitive number with == will evaluate to true.

new Number(1) == new Number(1) // false
new Number(1) === new Number(1) // false
new Number(1) == 1 // true
new Number(1) === 1 // false

So Longs are just like JS Number wrappers. They are object wrappers for numeric values. If needed they can easily converted to primitive numbers by calling the global Number() function without ?new? keyword, eg:

if (typeof x === ?object?) 
    x = Number(x);

This is a common pattern in JavaScript even without Java longs, so I think it?s acceptable.

Hannes 


> Am 05.08.2016 um 15:45 schrieb Hannes Walln?fer <hannes.wallnoefer at oracle.com>:
> 
> Hi Joao Paulo,
> 
> thanks for the report. 
> 
> We do realize that this change caused problems for a lot of people, and we are sorry for that, and thinking how we can improve things.
> 
> I still think we were right to remove longs as internal number representation. But maybe we went to far with this, and should allow people to deal with longs as numbers, assuming they are all right with an eventual loss of presentation. 
> 
> This needs some discussion and thinking and experimentation. I?ll get back to you after the weekend.
> 
> Hannes
> 
> 
> 
>> Am 05.08.2016 um 04:40 schrieb Jo?o Paulo Varandas <joaovarandas at inpaas.com>:
>> 
>> By the way, I just found out some bugs filed about Long objects:
>> https://bugs.openjdk.java.net/browse/JDK-8162771
>> https://bugs.openjdk.java.net/browse/JDK-8161665
>> 
>> And a twitter discussion:
>> https://twitter.com/provegard/status/755010492112986112
>> 
>> I'd like to bring this up again if we have more room for discussion ...
>> --
>> 
>> 2 Long values returned from a database and sent to a javascript evaluation code can't be compared the way it should in JavaScript...  If I have some validation code, I don't know if the source is some JavaScript input (number), or the source is a database query (object/Long/Integer/Double).
>> 
>> It's really hard to decide when sometimes x==y should be compared as x.equals(y) and sometimes not... and sometimes, at the same point in code I should do a lot of conditional operations, to resolve a simple comparison... and that comparison does not work if the data source is a Java object or a JavaScript object.
>> 
>> The problem with the current solution is that comparison between different types would never work ...
>> 
>> Seeing that
>> jjs> new java.lang.Long(2147483648) == "2147483648"               
>> returns true
>> 
>> But
>> jjs> new java.lang.Long(2147483648) == new java.lang.Long(2147483648)
>> returns false
>> 
>> Is something really hard to accept ...
>> And that "equals" approach will work ONLY if I compare Long to Long. And I see this as a regression when talking about evaluating JavaScript code.
>> 
>> 
>> 
>> Sorry about the long post, but I would really appreciate if we could revalidate this and think about what the current situation represents from ecmascript's point of view.
>> 
>> 
>> 
>> 
>> 
>> -08-04 22:43 GMT-03:00 Jo?o Paulo Varandas <joaovarandas at inpaas.com>:
>> Sorry Tomas.
>> 
>> Either you did not read the message(which would be indeed a beginner's mistake), or you are misleading the discussion.
>> 
>> What you said, about equality and references would be true if we were talking about Java code. This is jdk8-nashorn's mailing list and I'm talking about JavaScript evaluation inside the JVM. 
>> 
>> 
>> Comparison operators inside the script engine follow JavaScript rules and not Java rules.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 	Jo?o Paulo Varandas
>> +55 11 99889-2321
>> joaovarandas at inpaas.com
>> 
>> 
>> 2016-08-04 20:08 GMT-03:00 Tom?? Z?ma <tomas at tzima.cz>:
>> A classical beginner's mistake. You are using Java objects and comparing references, not the values, so this is expected behavior. Simply compare the objects using equals().
>> 
>> 
>> On 4.8.2016 15:48, Jo?o Paulo Varandas wrote:
>> Hi guys!
>> 
>> It seems that version 1.8.0_101 has a bug in equality for same java data
>> types (java.lang.Long).
>> 
>> Check that:
>> jjs> new java.lang.Long(10) == new java.lang.Long(10)
>> false
>> 
>> Oops!?
>> 
>> See the gist:
>> https://gist.github.com/joaovarandas/51567bd3b576d48a4c574d60d5a60ba3
>> 
>> The results for all types should be ...
>> ==    true
>> ===   true
>> equals true
>> 
>> But for java.lang.Long and java.math.BigDecimal:
>> ==    false
>> ===   false
>> equals true
>> 
>> Maybe we could expand the test to other classes too, but the issue ...
>> - It does happen in 1.8.0_101.
>> - It does not 1.8.0_91.
>> - It does happen with other classes (BigDecimal).
>> - It does not happen with String.
>> - It does not happen with Integer.
>> 
>> 
>> I understand this is not an expected behavior. For now I'm rolling back
>> to 1.8.0_91 in my environments.
>> 
>> 
>> 
>> Do you me to file a bug?
>> 
>> Thanks
>> J
>> 
>> 
>> 
>> 
>> 
>> 
>> "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 hannes.wallnoefer at oracle.com  Tue Aug 16 12:51:14 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Tue, 16 Aug 2016 14:51:14 +0200
Subject: RFR: 8163945: Honor Number type hint in toPrimitive on Numbers
Message-ID: <F26C111D-64A7-4272-901A-21246B0F9869@oracle.com>

Please review 8163945: Honor Number type hint in toPrimitive on Numbers:

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

Thanks,
Hannes

From michael.haupt at oracle.com  Tue Aug 16 12:55:30 2016
From: michael.haupt at oracle.com (Michael Haupt)
Date: Tue, 16 Aug 2016 14:55:30 +0200
Subject: RFR: 8163945: Honor Number type hint in toPrimitive on Numbers
In-Reply-To: <F26C111D-64A7-4272-901A-21246B0F9869@oracle.com>
References: <F26C111D-64A7-4272-901A-21246B0F9869@oracle.com>
Message-ID: <18005737-34C5-4B34-8B58-163C419A90EF@oracle.com>

Hi Hannes,

thumbs up.

Best,

Michael

> Am 16.08.2016 um 14:51 schrieb Hannes Walln?fer <hannes.wallnoefer at oracle.com>:
> 
> Please review 8163945: Honor Number type hint in toPrimitive on Numbers:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8163945
> Webrev: http://cr.openjdk.java.net/~hannesw/8163945/
> 
> Thanks,
> Hannes

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment


From james.laskey at oracle.com  Tue Aug 16 12:55:42 2016
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Tue, 16 Aug 2016 09:55:42 -0300
Subject: RFR: 8163945: Honor Number type hint in toPrimitive on Numbers
In-Reply-To: <F26C111D-64A7-4272-901A-21246B0F9869@oracle.com>
References: <F26C111D-64A7-4272-901A-21246B0F9869@oracle.com>
Message-ID: <EA6DBC19-158C-45E2-BD93-2C0F299B98F0@oracle.com>

+1

> On Aug 16, 2016, at 9:51 AM, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
> 
> Please review 8163945: Honor Number type hint in toPrimitive on Numbers:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8163945
> Webrev: http://cr.openjdk.java.net/~hannesw/8163945/
> 
> Thanks,
> Hannes


From szegedia at gmail.com  Tue Aug 16 13:13:43 2016
From: szegedia at gmail.com (Attila Szegedi)
Date: Tue, 16 Aug 2016 15:13:43 +0200
Subject: RFR: 8163945: Honor Number type hint in toPrimitive on Numbers
In-Reply-To: <F26C111D-64A7-4272-901A-21246B0F9869@oracle.com>
References: <F26C111D-64A7-4272-901A-21246B0F9869@oracle.com>
Message-ID: <3A67C801-C36E-412F-80D2-EF356158192C@gmail.com>

+1

> On 16 Aug 2016, at 14:51, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
> 
> Please review 8163945: Honor Number type hint in toPrimitive on Numbers:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8163945
> Webrev: http://cr.openjdk.java.net/~hannesw/8163945/
> 
> Thanks,
> Hannes


From joaovarandas at inpaas.com  Tue Aug 16 14:16:42 2016
From: joaovarandas at inpaas.com (=?UTF-8?Q?Jo=C3=A3o_Paulo_Varandas?=)
Date: Tue, 16 Aug 2016 11:16:42 -0300
Subject: Unexpected equality behavior (java.lang.Long)
In-Reply-To: <563909A9-709B-4BF5-BCF2-038599AFB022@oracle.com>
References: <CACoP5y2Xfo91oTFkUT9G-oZs+-WHb3a9wmBcnYT+bpPqSg5CZQ@mail.gmail.com>
	<57A3CB0A.3040809@tzima.cz>
	<CACoP5y0d7+cow7WOQT+HGv+T5moest7BbG2FRdynqHiRm+sEyA@mail.gmail.com>
	<CACoP5y1O+-14nJUK37P1RFQT45DYNkjqBzf10FORiuNTTq6eBw@mail.gmail.com>
	<B18B7EB2-D8DA-405B-AC77-76637B4C3802@oracle.com>
	<563909A9-709B-4BF5-BCF2-038599AFB022@oracle.com>
Message-ID: <CACoP5y0WGRGti_XuVa71+WgOQZEzUqWfsr_BP64oZiFPW6QM2A@mail.gmail.com>

Hi Hannes.

Thanks for reviewing this. Seeing it from this perspective:

Longs are just like JS Number wrappers.


Made me believe the situation was not that bad too. Telling developers to
'unwrap' numbers using " x = Number(x); " would not be a bad idea.

With that in mind, any number comparison would have to be made unwrapping
data first ... But, we would also need to test nulls first, because:

While "null == 0" yields false, and obviusly "null === 0" yields false.
Number(null) === Number(0) would yield true.

Thus, we would need:

function unwrapNumber(x) {
   return x == null ? null : Number(x);
}

And also, to tell developers to call unwrapNumber() everytime they need to
compare a Number ...

I don't know if you agree with me, but now I see this as an anti-pattern.


---

Anyway... It seems that all the fuzz is because of that "bug" with Long
numbers and double. And I'm sorry that I did not look further into that
issue.

Maybe we should look further into that, and try to make that any number
below Number.MAX_SAFE_INTEGER (9007199254740991), work the way is expected
inside JS evaluations ...










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


2016-08-16 6:23 GMT-03:00 Hannes Walln?fer <hannes.wallnoefer at oracle.com>:

> After exploring various options I don?t think there?s anything we can do
> to go back and treat longs like numbers in Nashorn.
>
> The ECMA spec is quite clear that there are numbers and object, and
> comparison of the latter is by reference, not value. So having some kind of
> in-between states is not really an option. Making longs numbers again would
> be quite a small and harmless change within the language (without reverting
> to longs as internal data type). Precision would be lowered to doubles for
> large longs, but that wouldn?t be a problem for most users.
>
> However, the problems starts where longs as numbers inherit from
> Number.prototype. Of course, all methods in Number.prototype are specified
> for double values, and the toString methods collides with toString in
> java.lang.Long. Having a toString method that rounds large longs to the
> nearest double value is a no-go. Nor is extending all methods in
> Number.prototype to handle longs are viable options.
>
> There is one issue we need to fix to improve handling of longs and other
> instances of java.lang.Number though (thanks to Attila for first pointing
> this out): Currently, java.lang.Numbers not treated as numbers in the
> ToPrimitive operation with Number hint. This means less-than/greater-than
> operators will treat those number objects as strings instead of converting
> to double. I filed a bug for this, and will back port it to JDK 8u:
>
> https://bugs.openjdk.java.net/browse/JDK-8163945
>
> All things considered, there are some things that make me think the
> situation is not as bad as some seem to believe. For one, the new treatment
> of Longs (with the fix for the bug above) is consistent with how JavaScript
> Number objects/wrappers are treated. Comparing two Number wrappers for the
> same value will also evaluate to false with both == and === operators,
> while comparing them to the primitive number with == will evaluate to true.
>
> new Number(1) == new Number(1) // false
> new Number(1) === new Number(1) // false
> new Number(1) == 1 // true
> new Number(1) === 1 // false
>
> So Longs are just like JS Number wrappers. They are object wrappers for
> numeric values. If needed they can easily converted to primitive numbers by
> calling the global Number() function without ?new? keyword, eg:
>
> if (typeof x === ?object?)
>     x = Number(x);
>
> This is a common pattern in JavaScript even without Java longs, so I think
> it?s acceptable.
>
> Hannes
>
>
> > Am 05.08.2016 um 15:45 schrieb Hannes Walln?fer <
> hannes.wallnoefer at oracle.com>:
> >
> > Hi Joao Paulo,
> >
> > thanks for the report.
> >
> > We do realize that this change caused problems for a lot of people, and
> we are sorry for that, and thinking how we can improve things.
> >
> > I still think we were right to remove longs as internal number
> representation. But maybe we went to far with this, and should allow people
> to deal with longs as numbers, assuming they are all right with an eventual
> loss of presentation.
> >
> > This needs some discussion and thinking and experimentation. I?ll get
> back to you after the weekend.
> >
> > Hannes
> >
> >
> >
> >> Am 05.08.2016 um 04:40 schrieb Jo?o Paulo Varandas <
> joaovarandas at inpaas.com>:
> >>
> >> By the way, I just found out some bugs filed about Long objects:
> >> https://bugs.openjdk.java.net/browse/JDK-8162771
> >> https://bugs.openjdk.java.net/browse/JDK-8161665
> >>
> >> And a twitter discussion:
> >> https://twitter.com/provegard/status/755010492112986112
> >>
> >> I'd like to bring this up again if we have more room for discussion ...
> >> --
> >>
> >> 2 Long values returned from a database and sent to a javascript
> evaluation code can't be compared the way it should in JavaScript...  If I
> have some validation code, I don't know if the source is some JavaScript
> input (number), or the source is a database query
> (object/Long/Integer/Double).
> >>
> >> It's really hard to decide when sometimes x==y should be compared as
> x.equals(y) and sometimes not... and sometimes, at the same point in code I
> should do a lot of conditional operations, to resolve a simple
> comparison... and that comparison does not work if the data source is a
> Java object or a JavaScript object.
> >>
> >> The problem with the current solution is that comparison between
> different types would never work ...
> >>
> >> Seeing that
> >> jjs> new java.lang.Long(2147483648) == "2147483648"
> >> returns true
> >>
> >> But
> >> jjs> new java.lang.Long(2147483648) == new java.lang.Long(2147483648)
> >> returns false
> >>
> >> Is something really hard to accept ...
> >> And that "equals" approach will work ONLY if I compare Long to Long.
> And I see this as a regression when talking about evaluating JavaScript
> code.
> >>
> >>
> >>
> >> Sorry about the long post, but I would really appreciate if we could
> revalidate this and think about what the current situation represents from
> ecmascript's point of view.
> >>
> >>
> >>
> >>
> >>
> >> -08-04 22:43 GMT-03:00 Jo?o Paulo Varandas <joaovarandas at inpaas.com>:
> >> Sorry Tomas.
> >>
> >> Either you did not read the message(which would be indeed a beginner's
> mistake), or you are misleading the discussion.
> >>
> >> What you said, about equality and references would be true if we were
> talking about Java code. This is jdk8-nashorn's mailing list and I'm
> talking about JavaScript evaluation inside the JVM.
> >>
> >>
> >> Comparison operators inside the script engine follow JavaScript rules
> and not Java rules.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>      Jo?o Paulo Varandas
> >> +55 11 99889-2321
> >> joaovarandas at inpaas.com
> >>
> >>
> >> 2016-08-04 20:08 GMT-03:00 Tom?? Z?ma <tomas at tzima.cz>:
> >> A classical beginner's mistake. You are using Java objects and
> comparing references, not the values, so this is expected behavior. Simply
> compare the objects using equals().
> >>
> >>
> >> On 4.8.2016 15:48, Jo?o Paulo Varandas wrote:
> >> Hi guys!
> >>
> >> It seems that version 1.8.0_101 has a bug in equality for same java data
> >> types (java.lang.Long).
> >>
> >> Check that:
> >> jjs> new java.lang.Long(10) == new java.lang.Long(10)
> >> false
> >>
> >> Oops!?
> >>
> >> See the gist:
> >> https://gist.github.com/joaovarandas/51567bd3b576d48a4c574d60d5a60ba3
> >>
> >> The results for all types should be ...
> >> ==    true
> >> ===   true
> >> equals true
> >>
> >> But for java.lang.Long and java.math.BigDecimal:
> >> ==    false
> >> ===   false
> >> equals true
> >>
> >> Maybe we could expand the test to other classes too, but the issue ...
> >> - It does happen in 1.8.0_101.
> >> - It does not 1.8.0_91.
> >> - It does happen with other classes (BigDecimal).
> >> - It does not happen with String.
> >> - It does not happen with Integer.
> >>
> >>
> >> I understand this is not an expected behavior. For now I'm rolling back
> >> to 1.8.0_91 in my environments.
> >>
> >>
> >>
> >> Do you me to file a bug?
> >>
> >> Thanks
> >> J
> >>
> >>
> >>
> >>
> >>
> >>
> >> "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"
> >
>
>

-- 
"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 hannes.wallnoefer at oracle.com  Wed Aug 17 05:36:37 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Wed, 17 Aug 2016 07:36:37 +0200
Subject: RFR: 8163945: Honor Number type hint in toPrimitive on Numbers
In-Reply-To: <3A67C801-C36E-412F-80D2-EF356158192C@gmail.com>
References: <F26C111D-64A7-4272-901A-21246B0F9869@oracle.com>
	<3A67C801-C36E-412F-80D2-EF356158192C@gmail.com>
Message-ID: <75451FBA-0C90-4473-A262-0F8858049760@oracle.com>

Thanks Attila for making me aware of this and suggesting this solution.


> Am 16.08.2016 um 15:13 schrieb Attila Szegedi <szegedia at gmail.com>:
> 
> +1
> 
>> On 16 Aug 2016, at 14:51, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
>> 
>> Please review 8163945: Honor Number type hint in toPrimitive on Numbers:
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163945
>> Webrev: http://cr.openjdk.java.net/~hannesw/8163945/
>> 
>> Thanks,
>> Hannes
> 


From hannes.wallnoefer at oracle.com  Wed Aug 17 05:56:22 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Wed, 17 Aug 2016 07:56:22 +0200
Subject: Unexpected equality behavior (java.lang.Long)
In-Reply-To: <CACoP5y0WGRGti_XuVa71+WgOQZEzUqWfsr_BP64oZiFPW6QM2A@mail.gmail.com>
References: <CACoP5y2Xfo91oTFkUT9G-oZs+-WHb3a9wmBcnYT+bpPqSg5CZQ@mail.gmail.com>
	<57A3CB0A.3040809@tzima.cz>
	<CACoP5y0d7+cow7WOQT+HGv+T5moest7BbG2FRdynqHiRm+sEyA@mail.gmail.com>
	<CACoP5y1O+-14nJUK37P1RFQT45DYNkjqBzf10FORiuNTTq6eBw@mail.gmail.com>
	<B18B7EB2-D8DA-405B-AC77-76637B4C3802@oracle.com>
	<563909A9-709B-4BF5-BCF2-038599AFB022@oracle.com>
	<CACoP5y0WGRGti_XuVa71+WgOQZEzUqWfsr_BP64oZiFPW6QM2A@mail.gmail.com>
Message-ID: <2B6D3495-DD97-4E6E-BC7D-9FFEB7DF9045@oracle.com>

It?s unfortunate JS considers null to be of type ?object?. I think that in most practical circumstances and definitely when a number comes from a Java primitive you can omit the null check as Java primitives can?t be null, though.

Hannes


> Am 16.08.2016 um 16:16 schrieb Jo?o Paulo Varandas <joaovarandas at inpaas.com>:
> 
> Hi Hannes.
> 
> Thanks for reviewing this. Seeing it from this perspective:
> 
> Longs are just like JS Number wrappers.
> 
> Made me believe the situation was not that bad too. Telling developers to 'unwrap' numbers using " x = Number(x); " would not be a bad idea.
> 
> With that in mind, any number comparison would have to be made unwrapping data first ... But, we would also need to test nulls first, because:
> 
> While "null == 0" yields false, and obviusly "null === 0" yields false.
> Number(null) === Number(0) would yield true.
> 
> Thus, we would need:
> 
> function unwrapNumber(x) {
>    return x == null ? null : Number(x);
> }
> 
> And also, to tell developers to call unwrapNumber() everytime they need to compare a Number ... 
> 
> I don't know if you agree with me, but now I see this as an anti-pattern.
> 
> 
> ---
> 
> Anyway... It seems that all the fuzz is because of that "bug" with Long numbers and double. And I'm sorry that I did not look further into that issue.
> 
> Maybe we should look further into that, and try to make that any number below Number.MAX_SAFE_INTEGER (9007199254740991), work the way is expected inside JS evaluations ... 
> 
> 
> 
> 
> 
> 
>  
>  
> 
> 	Jo?o Paulo Varandas
> +55 11 99889-2321
> joaovarandas at inpaas.com
> 
> 
> 2016-08-16 6:23 GMT-03:00 Hannes Walln?fer <hannes.wallnoefer at oracle.com>:
> After exploring various options I don?t think there?s anything we can do to go back and treat longs like numbers in Nashorn.
> 
> The ECMA spec is quite clear that there are numbers and object, and comparison of the latter is by reference, not value. So having some kind of in-between states is not really an option. Making longs numbers again would be quite a small and harmless change within the language (without reverting to longs as internal data type). Precision would be lowered to doubles for large longs, but that wouldn?t be a problem for most users.
> 
> However, the problems starts where longs as numbers inherit from Number.prototype. Of course, all methods in Number.prototype are specified for double values, and the toString methods collides with toString in java.lang.Long. Having a toString method that rounds large longs to the nearest double value is a no-go. Nor is extending all methods in Number.prototype to handle longs are viable options.
> 
> There is one issue we need to fix to improve handling of longs and other instances of java.lang.Number though (thanks to Attila for first pointing this out): Currently, java.lang.Numbers not treated as numbers in the ToPrimitive operation with Number hint. This means less-than/greater-than operators will treat those number objects as strings instead of converting to double. I filed a bug for this, and will back port it to JDK 8u:
> 
> https://bugs.openjdk.java.net/browse/JDK-8163945
> 
> All things considered, there are some things that make me think the situation is not as bad as some seem to believe. For one, the new treatment of Longs (with the fix for the bug above) is consistent with how JavaScript Number objects/wrappers are treated. Comparing two Number wrappers for the same value will also evaluate to false with both == and === operators, while comparing them to the primitive number with == will evaluate to true.
> 
> new Number(1) == new Number(1) // false
> new Number(1) === new Number(1) // false
> new Number(1) == 1 // true
> new Number(1) === 1 // false
> 
> So Longs are just like JS Number wrappers. They are object wrappers for numeric values. If needed they can easily converted to primitive numbers by calling the global Number() function without ?new? keyword, eg:
> 
> if (typeof x === ?object?)
>     x = Number(x);
> 
> This is a common pattern in JavaScript even without Java longs, so I think it?s acceptable.
> 
> Hannes
> 
> 
> > Am 05.08.2016 um 15:45 schrieb Hannes Walln?fer <hannes.wallnoefer at oracle.com>:
> >
> > Hi Joao Paulo,
> >
> > thanks for the report.
> >
> > We do realize that this change caused problems for a lot of people, and we are sorry for that, and thinking how we can improve things.
> >
> > I still think we were right to remove longs as internal number representation. But maybe we went to far with this, and should allow people to deal with longs as numbers, assuming they are all right with an eventual loss of presentation.
> >
> > This needs some discussion and thinking and experimentation. I?ll get back to you after the weekend.
> >
> > Hannes
> >
> >
> >
> >> Am 05.08.2016 um 04:40 schrieb Jo?o Paulo Varandas <joaovarandas at inpaas.com>:
> >>
> >> By the way, I just found out some bugs filed about Long objects:
> >> https://bugs.openjdk.java.net/browse/JDK-8162771
> >> https://bugs.openjdk.java.net/browse/JDK-8161665
> >>
> >> And a twitter discussion:
> >> https://twitter.com/provegard/status/755010492112986112
> >>
> >> I'd like to bring this up again if we have more room for discussion ...
> >> --
> >>
> >> 2 Long values returned from a database and sent to a javascript evaluation code can't be compared the way it should in JavaScript...  If I have some validation code, I don't know if the source is some JavaScript input (number), or the source is a database query (object/Long/Integer/Double).
> >>
> >> It's really hard to decide when sometimes x==y should be compared as x.equals(y) and sometimes not... and sometimes, at the same point in code I should do a lot of conditional operations, to resolve a simple comparison... and that comparison does not work if the data source is a Java object or a JavaScript object.
> >>
> >> The problem with the current solution is that comparison between different types would never work ...
> >>
> >> Seeing that
> >> jjs> new java.lang.Long(2147483648) == "2147483648"
> >> returns true
> >>
> >> But
> >> jjs> new java.lang.Long(2147483648) == new java.lang.Long(2147483648)
> >> returns false
> >>
> >> Is something really hard to accept ...
> >> And that "equals" approach will work ONLY if I compare Long to Long. And I see this as a regression when talking about evaluating JavaScript code.
> >>
> >>
> >>
> >> Sorry about the long post, but I would really appreciate if we could revalidate this and think about what the current situation represents from ecmascript's point of view.
> >>
> >>
> >>
> >>
> >>
> >> -08-04 22:43 GMT-03:00 Jo?o Paulo Varandas <joaovarandas at inpaas.com>:
> >> Sorry Tomas.
> >>
> >> Either you did not read the message(which would be indeed a beginner's mistake), or you are misleading the discussion.
> >>
> >> What you said, about equality and references would be true if we were talking about Java code. This is jdk8-nashorn's mailing list and I'm talking about JavaScript evaluation inside the JVM.
> >>
> >>
> >> Comparison operators inside the script engine follow JavaScript rules and not Java rules.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>      Jo?o Paulo Varandas
> >> +55 11 99889-2321
> >> joaovarandas at inpaas.com
> >>
> >>
> >> 2016-08-04 20:08 GMT-03:00 Tom?? Z?ma <tomas at tzima.cz>:
> >> A classical beginner's mistake. You are using Java objects and comparing references, not the values, so this is expected behavior. Simply compare the objects using equals().
> >>
> >>
> >> On 4.8.2016 15:48, Jo?o Paulo Varandas wrote:
> >> Hi guys!
> >>
> >> It seems that version 1.8.0_101 has a bug in equality for same java data
> >> types (java.lang.Long).
> >>
> >> Check that:
> >> jjs> new java.lang.Long(10) == new java.lang.Long(10)
> >> false
> >>
> >> Oops!?
> >>
> >> See the gist:
> >> https://gist.github.com/joaovarandas/51567bd3b576d48a4c574d60d5a60ba3
> >>
> >> The results for all types should be ...
> >> ==    true
> >> ===   true
> >> equals true
> >>
> >> But for java.lang.Long and java.math.BigDecimal:
> >> ==    false
> >> ===   false
> >> equals true
> >>
> >> Maybe we could expand the test to other classes too, but the issue ...
> >> - It does happen in 1.8.0_101.
> >> - It does not 1.8.0_91.
> >> - It does happen with other classes (BigDecimal).
> >> - It does not happen with String.
> >> - It does not happen with Integer.
> >>
> >>
> >> I understand this is not an expected behavior. For now I'm rolling back
> >> to 1.8.0_91 in my environments.
> >>
> >>
> >>
> >> Do you me to file a bug?
> >>
> >> Thanks
> >> J
> >>
> >>
> >>
> >>
> >>
> >>
> >> "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"
> >
> 
> 
> 
> "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 hannes.wallnoefer at oracle.com  Wed Aug 17 06:08:32 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Wed, 17 Aug 2016 08:08:32 +0200
Subject: RFR: 8162955: Activate anonymous class loading for small sources
In-Reply-To: <53AF0878-662A-4357-AEF0-46058C304FC0@lagergren.net>
References: <DC39583D-F511-4C1E-AD3A-0D414562A3FF@oracle.com>
	<9878FE30-E33E-45EA-A334-19C05D304EC1@lagergren.net>
	<7BCF824F-EFBE-49A4-BA64-2ADFC2195C30@oracle.com>
	<53AF0878-662A-4357-AEF0-46058C304FC0@lagergren.net>
Message-ID: <8D5B5988-07BD-450E-A3AE-E21A718A3CB8@oracle.com>

We have the ?auto? setting with its size threshold as default exactly because it does affect runtime performance. With anonymous classes, some octane benchmarks are significantly slower. So the rationale behind the ?auto? setting is that we use anon classes for small scripts because 1) loading time matters more here and 2) these are often run-once. 

This is where the ?auto? setting was introduced, shortly after support for anonymous classes: 
https://bugs.openjdk.java.net/browse/JDK-8138882
 
Hannes

> Am 13.08.2016 um 20:23 schrieb Marcus Lagergren <marcus at lagergren.net>:
> 
> Interesting
> +1
> 
> Is it possible to make this a flag with default ?on", and check in a microbenchmark that proves this?
> 
> Does this affect runtime performance, i.e. program execution speed, in any way that you can measure?
> 
> Regards
> Marcus
> 
>> On 09 Aug 2016, at 12:10, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
>> 
>> It?s pretty drastic, and has gotten more pronounced in recent JDK 9 builds. Running test programs from the issues linked in the Jira description there?s somewhere between 30% and 100% speedup from using anonymous classes.
>> 
>> Note that the intention has always been to use anonymous classes for short scripts, we just didn?t realize many users compile one-liners using the Java API.
>> 
>> Hannes
>> 
>> 
>>> Am 09.08.2016 um 11:24 schrieb Marcus Lagergren <marcus at lagergren.net>:
>>> 
>>> Do you have any benchmark examples with better and worse results?
>>> 
>>> Just curious
>>> 
>>> /M
>>> 
>>>> On 04 Aug 2016, at 13:48, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
>>>> 
>>>> Please review 8162955: Activate anonymous class loading for small sources.
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162955
>>>> Webrev: http://cr.openjdk.java.net/~hannesw/8162955/webrev/
>>>> 
>>>> The size threshold of 512 bytes I chose is arbitrary. It seems to fit all reported cases which consist of firing lots of one-liner scripts where quick loading is more important than optimization.
>>>> 
>>>> Thanks,
>>>> Hannes
>>> 
>> 
> 


From szegedia at gmail.com  Wed Aug 17 06:45:23 2016
From: szegedia at gmail.com (Attila Szegedi)
Date: Wed, 17 Aug 2016 08:45:23 +0200
Subject: Unexpected equality behavior (java.lang.Long)
In-Reply-To: <2B6D3495-DD97-4E6E-BC7D-9FFEB7DF9045@oracle.com>
References: <CACoP5y2Xfo91oTFkUT9G-oZs+-WHb3a9wmBcnYT+bpPqSg5CZQ@mail.gmail.com>
	<57A3CB0A.3040809@tzima.cz>
	<CACoP5y0d7+cow7WOQT+HGv+T5moest7BbG2FRdynqHiRm+sEyA@mail.gmail.com>
	<CACoP5y1O+-14nJUK37P1RFQT45DYNkjqBzf10FORiuNTTq6eBw@mail.gmail.com>
	<B18B7EB2-D8DA-405B-AC77-76637B4C3802@oracle.com>
	<563909A9-709B-4BF5-BCF2-038599AFB022@oracle.com>
	<CACoP5y0WGRGti_XuVa71+WgOQZEzUqWfsr_BP64oZiFPW6QM2A@mail.gmail.com>
	<2B6D3495-DD97-4E6E-BC7D-9FFEB7DF9045@oracle.com>
Message-ID: <DD72A4FD-D170-4F4A-B1E6-FE007E400794@gmail.com>

It doesn?t? Null is its own type in JS. The typeof operator returns the string ?object? for a null value as per http://es5.github.io/#x11.4.3 <http://es5.github.io/#x11.4.3>, but that?s (weird JS) special-casing. Internally, Null is a type with one value, null.


> On 17 Aug 2016, at 07:56, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
> 
> It?s unfortunate JS considers null to be of type ?object?. I think that in most practical circumstances and definitely when a number comes from a Java primitive you can omit the null check as Java primitives can?t be null, though.
> 
> Hannes
> 
> 
>> Am 16.08.2016 um 16:16 schrieb Jo?o Paulo Varandas <joaovarandas at inpaas.com>:
>> 
>> Hi Hannes.
>> 
>> Thanks for reviewing this. Seeing it from this perspective:
>> 
>> Longs are just like JS Number wrappers.
>> 
>> Made me believe the situation was not that bad too. Telling developers to 'unwrap' numbers using " x = Number(x); " would not be a bad idea.
>> 
>> With that in mind, any number comparison would have to be made unwrapping data first ... But, we would also need to test nulls first, because:
>> 
>> While "null == 0" yields false, and obviusly "null === 0" yields false.
>> Number(null) === Number(0) would yield true.
>> 
>> Thus, we would need:
>> 
>> function unwrapNumber(x) {
>>   return x == null ? null : Number(x);
>> }
>> 
>> And also, to tell developers to call unwrapNumber() everytime they need to compare a Number ... 
>> 
>> I don't know if you agree with me, but now I see this as an anti-pattern.
>> 
>> 
>> ---
>> 
>> Anyway... It seems that all the fuzz is because of that "bug" with Long numbers and double. And I'm sorry that I did not look further into that issue.
>> 
>> Maybe we should look further into that, and try to make that any number below Number.MAX_SAFE_INTEGER (9007199254740991), work the way is expected inside JS evaluations ... 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 	Jo?o Paulo Varandas
>> +55 11 99889-2321
>> joaovarandas at inpaas.com
>> 
>> 
>> 2016-08-16 6:23 GMT-03:00 Hannes Walln?fer <hannes.wallnoefer at oracle.com>:
>> After exploring various options I don?t think there?s anything we can do to go back and treat longs like numbers in Nashorn.
>> 
>> The ECMA spec is quite clear that there are numbers and object, and comparison of the latter is by reference, not value. So having some kind of in-between states is not really an option. Making longs numbers again would be quite a small and harmless change within the language (without reverting to longs as internal data type). Precision would be lowered to doubles for large longs, but that wouldn?t be a problem for most users.
>> 
>> However, the problems starts where longs as numbers inherit from Number.prototype. Of course, all methods in Number.prototype are specified for double values, and the toString methods collides with toString in java.lang.Long. Having a toString method that rounds large longs to the nearest double value is a no-go. Nor is extending all methods in Number.prototype to handle longs are viable options.
>> 
>> There is one issue we need to fix to improve handling of longs and other instances of java.lang.Number though (thanks to Attila for first pointing this out): Currently, java.lang.Numbers not treated as numbers in the ToPrimitive operation with Number hint. This means less-than/greater-than operators will treat those number objects as strings instead of converting to double. I filed a bug for this, and will back port it to JDK 8u:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8163945
>> 
>> All things considered, there are some things that make me think the situation is not as bad as some seem to believe. For one, the new treatment of Longs (with the fix for the bug above) is consistent with how JavaScript Number objects/wrappers are treated. Comparing two Number wrappers for the same value will also evaluate to false with both == and === operators, while comparing them to the primitive number with == will evaluate to true.
>> 
>> new Number(1) == new Number(1) // false
>> new Number(1) === new Number(1) // false
>> new Number(1) == 1 // true
>> new Number(1) === 1 // false
>> 
>> So Longs are just like JS Number wrappers. They are object wrappers for numeric values. If needed they can easily converted to primitive numbers by calling the global Number() function without ?new? keyword, eg:
>> 
>> if (typeof x === ?object?)
>>    x = Number(x);
>> 
>> This is a common pattern in JavaScript even without Java longs, so I think it?s acceptable.
>> 
>> Hannes
>> 
>> 
>>> Am 05.08.2016 um 15:45 schrieb Hannes Walln?fer <hannes.wallnoefer at oracle.com>:
>>> 
>>> Hi Joao Paulo,
>>> 
>>> thanks for the report.
>>> 
>>> We do realize that this change caused problems for a lot of people, and we are sorry for that, and thinking how we can improve things.
>>> 
>>> I still think we were right to remove longs as internal number representation. But maybe we went to far with this, and should allow people to deal with longs as numbers, assuming they are all right with an eventual loss of presentation.
>>> 
>>> This needs some discussion and thinking and experimentation. I?ll get back to you after the weekend.
>>> 
>>> Hannes
>>> 
>>> 
>>> 
>>>> Am 05.08.2016 um 04:40 schrieb Jo?o Paulo Varandas <joaovarandas at inpaas.com>:
>>>> 
>>>> By the way, I just found out some bugs filed about Long objects:
>>>> https://bugs.openjdk.java.net/browse/JDK-8162771
>>>> https://bugs.openjdk.java.net/browse/JDK-8161665
>>>> 
>>>> And a twitter discussion:
>>>> https://twitter.com/provegard/status/755010492112986112
>>>> 
>>>> I'd like to bring this up again if we have more room for discussion ...
>>>> --
>>>> 
>>>> 2 Long values returned from a database and sent to a javascript evaluation code can't be compared the way it should in JavaScript...  If I have some validation code, I don't know if the source is some JavaScript input (number), or the source is a database query (object/Long/Integer/Double).
>>>> 
>>>> It's really hard to decide when sometimes x==y should be compared as x.equals(y) and sometimes not... and sometimes, at the same point in code I should do a lot of conditional operations, to resolve a simple comparison... and that comparison does not work if the data source is a Java object or a JavaScript object.
>>>> 
>>>> The problem with the current solution is that comparison between different types would never work ...
>>>> 
>>>> Seeing that
>>>> jjs> new java.lang.Long(2147483648) == "2147483648"
>>>> returns true
>>>> 
>>>> But
>>>> jjs> new java.lang.Long(2147483648) == new java.lang.Long(2147483648)
>>>> returns false
>>>> 
>>>> Is something really hard to accept ...
>>>> And that "equals" approach will work ONLY if I compare Long to Long. And I see this as a regression when talking about evaluating JavaScript code.
>>>> 
>>>> 
>>>> 
>>>> Sorry about the long post, but I would really appreciate if we could revalidate this and think about what the current situation represents from ecmascript's point of view.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -08-04 22:43 GMT-03:00 Jo?o Paulo Varandas <joaovarandas at inpaas.com>:
>>>> Sorry Tomas.
>>>> 
>>>> Either you did not read the message(which would be indeed a beginner's mistake), or you are misleading the discussion.
>>>> 
>>>> What you said, about equality and references would be true if we were talking about Java code. This is jdk8-nashorn's mailing list and I'm talking about JavaScript evaluation inside the JVM.
>>>> 
>>>> 
>>>> Comparison operators inside the script engine follow JavaScript rules and not Java rules.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>     Jo?o Paulo Varandas
>>>> +55 11 99889-2321
>>>> joaovarandas at inpaas.com
>>>> 
>>>> 
>>>> 2016-08-04 20:08 GMT-03:00 Tom?? Z?ma <tomas at tzima.cz>:
>>>> A classical beginner's mistake. You are using Java objects and comparing references, not the values, so this is expected behavior. Simply compare the objects using equals().
>>>> 
>>>> 
>>>> On 4.8.2016 15:48, Jo?o Paulo Varandas wrote:
>>>> Hi guys!
>>>> 
>>>> It seems that version 1.8.0_101 has a bug in equality for same java data
>>>> types (java.lang.Long).
>>>> 
>>>> Check that:
>>>> jjs> new java.lang.Long(10) == new java.lang.Long(10)
>>>> false
>>>> 
>>>> Oops!?
>>>> 
>>>> See the gist:
>>>> https://gist.github.com/joaovarandas/51567bd3b576d48a4c574d60d5a60ba3
>>>> 
>>>> The results for all types should be ...
>>>> ==    true
>>>> ===   true
>>>> equals true
>>>> 
>>>> But for java.lang.Long and java.math.BigDecimal:
>>>> ==    false
>>>> ===   false
>>>> equals true
>>>> 
>>>> Maybe we could expand the test to other classes too, but the issue ...
>>>> - It does happen in 1.8.0_101.
>>>> - It does not 1.8.0_91.
>>>> - It does happen with other classes (BigDecimal).
>>>> - It does not happen with String.
>>>> - It does not happen with Integer.
>>>> 
>>>> 
>>>> I understand this is not an expected behavior. For now I'm rolling back
>>>> to 1.8.0_91 in my environments.
>>>> 
>>>> 
>>>> 
>>>> Do you me to file a bug?
>>>> 
>>>> Thanks
>>>> J
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> "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"
>>> 
>> 
>> 
>> 
>> "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 hannes.wallnoefer at oracle.com  Wed Aug 17 08:50:53 2016
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Wed, 17 Aug 2016 10:50:53 +0200
Subject: Unexpected equality behavior (java.lang.Long)
In-Reply-To: <DD72A4FD-D170-4F4A-B1E6-FE007E400794@gmail.com>
References: <CACoP5y2Xfo91oTFkUT9G-oZs+-WHb3a9wmBcnYT+bpPqSg5CZQ@mail.gmail.com>
	<57A3CB0A.3040809@tzima.cz>
	<CACoP5y0d7+cow7WOQT+HGv+T5moest7BbG2FRdynqHiRm+sEyA@mail.gmail.com>
	<CACoP5y1O+-14nJUK37P1RFQT45DYNkjqBzf10FORiuNTTq6eBw@mail.gmail.com>
	<B18B7EB2-D8DA-405B-AC77-76637B4C3802@oracle.com>
	<563909A9-709B-4BF5-BCF2-038599AFB022@oracle.com>
	<CACoP5y0WGRGti_XuVa71+WgOQZEzUqWfsr_BP64oZiFPW6QM2A@mail.gmail.com>
	<2B6D3495-DD97-4E6E-BC7D-9FFEB7DF9045@oracle.com>
	<DD72A4FD-D170-4F4A-B1E6-FE007E400794@gmail.com>
Message-ID: <8636E4FA-3FCC-4BAD-9088-3E14DE664D4E@oracle.com>

You?re right. I was referring to behavior of the typeof operator.

Hannes

> Am 17.08.2016 um 08:45 schrieb Attila Szegedi <szegedia at gmail.com>:
> 
> It doesn?t? Null is its own type in JS. The typeof operator returns the string ?object? for a null value as per http://es5.github.io/#x11.4.3, but that?s (weird JS) special-casing. Internally, Null is a type with one value, null.
> 
> 
>> On 17 Aug 2016, at 07:56, Hannes Walln?fer <hannes.wallnoefer at oracle.com> wrote:
>> 
>> It?s unfortunate JS considers null to be of type ?object?. I think that in most practical circumstances and definitely when a number comes from a Java primitive you can omit the null check as Java primitives can?t be null, though.
>> 
>> Hannes
>> 
>> 
>>> Am 16.08.2016 um 16:16 schrieb Jo?o Paulo Varandas <joaovarandas at inpaas.com>:
>>> 
>>> Hi Hannes.
>>> 
>>> Thanks for reviewing this. Seeing it from this perspective:
>>> 
>>> Longs are just like JS Number wrappers.
>>> 
>>> Made me believe the situation was not that bad too. Telling developers to 'unwrap' numbers using " x = Number(x); " would not be a bad idea.
>>> 
>>> With that in mind, any number comparison would have to be made unwrapping data first ... But, we would also need to test nulls first, because:
>>> 
>>> While "null == 0" yields false, and obviusly "null === 0" yields false.
>>> Number(null) === Number(0) would yield true.
>>> 
>>> Thus, we would need:
>>> 
>>> function unwrapNumber(x) {
>>>   return x == null ? null : Number(x);
>>> }
>>> 
>>> And also, to tell developers to call unwrapNumber() everytime they need to compare a Number ... 
>>> 
>>> I don't know if you agree with me, but now I see this as an anti-pattern.
>>> 
>>> 
>>> ---
>>> 
>>> Anyway... It seems that all the fuzz is because of that "bug" with Long numbers and double. And I'm sorry that I did not look further into that issue.
>>> 
>>> Maybe we should look further into that, and try to make that any number below Number.MAX_SAFE_INTEGER (9007199254740991), work the way is expected inside JS evaluations ... 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 	Jo?o Paulo Varandas
>>> +55 11 99889-2321
>>> joaovarandas at inpaas.com
>>> 
>>> 
>>> 2016-08-16 6:23 GMT-03:00 Hannes Walln?fer <hannes.wallnoefer at oracle.com>:
>>> After exploring various options I don?t think there?s anything we can do to go back and treat longs like numbers in Nashorn.
>>> 
>>> The ECMA spec is quite clear that there are numbers and object, and comparison of the latter is by reference, not value. So having some kind of in-between states is not really an option. Making longs numbers again would be quite a small and harmless change within the language (without reverting to longs as internal data type). Precision would be lowered to doubles for large longs, but that wouldn?t be a problem for most users.
>>> 
>>> However, the problems starts where longs as numbers inherit from Number.prototype. Of course, all methods in Number.prototype are specified for double values, and the toString methods collides with toString in java.lang.Long. Having a toString method that rounds large longs to the nearest double value is a no-go. Nor is extending all methods in Number.prototype to handle longs are viable options.
>>> 
>>> There is one issue we need to fix to improve handling of longs and other instances of java.lang.Number though (thanks to Attila for first pointing this out): Currently, java.lang.Numbers not treated as numbers in the ToPrimitive operation with Number hint. This means less-than/greater-than operators will treat those number objects as strings instead of converting to double. I filed a bug for this, and will back port it to JDK 8u:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8163945
>>> 
>>> All things considered, there are some things that make me think the situation is not as bad as some seem to believe. For one, the new treatment of Longs (with the fix for the bug above) is consistent with how JavaScript Number objects/wrappers are treated. Comparing two Number wrappers for the same value will also evaluate to false with both == and === operators, while comparing them to the primitive number with == will evaluate to true.
>>> 
>>> new Number(1) == new Number(1) // false
>>> new Number(1) === new Number(1) // false
>>> new Number(1) == 1 // true
>>> new Number(1) === 1 // false
>>> 
>>> So Longs are just like JS Number wrappers. They are object wrappers for numeric values. If needed they can easily converted to primitive numbers by calling the global Number() function without ?new? keyword, eg:
>>> 
>>> if (typeof x === ?object?)
>>>    x = Number(x);
>>> 
>>> This is a common pattern in JavaScript even without Java longs, so I think it?s acceptable.
>>> 
>>> Hannes
>>> 
>>> 
>>>> Am 05.08.2016 um 15:45 schrieb Hannes Walln?fer <hannes.wallnoefer at oracle.com>:
>>>> 
>>>> Hi Joao Paulo,
>>>> 
>>>> thanks for the report.
>>>> 
>>>> We do realize that this change caused problems for a lot of people, and we are sorry for that, and thinking how we can improve things.
>>>> 
>>>> I still think we were right to remove longs as internal number representation. But maybe we went to far with this, and should allow people to deal with longs as numbers, assuming they are all right with an eventual loss of presentation.
>>>> 
>>>> This needs some discussion and thinking and experimentation. I?ll get back to you after the weekend.
>>>> 
>>>> Hannes
>>>> 
>>>> 
>>>> 
>>>>> Am 05.08.2016 um 04:40 schrieb Jo?o Paulo Varandas <joaovarandas at inpaas.com>:
>>>>> 
>>>>> By the way, I just found out some bugs filed about Long objects:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8162771
>>>>> https://bugs.openjdk.java.net/browse/JDK-8161665
>>>>> 
>>>>> And a twitter discussion:
>>>>> https://twitter.com/provegard/status/755010492112986112
>>>>> 
>>>>> I'd like to bring this up again if we have more room for discussion ...
>>>>> --
>>>>> 
>>>>> 2 Long values returned from a database and sent to a javascript evaluation code can't be compared the way it should in JavaScript...  If I have some validation code, I don't know if the source is some JavaScript input (number), or the source is a database query (object/Long/Integer/Double).
>>>>> 
>>>>> It's really hard to decide when sometimes x==y should be compared as x.equals(y) and sometimes not... and sometimes, at the same point in code I should do a lot of conditional operations, to resolve a simple comparison... and that comparison does not work if the data source is a Java object or a JavaScript object.
>>>>> 
>>>>> The problem with the current solution is that comparison between different types would never work ...
>>>>> 
>>>>> Seeing that
>>>>> jjs> new java.lang.Long(2147483648) == "2147483648"
>>>>> returns true
>>>>> 
>>>>> But
>>>>> jjs> new java.lang.Long(2147483648) == new java.lang.Long(2147483648)
>>>>> returns false
>>>>> 
>>>>> Is something really hard to accept ...
>>>>> And that "equals" approach will work ONLY if I compare Long to Long. And I see this as a regression when talking about evaluating JavaScript code.
>>>>> 
>>>>> 
>>>>> 
>>>>> Sorry about the long post, but I would really appreciate if we could revalidate this and think about what the current situation represents from ecmascript's point of view.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -08-04 22:43 GMT-03:00 Jo?o Paulo Varandas <joaovarandas at inpaas.com>:
>>>>> Sorry Tomas.
>>>>> 
>>>>> Either you did not read the message(which would be indeed a beginner's mistake), or you are misleading the discussion.
>>>>> 
>>>>> What you said, about equality and references would be true if we were talking about Java code. This is jdk8-nashorn's mailing list and I'm talking about JavaScript evaluation inside the JVM.
>>>>> 
>>>>> 
>>>>> Comparison operators inside the script engine follow JavaScript rules and not Java rules.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>     Jo?o Paulo Varandas
>>>>> +55 11 99889-2321
>>>>> joaovarandas at inpaas.com
>>>>> 
>>>>> 
>>>>> 2016-08-04 20:08 GMT-03:00 Tom?? Z?ma <tomas at tzima.cz>:
>>>>> A classical beginner's mistake. You are using Java objects and comparing references, not the values, so this is expected behavior. Simply compare the objects using equals().
>>>>> 
>>>>> 
>>>>> On 4.8.2016 15:48, Jo?o Paulo Varandas wrote:
>>>>> Hi guys!
>>>>> 
>>>>> It seems that version 1.8.0_101 has a bug in equality for same java data
>>>>> types (java.lang.Long).
>>>>> 
>>>>> Check that:
>>>>> jjs> new java.lang.Long(10) == new java.lang.Long(10)
>>>>> false
>>>>> 
>>>>> Oops!?
>>>>> 
>>>>> See the gist:
>>>>> https://gist.github.com/joaovarandas/51567bd3b576d48a4c574d60d5a60ba3
>>>>> 
>>>>> The results for all types should be ...
>>>>> ==    true
>>>>> ===   true
>>>>> equals true
>>>>> 
>>>>> But for java.lang.Long and java.math.BigDecimal:
>>>>> ==    false
>>>>> ===   false
>>>>> equals true
>>>>> 
>>>>> Maybe we could expand the test to other classes too, but the issue ...
>>>>> - It does happen in 1.8.0_101.
>>>>> - It does not 1.8.0_91.
>>>>> - It does happen with other classes (BigDecimal).
>>>>> - It does not happen with String.
>>>>> - It does not happen with Integer.
>>>>> 
>>>>> 
>>>>> I understand this is not an expected behavior. For now I'm rolling back
>>>>> to 1.8.0_91 in my environments.
>>>>> 
>>>>> 
>>>>> 
>>>>> Do you me to file a bug?
>>>>> 
>>>>> Thanks
>>>>> J
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> "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"
>>>> 
>>> 
>>> 
>>> 
>>> "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 joaovarandas at inpaas.com  Wed Aug 17 11:48:27 2016
From: joaovarandas at inpaas.com (=?UTF-8?Q?Jo=C3=A3o_Paulo_Varandas?=)
Date: Wed, 17 Aug 2016 08:48:27 -0300
Subject: Unexpected equality behavior (java.lang.Long)
In-Reply-To: <8636E4FA-3FCC-4BAD-9088-3E14DE664D4E@oracle.com>
References: <CACoP5y2Xfo91oTFkUT9G-oZs+-WHb3a9wmBcnYT+bpPqSg5CZQ@mail.gmail.com>
	<57A3CB0A.3040809@tzima.cz>
	<CACoP5y0d7+cow7WOQT+HGv+T5moest7BbG2FRdynqHiRm+sEyA@mail.gmail.com>
	<CACoP5y1O+-14nJUK37P1RFQT45DYNkjqBzf10FORiuNTTq6eBw@mail.gmail.com>
	<B18B7EB2-D8DA-405B-AC77-76637B4C3802@oracle.com>
	<563909A9-709B-4BF5-BCF2-038599AFB022@oracle.com>
	<CACoP5y0WGRGti_XuVa71+WgOQZEzUqWfsr_BP64oZiFPW6QM2A@mail.gmail.com>
	<2B6D3495-DD97-4E6E-BC7D-9FFEB7DF9045@oracle.com>
	<DD72A4FD-D170-4F4A-B1E6-FE007E400794@gmail.com>
	<8636E4FA-3FCC-4BAD-9088-3E14DE664D4E@oracle.com>
Message-ID: <CACoP5y25cPO+H_iV_HTdbCTUn5xe6oUDW8fjPj+01DP4pUi0bg@mail.gmail.com>

We don't need null checks for primitive types, but ...

* Any value inside a Map or a Collection won't be primitive. And could be
null.

* Also, if we are talking about any record coming from a database, 'null'
is there.

* Any value not present in a Map is returned as null from the "get" method
(for ScriptObjectMirror too)

* Any JSON (if we use Jackson or json.org objects for example) would be
parsed into a Map, and, thus would also have null values.

* Request parameters can be null if they are not provided (nowadays, if we
are talking about RESTful services, requests are mostly in JSON format
and...  there are null values).


So I would say that nulls must be validated in most cases anyway.





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


2016-08-17 5:50 GMT-03:00 Hannes Walln?fer <hannes.wallnoefer at oracle.com>:

> You?re right. I was referring to behavior of the typeof operator.
>
> Hannes
>
> > Am 17.08.2016 um 08:45 schrieb Attila Szegedi <szegedia at gmail.com>:
> >
> > It doesn?t? Null is its own type in JS. The typeof operator returns the
> string ?object? for a null value as per http://es5.github.io/#x11.4.3,
> but that?s (weird JS) special-casing. Internally, Null is a type with one
> value, null.
> >
> >
> >> On 17 Aug 2016, at 07:56, Hannes Walln?fer <
> hannes.wallnoefer at oracle.com> wrote:
> >>
> >> It?s unfortunate JS considers null to be of type ?object?. I think that
> in most practical circumstances and definitely when a number comes from a
> Java primitive you can omit the null check as Java primitives can?t be
> null, though.
> >>
> >> Hannes
> >>
> >>
> >>> Am 16.08.2016 um 16:16 schrieb Jo?o Paulo Varandas <
> joaovarandas at inpaas.com>:
> >>>
> >>> Hi Hannes.
> >>>
> >>> Thanks for reviewing this. Seeing it from this perspective:
> >>>
> >>> Longs are just like JS Number wrappers.
> >>>
> >>> Made me believe the situation was not that bad too. Telling developers
> to 'unwrap' numbers using " x = Number(x); " would not be a bad idea.
> >>>
> >>> With that in mind, any number comparison would have to be made
> unwrapping data first ... But, we would also need to test nulls first,
> because:
> >>>
> >>> While "null == 0" yields false, and obviusly "null === 0" yields false.
> >>> Number(null) === Number(0) would yield true.
> >>>
> >>> Thus, we would need:
> >>>
> >>> function unwrapNumber(x) {
> >>>   return x == null ? null : Number(x);
> >>> }
> >>>
> >>> And also, to tell developers to call unwrapNumber() everytime they
> need to compare a Number ...
> >>>
> >>> I don't know if you agree with me, but now I see this as an
> anti-pattern.
> >>>
> >>>
> >>> ---
> >>>
> >>> Anyway... It seems that all the fuzz is because of that "bug" with
> Long numbers and double. And I'm sorry that I did not look further into
> that issue.
> >>>
> >>> Maybe we should look further into that, and try to make that any
> number below Number.MAX_SAFE_INTEGER (9007199254740991), work the way is
> expected inside JS evaluations ...
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     Jo?o Paulo Varandas
> >>> +55 11 99889-2321
> >>> joaovarandas at inpaas.com
> >>>
> >>>
> >>> 2016-08-16 6:23 GMT-03:00 Hannes Walln?fer <
> hannes.wallnoefer at oracle.com>:
> >>> After exploring various options I don?t think there?s anything we can
> do to go back and treat longs like numbers in Nashorn.
> >>>
> >>> The ECMA spec is quite clear that there are numbers and object, and
> comparison of the latter is by reference, not value. So having some kind of
> in-between states is not really an option. Making longs numbers again would
> be quite a small and harmless change within the language (without reverting
> to longs as internal data type). Precision would be lowered to doubles for
> large longs, but that wouldn?t be a problem for most users.
> >>>
> >>> However, the problems starts where longs as numbers inherit from
> Number.prototype. Of course, all methods in Number.prototype are specified
> for double values, and the toString methods collides with toString in
> java.lang.Long. Having a toString method that rounds large longs to the
> nearest double value is a no-go. Nor is extending all methods in
> Number.prototype to handle longs are viable options.
> >>>
> >>> There is one issue we need to fix to improve handling of longs and
> other instances of java.lang.Number though (thanks to Attila for first
> pointing this out): Currently, java.lang.Numbers not treated as numbers in
> the ToPrimitive operation with Number hint. This means
> less-than/greater-than operators will treat those number objects as strings
> instead of converting to double. I filed a bug for this, and will back port
> it to JDK 8u:
> >>>
> >>> https://bugs.openjdk.java.net/browse/JDK-8163945
> >>>
> >>> All things considered, there are some things that make me think the
> situation is not as bad as some seem to believe. For one, the new treatment
> of Longs (with the fix for the bug above) is consistent with how JavaScript
> Number objects/wrappers are treated. Comparing two Number wrappers for the
> same value will also evaluate to false with both == and === operators,
> while comparing them to the primitive number with == will evaluate to true.
> >>>
> >>> new Number(1) == new Number(1) // false
> >>> new Number(1) === new Number(1) // false
> >>> new Number(1) == 1 // true
> >>> new Number(1) === 1 // false
> >>>
> >>> So Longs are just like JS Number wrappers. They are object wrappers
> for numeric values. If needed they can easily converted to primitive
> numbers by calling the global Number() function without ?new? keyword, eg:
> >>>
> >>> if (typeof x === ?object?)
> >>>    x = Number(x);
> >>>
> >>> This is a common pattern in JavaScript even without Java longs, so I
> think it?s acceptable.
> >>>
> >>> Hannes
> >>>
> >>>
> >>>> Am 05.08.2016 um 15:45 schrieb Hannes Walln?fer <
> hannes.wallnoefer at oracle.com>:
> >>>>
> >>>> Hi Joao Paulo,
> >>>>
> >>>> thanks for the report.
> >>>>
> >>>> We do realize that this change caused problems for a lot of people,
> and we are sorry for that, and thinking how we can improve things.
> >>>>
> >>>> I still think we were right to remove longs as internal number
> representation. But maybe we went to far with this, and should allow people
> to deal with longs as numbers, assuming they are all right with an eventual
> loss of presentation.
> >>>>
> >>>> This needs some discussion and thinking and experimentation. I?ll get
> back to you after the weekend.
> >>>>
> >>>> Hannes
> >>>>
> >>>>
> >>>>
> >>>>> Am 05.08.2016 um 04:40 schrieb Jo?o Paulo Varandas <
> joaovarandas at inpaas.com>:
> >>>>>
> >>>>> By the way, I just found out some bugs filed about Long objects:
> >>>>> https://bugs.openjdk.java.net/browse/JDK-8162771
> >>>>> https://bugs.openjdk.java.net/browse/JDK-8161665
> >>>>>
> >>>>> And a twitter discussion:
> >>>>> https://twitter.com/provegard/status/755010492112986112
> >>>>>
> >>>>> I'd like to bring this up again if we have more room for discussion
> ...
> >>>>> --
> >>>>>
> >>>>> 2 Long values returned from a database and sent to a javascript
> evaluation code can't be compared the way it should in JavaScript...  If I
> have some validation code, I don't know if the source is some JavaScript
> input (number), or the source is a database query
> (object/Long/Integer/Double).
> >>>>>
> >>>>> It's really hard to decide when sometimes x==y should be compared as
> x.equals(y) and sometimes not... and sometimes, at the same point in code I
> should do a lot of conditional operations, to resolve a simple
> comparison... and that comparison does not work if the data source is a
> Java object or a JavaScript object.
> >>>>>
> >>>>> The problem with the current solution is that comparison between
> different types would never work ...
> >>>>>
> >>>>> Seeing that
> >>>>> jjs> new java.lang.Long(2147483648) == "2147483648"
> >>>>> returns true
> >>>>>
> >>>>> But
> >>>>> jjs> new java.lang.Long(2147483648) == new java.lang.Long(2147483648
> )
> >>>>> returns false
> >>>>>
> >>>>> Is something really hard to accept ...
> >>>>> And that "equals" approach will work ONLY if I compare Long to Long.
> And I see this as a regression when talking about evaluating JavaScript
> code.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Sorry about the long post, but I would really appreciate if we could
> revalidate this and think about what the current situation represents from
> ecmascript's point of view.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> -08-04 22:43 GMT-03:00 Jo?o Paulo Varandas <joaovarandas at inpaas.com
> >:
> >>>>> Sorry Tomas.
> >>>>>
> >>>>> Either you did not read the message(which would be indeed a
> beginner's mistake), or you are misleading the discussion.
> >>>>>
> >>>>> What you said, about equality and references would be true if we
> were talking about Java code. This is jdk8-nashorn's mailing list and I'm
> talking about JavaScript evaluation inside the JVM.
> >>>>>
> >>>>>
> >>>>> Comparison operators inside the script engine follow JavaScript
> rules and not Java rules.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Jo?o Paulo Varandas
> >>>>> +55 11 99889-2321
> >>>>> joaovarandas at inpaas.com
> >>>>>
> >>>>>
> >>>>> 2016-08-04 20:08 GMT-03:00 Tom?? Z?ma <tomas at tzima.cz>:
> >>>>> A classical beginner's mistake. You are using Java objects and
> comparing references, not the values, so this is expected behavior. Simply
> compare the objects using equals().
> >>>>>
> >>>>>
> >>>>> On 4.8.2016 15:48, Jo?o Paulo Varandas wrote:
> >>>>> Hi guys!
> >>>>>
> >>>>> It seems that version 1.8.0_101 has a bug in equality for same java
> data
> >>>>> types (java.lang.Long).
> >>>>>
> >>>>> Check that:
> >>>>> jjs> new java.lang.Long(10) == new java.lang.Long(10)
> >>>>> false
> >>>>>
> >>>>> Oops!?
> >>>>>
> >>>>> See the gist:
> >>>>> https://gist.github.com/joaovarandas/51567bd3b576d48a4c574d60d5a60b
> a3
> >>>>>
> >>>>> The results for all types should be ...
> >>>>> ==    true
> >>>>> ===   true
> >>>>> equals true
> >>>>>
> >>>>> But for java.lang.Long and java.math.BigDecimal:
> >>>>> ==    false
> >>>>> ===   false
> >>>>> equals true
> >>>>>
> >>>>> Maybe we could expand the test to other classes too, but the issue
> ...
> >>>>> - It does happen in 1.8.0_101.
> >>>>> - It does not 1.8.0_91.
> >>>>> - It does happen with other classes (BigDecimal).
> >>>>> - It does not happen with String.
> >>>>> - It does not happen with Integer.
> >>>>>
> >>>>>
> >>>>> I understand this is not an expected behavior. For now I'm rolling
> back
> >>>>> to 1.8.0_91 in my environments.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Do you me to file a bug?
> >>>>>
> >>>>> Thanks
> >>>>> J
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> "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"
> >>>>
> >>>
> >>>
> >>>
> >>> "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"
> >>>
> >>
> >
>
>

-- 
"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 sundararajan.athijegannathan at oracle.com  Wed Aug 17 13:45:09 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 17 Aug 2016 19:15:09 +0530
Subject: RFR 8164216: Netbeans makefile for nashorn should use JDK_9 as
	platform
Message-ID: <f59593df-5345-e7ea-ce7f-c8f89326ce4b@oracle.com>

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

-Sundar


From james.laskey at oracle.com  Wed Aug 17 13:46:13 2016
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Wed, 17 Aug 2016 10:46:13 -0300
Subject: RFR 8164216: Netbeans makefile for nashorn should use JDK_9 as
	platform
In-Reply-To: <f59593df-5345-e7ea-ce7f-c8f89326ce4b@oracle.com>
References: <f59593df-5345-e7ea-ce7f-c8f89326ce4b@oracle.com>
Message-ID: <5E3844AE-741C-4940-9150-3170C2539478@oracle.com>

+1

> On Aug 17, 2016, at 10:45 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8164216/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8164216
> 
> -Sundar
> 


From sundararajan.athijegannathan at oracle.com  Thu Aug 18 09:04:10 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 18 Aug 2016 14:34:10 +0530
Subject: RFR 8164260: readLine does not echo characters
Message-ID: <0149661c-79a3-b88f-832e-d50c48ec84f3@oracle.com>

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

Thanks,

-Sundar


From james.laskey at oracle.com  Thu Aug 18 10:46:20 2016
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Thu, 18 Aug 2016 07:46:20 -0300
Subject: RFR 8164260: readLine does not echo characters
In-Reply-To: <0149661c-79a3-b88f-832e-d50c48ec84f3@oracle.com>
References: <0149661c-79a3-b88f-832e-d50c48ec84f3@oracle.com>
Message-ID: <98EAE767-B0C7-4EBE-A4FA-433673E43A7C@oracle.com>

+1

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


From axel.faust.g at googlemail.com  Fri Aug 19 14:41:16 2016
From: axel.faust.g at googlemail.com (Axel Faust)
Date: Fri, 19 Aug 2016 16:41:16 +0200
Subject: Type specialization / recompilation of functions using "arguments"
Message-ID: <CAJx6Ui6uqhgPPbsOD6vwUH1GnLge++XhkugNU=miXSTex11hBQ@mail.gmail.com>

Hello,

in my ongoing project to implement an alternative scripting integration to
the ECM platform Alfresco using Nashorn, I recently ran into a performance
issue due to constructor / function recompilation due to type
specialization, particularly if the constructor / function in question is
accessing the "arguments" object.

I have tried to simplify this with a test and used "jjs
--log=recompile:finest" to run it.

Consider the following script:

function testArguments() { print(JSON.stringify(arguments)); }
// simple call tests
testArguments('test1'); // first access => 2x "parameter type
specialization"
testArguments('test1'); // identical parameter => no recompilation
testArguments('test2'); // identical param type, different value =>
"parameter type specialization"
testArguments('test3'); // identical param type, different value =>
"parameter type specialization"
// iterative call test
for (var i = 0; i < 1000; i++) { testArguments('test' + i); } // identical
param type, different values => only one "parameter type specialization"


Now I don't quite understand why script function "testArguments" needs to
be recompiled on each call with the same parameter type but different
value, and how this is not required when executed within a loop structure.
The latter is interesting on another level, since a test script for my
Alfresco-Nashorn integration is running an array-forEach loop where the
called function is being recompiled on every iteration, while replacing the
for-loop in the test script above with an array-forEach (pre-filled)
behaves exactly the same as the for-loop with only a single recompilation.
Additionally, in the integration test script I even see recompilations for
identical values (in subsequent runs of the same script).

Now having a single recompilation wouldn't be so bad, but continous
recompilation hurts quite a bit. Unfortunately this affects quite a central
piece in my integration project and thus causes significant overhead via
ClassLoader.defineClass, Class.getDeclaredFields and method handle / call
site handling operations that result from the recompilation. Each run of my
integration-specific test script adds ~10 CompiledFunction instances to the
ScriptFunctionData.code list for the same function (all with apparently
identical call site types and invokers, at least judging from
toString-representations). The persistent code cache doesn't seem to be
used at all as RecompilableScriptFunctionData.getBest calls
compileTypeSpecialization in a way that disables its use.

Is this behaviour something that should be considered "expected" or is it a
"real" performance bug? If it is expected, is there a general
recommendation not to use functions that access arguments for
performance-critical code?
(I tested with JDK 8u71 and JDK 9 ea+125 - behaviour is the same except JDK
9 provides deoptimization log output on 1st call)

Regards
Axel Faust

From james.laskey at oracle.com  Fri Aug 19 14:49:30 2016
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Fri, 19 Aug 2016 11:49:30 -0300
Subject: Type specialization / recompilation of functions using "arguments"
In-Reply-To: <CAJx6Ui6uqhgPPbsOD6vwUH1GnLge++XhkugNU=miXSTex11hBQ@mail.gmail.com>
References: <CAJx6Ui6uqhgPPbsOD6vwUH1GnLge++XhkugNU=miXSTex11hBQ@mail.gmail.com>
Message-ID: <C74A3EC1-8EA7-4EF2-B3F7-E7CCAB1780F2@oracle.com>

Axel,

I?ve created a bug to track.  May be slow to process because of vacations and JDK9 long march.

https://bugs.openjdk.java.net/browse/JDK-8164477

Cheers,

? Jim


> On Aug 19, 2016, at 11:41 AM, Axel Faust <axel.faust.g at googlemail.com> wrote:
> 
> Hello,
> 
> in my ongoing project to implement an alternative scripting integration to
> the ECM platform Alfresco using Nashorn, I recently ran into a performance
> issue due to constructor / function recompilation due to type
> specialization, particularly if the constructor / function in question is
> accessing the "arguments" object.
> 
> I have tried to simplify this with a test and used "jjs
> --log=recompile:finest" to run it.
> 
> Consider the following script:
> 
> function testArguments() { print(JSON.stringify(arguments)); }
> // simple call tests
> testArguments('test1'); // first access => 2x "parameter type
> specialization"
> testArguments('test1'); // identical parameter => no recompilation
> testArguments('test2'); // identical param type, different value =>
> "parameter type specialization"
> testArguments('test3'); // identical param type, different value =>
> "parameter type specialization"
> // iterative call test
> for (var i = 0; i < 1000; i++) { testArguments('test' + i); } // identical
> param type, different values => only one "parameter type specialization"
> 
> 
> Now I don't quite understand why script function "testArguments" needs to
> be recompiled on each call with the same parameter type but different
> value, and how this is not required when executed within a loop structure.
> The latter is interesting on another level, since a test script for my
> Alfresco-Nashorn integration is running an array-forEach loop where the
> called function is being recompiled on every iteration, while replacing the
> for-loop in the test script above with an array-forEach (pre-filled)
> behaves exactly the same as the for-loop with only a single recompilation.
> Additionally, in the integration test script I even see recompilations for
> identical values (in subsequent runs of the same script).
> 
> Now having a single recompilation wouldn't be so bad, but continous
> recompilation hurts quite a bit. Unfortunately this affects quite a central
> piece in my integration project and thus causes significant overhead via
> ClassLoader.defineClass, Class.getDeclaredFields and method handle / call
> site handling operations that result from the recompilation. Each run of my
> integration-specific test script adds ~10 CompiledFunction instances to the
> ScriptFunctionData.code list for the same function (all with apparently
> identical call site types and invokers, at least judging from
> toString-representations). The persistent code cache doesn't seem to be
> used at all as RecompilableScriptFunctionData.getBest calls
> compileTypeSpecialization in a way that disables its use.
> 
> Is this behaviour something that should be considered "expected" or is it a
> "real" performance bug? If it is expected, is there a general
> recommendation not to use functions that access arguments for
> performance-critical code?
> (I tested with JDK 8u71 and JDK 9 ea+125 - behaviour is the same except JDK
> 9 provides deoptimization log output on 1st call)
> 
> Regards
> Axel Faust


From emilian.bold at gmail.com  Sat Aug 20 06:21:21 2016
From: emilian.bold at gmail.com (Emilian Bold)
Date: Sat, 20 Aug 2016 09:21:21 +0300
Subject: Tree API (JEP 236): fine grained offsets (for eg. SwitchTree)
In-Reply-To: <87f36a59-d29c-a8f1-8dbc-f9d7eafdd5f8@oracle.com>
References: <CAL6R17DTO-NFGFTtbc3dPSrG-meiG5k-5tXUztXPqcam33CEZA@mail.gmail.com>
	<87f36a59-d29c-a8f1-8dbc-f9d7eafdd5f8@oracle.com>
Message-ID: <CAL6R17AdpufcQMxiiFo6d+WQwW8pWv354XQczv5DJQGmgj14QQ@mail.gmail.com>

javac's tree API is equally unfit for IDEs editing/debugging which JEP 236
should help with. Which I presume is why NetBeans has its own javac fork
http://hg.netbeans.org/main/nb-javac-jdk8/

The JEP 236 Tree API is only good for abstract code analysis. It's not good
for tools that preserve most of the text as-is (say, a refactoring tool).


--emi

On Thu, Aug 4, 2016 at 8:11 AM, Sundararajan Athijegannathan <
sundararajan.athijegannathan at oracle.com> wrote:

> hmm.. not sure if Abstract syntax tree Parser API should provide offsets
> of "(", "}" etc.  This API is modeled after javac's tree API - I don't
> think even that goes to that level of representation of the source code...
>
> -Sundar
>
>
> On 8/3/2016 2:38 PM, Emilian Bold wrote:
> > Hello,
> >
> > Since JEP 236 is designed to help with editing I believe the Tree API
> > should provide more offsets info about the whole statement.
> >
> > For example SwitchTree covers the switch statement:
> >
> > switch ( expression ) {
> >      cases
> > }
> >
> > but it is impossible to determine the offsets of the curly braces or of
> the
> > round brackets.
> >
> > The closing curly brace is clearly located at SwitchTree.getEndPosition.
> >
> > But the first curly brace has an unknown offset somewhere between
> > SwitchTree.getExpression(). getEndPosition() + 1 and the getStartPosition
> > of the 1st CaseTree.
> >
> > Obviously exact offsets are necessary to provide matching brace
> > highlighting or code folding for the switch expression in an editor.
> >
> > Ideally SwitchTree would have contained a (Switch)BlockTree which in turn
> > would have contained the list of CaseTree-s.
> >
> > For the round brackets, SwitchTree.getExpression() could have returned
> > a ParenthesizedTree instead.
> >
> > PS: I wonder, would it be possible to guarantee that there is a way to
> > re-generate the exact input string based on the (CompilationUnit)Tree?
> > Because this is what seems necessary for an editor or for
> > minimally-invasive source-code processing tools.
> >
> > --emi
>
>

From srinivas.dama at oracle.com  Tue Aug 23 09:49:58 2016
From: srinivas.dama at oracle.com (Srinivas Dama)
Date: Tue, 23 Aug 2016 02:49:58 -0700 (PDT)
Subject: RFR:8164618: add documentation for NativeNumber and NativeBoolean
Message-ID: <3367dd1e-1ac8-45b4-9f92-21bb438e43b5@default>

Hi,
Please review http://cr.openjdk.java.net/~sdama/8164618/webrev.00/ 
for https://bugs.openjdk.java.net/browse/JDK-8164618 

Regards,
Srinivas

From sundararajan.athijegannathan at oracle.com  Tue Aug 23 10:31:21 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Tue, 23 Aug 2016 16:01:21 +0530
Subject: RFR:8164618: add documentation for NativeNumber and NativeBoolean
In-Reply-To: <3367dd1e-1ac8-45b4-9f92-21bb438e43b5@default>
References: <3367dd1e-1ac8-45b4-9f92-21bb438e43b5@default>
Message-ID: <7e5e1668-a645-6b40-2b5c-bd4aaecc2f48@oracle.com>

+1


On 8/23/2016 3:19 PM, Srinivas Dama wrote:
> Hi,
> Please review http://cr.openjdk.java.net/~sdama/8164618/webrev.00/ 
> for https://bugs.openjdk.java.net/browse/JDK-8164618 
>
> Regards,
> Srinivas


From sundararajan.athijegannathan at oracle.com  Thu Aug 25 16:43:13 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 25 Aug 2016 22:13:13 +0530
Subject: RFR 8164748: Edit pad crashes when calling function
Message-ID: <aef35c09-c1d6-9542-ebb7-a2f20c224486@oracle.com>

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

Thanks,

-Sundar


From james.laskey at oracle.com  Thu Aug 25 16:45:18 2016
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Thu, 25 Aug 2016 13:45:18 -0300
Subject: RFR 8164748: Edit pad crashes when calling function
In-Reply-To: <aef35c09-c1d6-9542-ebb7-a2f20c224486@oracle.com>
References: <aef35c09-c1d6-9542-ebb7-a2f20c224486@oracle.com>
Message-ID: <3BD2E312-B1CE-4049-B00F-8AC87017380B@oracle.com>

+1

> On Aug 25, 2016, at 1:43 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8164748/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8164748
> 
> Thanks,
> 
> -Sundar
> 


From fiterman at gmail.com  Thu Aug 25 16:23:25 2016
From: fiterman at gmail.com (Yuli Fiterman)
Date: Thu, 25 Aug 2016 12:23:25 -0400
Subject: Please fix the StackOverFlowError
In-Reply-To: <F1B5DA3099B6E84A83217769A750A33723B8F036@smtp_mail.bankofamerica.com>
References: <F1B5DA3099B6E84A83217769A750A33723B8F036@smtp_mail.bankofamerica.com>
Message-ID: <CACSMDgAjNmurCVzZ2Qx=3Vqhb37Jyfjwx8LHd+BaXduKJG_epg@mail.gmail.com>

Please fix the StackOverFlowError. This is affecting a lot of people.  It
happens because Nashorn relies on Java serialization but the way the AST is
structured causes extremely deep nesting for certain expressions.  Yes, the
scripts that cause this are poorly written but other JS engines have no
problems handling them ? so it needs to be fixed in Nashorn.



Link for details:



https://youtrack.jetbrains.com/issue/IDEA-157806

From claes.redestad at oracle.com  Fri Aug 26 00:24:19 2016
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 26 Aug 2016 02:24:19 +0200
Subject: jjs and the tiny heap that couldn't
Message-ID: <57BF8C33.4000200@oracle.com>

Hi,

as I was playing around with jjs to get some data points on recent indy
bootstrap improvements when I noticed that the default heap size might
be excessively small (linux x64 on a machine with 64G RAM):

exit.js:
exit();

jdk9/bin/jjs -J-Xlog:gc exit.js
[0.026s][info][gc] Using G1
[0,246s][info][gc] GC(0) Pause Young (G1 Evacuation Pause) 3M->0M(8M) 
(0,243s, 0,246s) 3,643ms
[0,321s][info][gc] GC(1) Pause Young (G1 Evacuation Pause) 2M->1M(8M) 
(0,314s, 0,321s) 6,996ms
[0,353s][info][gc] GC(2) Pause Young (G1 Evacuation Pause) 2M->1M(8M) 
(0,349s, 0,353s) 3,307ms
[0,485s][info][gc] GC(3) Pause Young (G1 Evacuation Pause) 3M->1M(8M) 
(0,474s, 0,485s) 10,991ms
[0,581s][info][gc] GC(4) Pause Young (G1 Evacuation Pause) 3M->2M(14M) 
(0,573s, 0,581s) 7,879ms
[0,743s][info][gc] GC(5) Pause Young (G1 Evacuation Pause) 6M->2M(14M) 
(0,735s, 0,743s) 8,678ms

It appears jjs starts out with a tiny heap, leading to substantial
time spent in GC just to bootstrap.

A small bump to -Xms35m removes GC activity during bootstrap (for
reference on this machine java defaults to an -Xms around 140m):

jdk9/bin/jjs -J-Xmx35m -J-Xlog:gc exit.js
[0.026s][info][gc] Using G1

The story is similar on 8u, but there I had to increase it all the way
to -Xms100m to get GC activity down to zero.

Is it just me, or does it seem odd that jjs is so aggressively tuned
for minimal footprint that we spend considerable time in GC just to get
up and running - and still end up increasing the heap size in the
process?

Thanks!

/Claes

From sundararajan.athijegannathan at oracle.com  Fri Aug 26 03:01:12 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 26 Aug 2016 08:31:12 +0530
Subject: jjs and the tiny heap that couldn't
In-Reply-To: <57BF8C33.4000200@oracle.com>
References: <57BF8C33.4000200@oracle.com>
Message-ID: <33661f0b-731c-4ec5-845e-eb384a440c6e@oracle.com>

I don't think jjs was ever GC tuned! Most likely default copied/adapted
from somewhere else!

Please file a bug with your findings.

PS. jjs of jdk9 is very different (in interactive mode) from that of
jdk8u. jdk9 versions on jline+many other desktop stuff and so would load
lot more code.

Thanks,

-Sundar


On 8/26/2016 5:54 AM, Claes Redestad wrote:
> Hi,
>
> as I was playing around with jjs to get some data points on recent indy
> bootstrap improvements when I noticed that the default heap size might
> be excessively small (linux x64 on a machine with 64G RAM):
>
> exit.js:
> exit();
>
> jdk9/bin/jjs -J-Xlog:gc exit.js
> [0.026s][info][gc] Using G1
> [0,246s][info][gc] GC(0) Pause Young (G1 Evacuation Pause) 3M->0M(8M)
> (0,243s, 0,246s) 3,643ms
> [0,321s][info][gc] GC(1) Pause Young (G1 Evacuation Pause) 2M->1M(8M)
> (0,314s, 0,321s) 6,996ms
> [0,353s][info][gc] GC(2) Pause Young (G1 Evacuation Pause) 2M->1M(8M)
> (0,349s, 0,353s) 3,307ms
> [0,485s][info][gc] GC(3) Pause Young (G1 Evacuation Pause) 3M->1M(8M)
> (0,474s, 0,485s) 10,991ms
> [0,581s][info][gc] GC(4) Pause Young (G1 Evacuation Pause) 3M->2M(14M)
> (0,573s, 0,581s) 7,879ms
> [0,743s][info][gc] GC(5) Pause Young (G1 Evacuation Pause) 6M->2M(14M)
> (0,735s, 0,743s) 8,678ms
>
> It appears jjs starts out with a tiny heap, leading to substantial
> time spent in GC just to bootstrap.
>
> A small bump to -Xms35m removes GC activity during bootstrap (for
> reference on this machine java defaults to an -Xms around 140m):
>
> jdk9/bin/jjs -J-Xmx35m -J-Xlog:gc exit.js
> [0.026s][info][gc] Using G1
>
> The story is similar on 8u, but there I had to increase it all the way
> to -Xms100m to get GC activity down to zero.
>
> Is it just me, or does it seem odd that jjs is so aggressively tuned
> for minimal footprint that we spend considerable time in GC just to get
> up and running - and still end up increasing the heap size in the
> process?
>
> Thanks!
>
> /Claes


From claes.redestad at oracle.com  Fri Aug 26 11:18:13 2016
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 26 Aug 2016 13:18:13 +0200
Subject: jjs and the tiny heap that couldn't
In-Reply-To: <33661f0b-731c-4ec5-845e-eb384a440c6e@oracle.com>
References: <57BF8C33.4000200@oracle.com>
	<33661f0b-731c-4ec5-845e-eb384a440c6e@oracle.com>
Message-ID: <57C02575.4040203@oracle.com>



On 2016-08-26 05:01, Sundararajan Athijegannathan wrote:
> I don't think jjs was ever GC tuned! Most likely default copied/adapted
> from somewhere else!
>
> Please file a bug with your findings.

Sure:

https://bugs.openjdk.java.net/browse/JDK-8164848

>
> PS. jjs of jdk9 is very different (in interactive mode) from that of
> jdk8u. jdk9 versions on jline+many other desktop stuff and so would load
> lot more code.

Right, I noticed that on jdk8 running the exit.js script loads fewer
classes (1827), while on jdk9 we load 2359 classes right now (down from
2450 OOTB thanks to the --generate-jli-classes plugin and other work on
improving indy bootstrap[1]).

When I link a custom image with a --generate-jli-classes configuration
created by running jjs exit.js I can currently get it down to 2114
classes loaded (meaning we're avoiding generating more than 300 LF
classes at bootstrap), which together with the small heap tuning puts
startup of jjs on 9 well on par with 8.

Thanks!

/Claes

[1] https://bugs.openjdk.java.net/browse/JDK-8086045