Re: RFR: 8156615:Catch parameter can be a BindingPattern in ES6 mode

/8156615/webrev.02/ > > Included all changes suggested with some modifications. > > Regards, > Srinivas > > -Original Message- > From: Attila Szegedi [mailto:szege...@gmail.com] > Sent: Tuesday, November 08, 2016 7:40 PM > To: Nashorn-dev > Subject: Re: RFR:

Re: Review request for JDK-8168373: don't emit conversions for symbols outside their lexical scope

+1 Thank for fixing this, Attila! Hannes > Am 08.11.2016 um 14:01 schrieb Attila Szegedi : > > Please review JDK-8168373 "don't emit conversions for symbols outside their > lexical scope" at > for

Re: RFR: 8156615:Catch parameter can be a BindingPattern in ES6 mode

What Sundar said. Additionally: + if (exception instanceof IdentNode) { + this.exception = ((IdentNode) exception == null) ? null : ((IdentNode) exception).setIsInitializedHere(); First, casting an expression before a null comparison is silly :-). Second, you don’t even need to check for

Re: RFR: 8156615:Catch parameter can be a BindingPattern in ES6 mode

You need to update Parser API implementation to handle catch parameter being expression - rather than an IdentNode. => you need to * add another getter in CatchNode to expose Expression * Use it in IRTranslator (of Parser API impl.) to translate catch param as expression * You need to check

Re: RFR: 8156619: Unimplemented ES6 features should result in clear Error being thrown

While it is okay on generators, reporting super keyword usage with function declaration looks bit odd.. That said, it is not very serious. +1 -Sundar On 11/7/2016 5:22 PM, Hannes Wallnöfer wrote: > Thanks Sundar. > > For the super keyword, we store its usage in the function while super itself

Re: RFR: 8156619: Unimplemented ES6 features should result in clear Error being thrown

+1 from me. > On 07 Nov 2016, at 12:52, Hannes Wallnöfer > wrote: > > Thanks Sundar. > > For the super keyword, we store its usage in the function while super itself > is a normal identifier. For generators, the function actually is the entity > although you

Re: RFR 8169050: underscore_linker.js sample fails after dynalink changes for JDK-8168005

Good catch, + 1 Hannes > Am 02.11.2016 um 13:49 schrieb Jim Laskey (Oracle) : > > +1 > >> On Nov 2, 2016, at 9:38 AM, Sundararajan Athijegannathan >> wrote: >> >> Please review

Re: RFR 8169050: underscore_linker.js sample fails after dynalink changes for JDK-8168005

+1 > On Nov 2, 2016, at 9:38 AM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8169050/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8169050 > > PS. The failing sample exposed a bug in nashorn's

Re: Review request for JDK-8168005: Introduce namespaces for GET, SET Dynalink operations

Thank you; can I consider this an approval on your part? > On 27 Oct 2016, at 15:05, Hannes Wallnöfer > wrote: > > Hi Attila, > > this looks good. Very nice work, the new API is indeed much nicer! > > Hannes > >> Am 26.10.2016 um 12:48 schrieb Attila Szegedi

Re: RFR: 8148924: Inconsistent "this" context in JSAdapter adaptee function calls

+1 > On 25 Oct 2016, at 16:45, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8148924 > Webrev: http://cr.openjdk.java.net/~hannesw/8148924/webrev/ > > Thanks, > Hannes

Re: RFR: 8148924: Inconsistent "this" context in JSAdapter adaptee function calls

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

Re: Review request for JDK-8168005: Introduce namespaces for GET, SET Dynalink operations

Hi Attila, this looks good. Very nice work, the new API is indeed much nicer! Hannes > Am 26.10.2016 um 12:48 schrieb Attila Szegedi : > > Please review JDK-8168005 "Introduce namespaces for GET, SET Dynalink > operations" at

Re: Review request for JDK-8168005: Introduce namespaces for GET, SET Dynalink operations

Hi Andreas, you’re of course right about NamedOperation finality, that’s an oversight on my part. Also thanks for catching the documentation error. I’ll fix both. Thanks, Attila. > On 26 Oct 2016, at 18:30, Andreas Woess wrote: > > Not a review, but one remark: it

Re: Review request for JDK-8168005: Introduce namespaces for GET, SET Dynalink operations

Not a review, but one remark: it does not make sense that NamedOperation is a final class given the protected changeNameInternal method. Also, in the javadoc of this class: "The contract for these operation is" Regards, Andreas On 2016-10-26 12:48, Attila Szegedi wrote: > Please review

Re: Review request for JDK-8168005: Introduce namespaces for GET, SET Dynalink operations

+1 -Sundar On 10/26/2016 4:18 PM, Attila Szegedi wrote: > Please review JDK-8168005 "Introduce namespaces for GET, SET Dynalink > operations" at for > > > The JIRA issue has detailed

Re: Help Needed To Build a standard Nashorn JAR File

Why are you trying to do this? Nashorn should be part of the JRE. Which JRE/JDK are you using? --emi On Tue, Oct 25, 2016 at 3:20 PM, RAVI KIRAN wrote: > Hello Team, > > Good Evening. Hope you all doing great. I have been going through some of > videos and blogs to

Re: RFR: 8168140: TypedArrays should implement ES6 iterator protocol

+1 > On 20 Oct 2016, at 18:06, Hannes Wallnöfer > wrote: > > Thanks, Sundar. I uploaded a new webrev with static utility methods for all > array iterators: > > http://cr.openjdk.java.net/~hannesw/8168140/webrev.01/ > > Also, I removed the „values" methods from

Re: RFR: 8168140: TypedArrays should implement ES6 iterator protocol

+1 -Sundar On 10/20/2016 9:36 PM, Hannes Wallnöfer wrote: > Thanks, Sundar. I uploaded a new webrev with static utility methods for all > array iterators: > > http://cr.openjdk.java.net/~hannesw/8168140/webrev.01/ > > Also, I removed the „values" methods from typed arrays. We don’t yet support

Re: RFR: 8168140: TypedArrays should implement ES6 iterator protocol

Could this: + return new ArrayIterator(Global.toObject(self), AbstractIterator.IterationKind.VALUE, Global.instance()); be in static utility method somewhere and be called from everywhere? Thanks, -Sundar On 10/19/2016 6:22 PM, Hannes Wallnöfer wrote: > Please review: > > Bug:

Re: RFR: 8168146 : Infinite recursion in Uint8ClampedArray.set

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

Re: RFR: 8168146 : Infinite recursion in Uint8ClampedArray.set

Not a committer but the patch was easy to understand, so +1 unbinding. Seems to me this was bound to happen due to boxing and overloaded methods and have int and Object arguments. --emi On Wed, Oct 19, 2016 at 12:41 PM, Hannes Wallnöfer < hannes.wallnoe...@oracle.com> wrote: > Please

Re: RFR 8071588: The spec for javax.script.ScriptEngineFactory.getProgram() should specify NPEs thrown

On 19/10/2016 06:06, Sundararajan Athijegannathan wrote: Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8071588 jdk webrev: http://cr.openjdk.java.net/~sundar/8071588/jdk/webrev.00/ nashorn webrev: http://cr.openjdk.java.net/~sundar/8071588/nashorn/webrev.00/ This looks okay

Re: RFR 8071588: The spec for javax.script.ScriptEngineFactory.getProgram() should specify NPEs thrown

+1 Hannes > Am 19.10.2016 um 07:06 schrieb Sundararajan Athijegannathan > : > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8071588 > > jdk webrev: http://cr.openjdk.java.net/~sundar/8071588/jdk/webrev.00/ > > nashorn webrev: >

Re: RFR 8071678: javax.script.ScriptContext setAttribute method should clarify behavior when GLOBAL_SCOPE is used and global scope object is null

+1 Hannes > Am 18.10.2016 um 13:36 schrieb Sundararajan Athijegannathan > : > > Please review http://cr.openjdk.java.net/~sundar/8071678/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8071678 > > Thanks, > > -Sundar >

Re: RFR 8071678: javax.script.ScriptContext setAttribute method should clarify behavior when GLOBAL_SCOPE is used and global scope object is null

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

Re: Java primitives should be disabled on JS objects when --no-java is used

[just fixing title so that nashorn-dev archive's list is readable in future] -Sundar On 10/17/2016 9:47 PM, Hannes Wallnöfer wrote: > In fact there's https://bugs.openjdk.java.net/browse/JDK-8157723, which was > filed by you and waiting for me. I actually dug it up earlier today. The fix > you

Re:

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

Re:

> On 17 Oct 2016, at 03:21, Hannes Wallnöfer > wrote: > > Hi Esben, > > >> Am 17.10.2016 um 09:11 schrieb Esben Andreasen > >: >> >> A. >> Where can I read about such non-ECMA-standard features in Nashorn? >> > >

Re:

Hi Esben, > Am 17.10.2016 um 09:11 schrieb Esben Andreasen : > > A. > Where can I read about such non-ECMA-standard features in Nashorn? > https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions I don’t think the string methods from java.lang.String are contained in

Re: Surprising Nashorn behavior for String methods

Hi Andreas, Well, it is as of ES 6.0. For the most part, Nashorn still is only 5.1 compliant with few ES6 items thrown in jdk 9. Also, my answer was generic in the sense that there are function properties available which are not in prototype [because of java extension]. -Sundar On 10/17/2016

Re:

Thanks. That makes sense. Two follow-ups, if I may: A. Where can I read about such non-ECMA-standard features in Nashorn? B. ECMAScript 6 includes `String.prototype.startsWith`, but it is not supported by Nashorn in ES6-mode: ``` 1 $ jjs -version --language=es6 2 nashorn 1.8.0_101 3 jjs>

Re: Surprising Nashorn behavior for String methods

@Andreas: But Nashorn on JDK 8 does not implement ECMAScript 6. --emi On Mon, Oct 17, 2016 at 8:22 AM, Andreas Rieber wrote: > Hi Sundar, > > startsWith is part of ECMAScript: > > http://www.ecma-international.org/ecma-262/6.0/#sec-string.p > rototype.startswith > >

Re:

it’s a side effect of the fact that primitive strings values in Nashorn are instances of java.lang.String, and the fact that with Nashorn you can invoke methods on Java objects, therefore “startsWith” is a Java String method. While Java methods also don’t inherit from Function.prototype (hence,

Re: Surprising Nashorn behavior for String methods

Hi Sundar, startsWith is part of ECMAScript: http://www.ecma-international.org/ecma-262/6.0/#sec-string.prototype.startswith Not widely supported... cheers Andreas On 17/10/2016 06:48, Sundararajan Athijegannathan wrote: Hi, "startsWith" is non-standard extension (actually, it is Java

Re: Surprising Nashorn behavior for String methods

Hi, "startsWith" is non-standard extension (actually, it is Java method) jjs> "hello".startsWith [jdk.internal.dynalink.beans.OverloadedDynamicMethod java.lang.String.startsWith] "startsWith" is not an ECMAScript standard specified property of String.prototype. In Nashorn, you can call methods

Re: typeof Long is not 'number' anymore

Yes, I had to freshen up on floating point precision. It's odd to use a double for a long value but you have no corruption up to 2^53. So, indeed, this might be a problem for Google, but not for normal scripts. --emi On Thu, Oct 13, 2016 at 2:05 PM, Attila Szegedi wrote:

Re: RFR 8167614: Avoid module dependency from jdk.dynalink to jdk.internal.module of java.base module

e >> compatibility concerns to changing it but it is being looked at. >> >> I'm not familiar with the issue in the java.sql.rowset module but it >> may be that the security checks in SerialJavaObject::getFields can be >> re-visited (I don't know all the history on that). >> >> >>> >>> Yes, I need boot layer modules only and I'll change that. >>> >> Thanks. >> >> -Alan. >

Re: typeof Long is not 'number' anymore

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

Re: typeof Long is not 'number' anymore

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

Re: RFR 8167614: Avoid module dependency from jdk.dynalink to jdk.internal.module of java.base module

On 12/10/2016 17:31, Sundararajan Athijegannathan wrote: Updated nashorn webrev: http://cr.openjdk.java.net/~sundar/8167614/nashorn/webrev.01/ Changed to use Layer.boot().findModule. That loos okay to me. I assume that once we fix the issues in java.sql that this code can be removed. -Alan

Re: RFR 8167614: Avoid module dependency from jdk.dynalink to jdk.internal.module of java.base module

Dynalink normally uses unreflect with publicLookup to get method handles for j.l.reflect.Method objects (found reflectively). But, publicLookup can not be used to unreflect caller sensitive methods. So, dynalink uses specific Lookup object from the callsite - for example, lookup of the Nashorn

Re: RFR 8167614: Avoid module dependency from jdk.dynalink to jdk.internal.module of java.base module

On 12/10/2016 16:11, Sundararajan Athijegannathan wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8167614 jdk webrev: http://cr.openjdk.java.net/~sundar/8167614/jdk/webrev.00/ nashorn webrev: http://cr.openjdk.java.net/~sundar/8167614/nashorn/webrev.00/ In

Re: RFR 8167614: Avoid module dependency from jdk.dynalink to jdk.internal.module of java.base module

+1 > On Oct 12, 2016, at 12:11 PM, Sundararajan Athijegannathan > wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8167614 > > jdk webrev: http://cr.openjdk.java.net/~sundar/8167614/jdk/webrev.00/ > > nashorn webrev: >

Re: Review request for JDK-8167443: Nashorn static method linking bypasses autoexported linkers

Good catch! +1 PS. We should perhaps convert few of those dynalink samples as tests.. Thanks, -Sundar On 10/11/2016 2:23 AM, Attila Szegedi wrote: > Please review JDK-8167443 "Nashorn static method linking bypasses > autoexported linkers" at >

Re: RFR 8167018: Nashorn and jjs should support --module-path and --add-modules options

+1, very nice to have jjs as first class Jigsaw citizen! Hannes > Am 07.10.2016 um 15:36 schrieb Jim Laskey (Oracle) : > > +1 > >> On Oct 7, 2016, at 10:16 AM, Sundararajan Athijegannathan >> wrote: >> >> Please review. >>

Re: RFR 8167018: Nashorn and jjs should support --module-path and --add-modules options

+1 > On Oct 7, 2016, at 10:16 AM, Sundararajan Athijegannathan > wrote: > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8167018 > Nashorn webrev: http://cr.openjdk.java.net/~sundar/8167018/nashorn/webrev.00/ > JDK webrev (jjs

Re: RFR: 8167289 : Backport ES6 updates from Graal.js

Thanks Attila. You’re right about that double cast, but I already pushed the change with Marcus’ and Sundar’s reviews. I’ll include that clean-up in my next commit. Hannes > Am 07.10.2016 um 15:22 schrieb Attila Szegedi : > > And the patch is now much easier to review!

Re: RFR: 8167289 : Backport ES6 updates from Graal.js

And the patch is now much easier to review! Anyway, apologies for having you make another roundtrip. That said, I’d prefer if subexpressions (LiteralNode.ArrayLiteralNode)literalNode and literalNode.getElementExpressions() were assigned to some shortish-named locals and used as such to

Re: RFR: 8167289 : Backport ES6 updates from Graal.js

This change conflicts with Attila’s add-finals change in Parser.java. I uploaded a new webrev with the merged patch. I double-checked that it keeps the finals and that the code I added uses final too. http://cr.openjdk.java.net/~hannesw/8167289/webrev.01/ Hannes > Am 07.10.2016 um 05:27

Re: RFR: 8167289 : Backport ES6 updates from Graal.js

+1 -Sundar On 10/6/2016 8:21 PM, Hannes Wallnöfer wrote: > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8167289 > Webrev: http://cr.openjdk.java.net/~hannesw/8167289/webrev.00/ > > These is mostly refactoring Andreas did in the Graal.js parser. It also > contains minor ES6

Re: RFR: 8167289 : Backport ES6 updates from Graal.js

+1 /M > On 6 Oct 2016, at 16:51, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8167289 > Webrev: http://cr.openjdk.java.net/~hannesw/8167289/webrev.00/ > > These is mostly refactoring Andreas did in the Graal.js

Re: Review request for JDK-8167117: insert missing final keywords

+1 > On Oct 4, 2016, at 3:36 PM, Attila Szegedi wrote: > > Please review JDK-8167117 "insert missing final keywords" at > for > > > Every year or so, this is done

Re: Review request for JDK-8167117: insert missing final keywords

2nd review, anyone? > On 05 Oct 2016, at 05:41, Sundararajan Athijegannathan > wrote: > > +1 > > PS. One of these days, we should write an ant task using javac API to > automate this check! Painful to manually check & fix using IDEs... > > -Sundar >

Re: Review request for JDK-8167037: Remove CALL_METHOD support from internal Nashorn linkers

+1 Hannes > Am 04.10.2016 um 09:51 schrieb Sundararajan Athijegannathan > : > > +1 > > -Sundar > > On 10/3/2016 10:47 PM, Attila Szegedi wrote: >> Please review JDK-8167037 "Remove CALL_METHOD support from internal Nashorn >> linkers" at

Re: Review request for JDK-8167037: Remove CALL_METHOD support from internal Nashorn linkers

+1 -Sundar On 10/3/2016 10:47 PM, Attila Szegedi wrote: > Please review JDK-8167037 "Remove CALL_METHOD support from internal Nashorn > linkers" at for > > > Nashorn never emits

Re: RFR: 8166902: Nested object literal property maps not reset in optimistic recompilation

Thanks to both of you! Attila: the TypeEvaluator (which is the only thing that will cause such as map change AFAICT) was added after the continuation code in question, so I think it was actually correct back then ;-) Hannes > Am 30.09.2016 um 18:29 schrieb Attila Szegedi

Re: RFR: 8166902: Nested object literal property maps not reset in optimistic recompilation

+1; good work. I'm kinda embarrassed I didn’t think of this case… Attila. > On 30 Sep 2016, at 18:18, Marcus Lagergren wrote: > > +1. Good catch, Hannes! > > /M > >> On 30 Sep 2016, at 16:46, Hannes Wallnöfer >> wrote: >> >> Please

Re: RFR: 8166902: Nested object literal property maps not reset in optimistic recompilation

+1. Good catch, Hannes! /M > On 30 Sep 2016, at 16:46, Hannes Wallnöfer > wrote: > > Please review 8166902: Nested object literal property maps not reset in > optimistic recompilation: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166902 > Webrev:

Re: RFR 8166183: jshell tool: on return from Ctrl-Z, garbage on screen, dies with Ctrl-C

Thumbs up on langtools and JDK. Thanks! Great to have this. Robert On September 30, 2016 2:50:46 AM Jan Lahoda wrote: Hello, When jshell or jjs are suspended and resumed, the terminal is reset to un-raw/cooked mode and jline editing is not working properly (as

Re: Integer add operation now yields Double instead of Long with JDK 1.8.0_101?

Hi Attila, that issue states that Nashorn internally represents numbers as int, long and double, and that now long should not be used anymore. To me this sounds like int can still be used, and I’d think that an int would be more appropriate for representing integral numbers until MAX_INT.

Re: Integer add operation now yields Double instead of Long with JDK 1.8.0_101?

Hi Sundar, so wouldn’t an Integer be the most appropriate Number type to represent the number 9? Suddenly running on floating point arithmetics where it used to be integer arithmetics is kind of like shaking the ground. My problem is that some complex application code is now breaking that

Re: Integer add operation now yields Double instead of Long with JDK 1.8.0_101?

Nashorn does not guarantee the exact Number subtype that will be used to represent a JS number. From Java code, you need to cast the result to java.lang.Number type and then call appropriate method like doubleValue or longValue on it. This "represent most appropriate Number type" helps in

Re: Integer add operation now yields Double instead of Long with JDK 1.8.0_101?

It’s an intentional change, see https://bugs.openjdk.java.net/browse/JDK-8144020 . Attila. > On 29 Sep 2016, at 18:30, Frantzius, Jörg wrote: > > Hi, > > we have a JUnit test that first evaluates a Javascript file

Re: Strange behavior in nested objects with optimistic types set to true

Thanks! On Thu, Sep 29, 2016 at 5:40 AM, Hannes Wallnöfer < hannes.wallnoe...@oracle.com> wrote: > Thanks for the report, Vivin, > > I’ve filed a bug and am looking into this. > > https://bugs.openjdk.java.net/browse/JDK-8166902 > > Hannes > > > Am 27.09.2016 um 19:08 schrieb Vivin Suresh

Re: Strange behavior in nested objects with optimistic types set to true

Thanks for the report, Vivin, I’ve filed a bug and am looking into this. https://bugs.openjdk.java.net/browse/JDK-8166902 Hannes > Am 27.09.2016 um 19:08 schrieb Vivin Suresh Paliath : > > This is on JDK 8u102. We're seeing strange behavior where certain certain >

Re: RFR: 8164467: ES6 computed properties are implemented wrongly

+1 > On 23 Sep 2016, at 16:24, Hannes Wallnöfer > wrote: > > Thanks Sundar! > > Anybody up for a second review? It’s not that big a patch ;) > > Hannes > >> Am 23.09.2016 um 06:25 schrieb Sundararajan Athijegannathan >>

Re: RFR: 8164467: ES6 computed properties are implemented wrongly

Thanks Sundar! Anybody up for a second review? It’s not that big a patch ;) Hannes > Am 23.09.2016 um 06:25 schrieb Sundararajan Athijegannathan > : > > +1, Nice! > > -Sundar > > > On 9/22/2016 9:06 PM, Hannes Wallnöfer wrote: >> Please review

Re: RFR 8166298: 3 nashorn ant tests fail with latest jdk9-dev tip

+1 Hannes > Am 20.09.2016 um 15:02 schrieb Michael Haupt : > > Hi Sundar, > > thumbs up. > > Best, > > Michael > >> Am 20.09.2016 um 14:51 schrieb Sundararajan Athijegannathan >> : >> >> Please review

Re: RFR 8166298: 3 nashorn ant tests fail with latest jdk9-dev tip

Hi Sundar, thumbs up. Best, Michael > Am 20.09.2016 um 14:51 schrieb Sundararajan Athijegannathan > : > > Please review http://cr.openjdk.java.net/~sundar/8166298/webrev.01/ for > https://bugs.openjdk.java.net/browse/JDK-8166298 > > Thanks, > >

Re: RFR 8166296:add documentation for Date,RegExp,Error,JSON objects

+1 -Sundar On 9/19/2016 11:13 PM, Srinivas Dama wrote: > Hello, > > Please review http://cr.openjdk.java.net/~sdama/8166296/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8166296 > > Regards, > Srinivas

Re: RFR 8166296:add documentation for Date,RegExp,Error,JSON objects

Hi Srini, > Am 19.09.2016 um 19:43 schrieb Srinivas Dama : > Please review http://cr.openjdk.java.net/~sdama/8166296/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8166296 thumbs up, provided these changes are applied: +Date.parse=returns a number, the

Re: Bug: ClassCastException for arguments variable (plain JavaScript)

Filed a bug: https://bugs.openjdk.java.net/browse/JDK-8166186 -Sundar On 9/15/2016 6:32 PM, Esben Andreasen wrote: > Nashorn can produce a ClassCastException when executing a plain > JavaScript program. > > The exception happens in a situation where the arguments variable is > used in

Re: RFR(s): 8165870: Fix module dependencies for javax.script/* tests

+1 -Sundar On 9/12/2016 9:39 PM, Sergei Kovalev wrote: > Hello team, > > Could you please review small fix for javax.script tests. > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8165870 > Webrev: http://cr.openjdk.java.net/~skovalev/8165870/webrev.00/ > > Root cause: Some tests failed in

Re: RFR 8165595: Main class should be set for nashorn modules

Looks good. thanks! /Erik On 2016-09-08 10:58, Sundararajan Athijegannathan wrote: Thanks. I'm going ahead with updated webrev : http://cr.openjdk.java.net/~sundar/8165595/webrev.02/ Only change is the whitespace removal as suggested. Thanks, -Sundar On 9/7/2016 6:18 PM, Erik Joelsson

Re: RFR 8165595: Main class should be set for nashorn modules

Thanks. I'm going ahead with updated webrev : http://cr.openjdk.java.net/~sundar/8165595/webrev.02/ Only change is the whitespace removal as suggested. Thanks, -Sundar On 9/7/2016 6:18 PM, Erik Joelsson wrote: > Hello, > > I cannot think of a more suitable place to put this right now. So far

Re: RFR: 8077149: __noSuchProperty__ and __noSuchMethod__ invocations are not properly guarded

Hi Hannes, thumbs up! Best, Michael > Am 07.09.2016 um 17:58 schrieb Hannes Wallnöfer > : > > Please review 8077149: __noSuchProperty__ and __noSuchMethod__ invocations > are not properly guarded. > > Webrev: http://cr.openjdk.java.net/~hannesw/8077149/ > Bug:

Re: RFR: 8077149: __noSuchProperty__ and __noSuchMethod__ invocations are not properly guarded

+1 > On Sep 7, 2016, at 12:58 PM, Hannes Wallnöfer > wrote: > > Please review 8077149: __noSuchProperty__ and __noSuchMethod__ invocations > are not properly guarded. > > Webrev: http://cr.openjdk.java.net/~hannesw/8077149/ > Bug:

Re: RFR 8165595: Main class should be set for nashorn modules

Hello, I cannot think of a more suitable place to put this right now. So far we have not had a need for module specific configuration for jmod creation. If this need grows, we might need to think of something. (sort of related, I have been thinking of ways to move all the java compilation

Re: RFR 8165595: Main class should be set for nashorn modules

On 07/09/2016 13:27, Sundararajan Athijegannathan wrote: jjs does not yet support module related options. So, user modules can not be scripted directly with jjs as of now. Only way is to use to launcher with -mp along with -m for jjs main class. With the change, only module name needs to be

Re: RFR 8165595: Main class should be set for nashorn modules

jjs does not yet support module related options. So, user modules can not be scripted directly with jjs as of now. Only way is to use to launcher with -mp along with -m for jjs main class. With the change, only module name needs to be specified. Also, jjs tool is not shipped for embedded

Re: RFR 8165595: Main class should be set for nashorn modules

On 07/09/2016 13:10, Sundararajan Athijegannathan wrote: Please review http://cr.openjdk.java.net/~sundar/8165595/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8165595 I'm not sure that asking users to use -m is right here, esp. when the modules contains launchers. Also

Re: ZBB List for our group

Try (assignee = jlaskey OR assignee = sundar OR assignee = hannesw OR assignee = mhaupt OR assignee = sdama) AND project = JDK AND issuetype = Bug AND status in (Open, "In Progress", New) AND priority in (P1, P2, P3) AND (fixVersion in (9) OR fixVersion is EMPTY AND affectedVersion in (9) AND

Re: Type specialization / recompilation of functions using "arguments"

Hello Hannes, I have repeated the tests with build 9-ea+134 on my new Windows 10 work laptop. Comand line is just "jjs --log=recompile:finest" The behaviour with recompilation can still be observed. Additionally I packaged the test script inside a JS file to be executed as "jjs

Re: Type specialization / recompilation of functions using "arguments"

Hi Axel, I tried to reproduce the bug with a recent JDK 9 build but did not get any of the additional/unexpected recompilation messages you described. You can see my output here:

Re: jjs and the tiny heap that couldn't

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

Re: RFR 8164748: Edit pad crashes when calling function

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

Re: RFR:8164618: add documentation for NativeNumber and NativeBoolean

+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

Re: Tree API (JEP 236): fine grained offsets (for eg. SwitchTree)

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

Re: Type specialization / recompilation of functions using "arguments"

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 wrote: > > Hello, > > in my ongoing project to

Re: RFR 8164260: readLine does not echo characters

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

Re: RFR 8164216: Netbeans makefile for nashorn should use JDK_9 as platform

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

Re: Unexpected equality behavior (java.lang.Long)

You’re right. I was referring to behavior of the typeof operator. Hannes > Am 17.08.2016 um 08:45 schrieb Attila Szegedi : > > 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,

Re: Unexpected equality behavior (java.lang.Long)

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,

Re: RFR: 8162955: Activate anonymous class loading for small sources

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

Re: Unexpected equality behavior (java.lang.Long)

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

Re: RFR: 8163945: Honor Number type hint in toPrimitive on Numbers

Thanks Attila for making me aware of this and suggesting this solution. > Am 16.08.2016 um 15:13 schrieb Attila Szegedi : > > +1 > >> On 16 Aug 2016, at 14:51, Hannes Wallnöfer >> wrote: >> >> Please review 8163945: Honor Number type hint in

Re: Unexpected equality behavior (java.lang.Long)

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

Re: RFR: 8163945: Honor Number type hint in toPrimitive on Numbers

+1 > On 16 Aug 2016, at 14:51, Hannes Wallnöfer > 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, >

Re: RFR: 8163945: Honor Number type hint in toPrimitive on Numbers

Hi Hannes, thumbs up. Best, Michael > Am 16.08.2016 um 14:51 schrieb Hannes Wallnöfer > : > > Please review 8163945: Honor Number type hint in toPrimitive on Numbers: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163945 > Webrev:

Re: RFR: 8134304: NPE in initialization of OptimisticTypesPersistence

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 : > > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8134304/webrev.01/ > for https://bugs.openjdk.java.net/browse/JDK-8134304 > >

<    3   4   5   6   7   8   9   10   11   12   >