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

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

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 <szege...@gmail.com>: > > +1 > >> On 16 Aug 2016, at 14:51, Hannes Wallnöfer <hannes.wallnoe...@oracle.com> >> wrote: >> >&g

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

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

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

; >> On 04 Aug 2016, at 13:48, Hannes Wallnöfer <hannes.wallnoe...@oracle.com> >> wrote: >> >> Please review 8162955: Activate anonymous class loading for small sources. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8162955 >> Webrev: http:/

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

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

RFR: 8162955: Activate anonymous class loading for small sources

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

RFR: 8162771: Strict equality operators should not be optimistic

Please review 8162771: Strict equality operators should not be optimistic. Bug: https://bugs.openjdk.java.net/browse/JDK-8162771 Webrev: http://cr.openjdk.java.net/~hannesw/8162771/webrev/ Thanks, Hannes

RFR: 8068972: Array.splice should follow the ES6 specification

Please review: Webrev: http://cr.openjdk.java.net/~hannesw/8068972/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8068972 This updates the implementation of Array.prototype.splice to conform with ES6 when called with a single argument. Hannes

Re: RFR 8160034: The `this` value in the `with` is broken by the repetition of a function call

that shouldn’t be required for the current case. The new webrev is here, please review: http://cr.openjdk.java.net/~hannesw/8160034/webrev.01/ Hannes > Am 20.07.2016 um 13:24 schrieb Attila Szegedi <szege...@gmail.com>: > > On 20 Jul 2016, at 12:29, Hannes Wallnöfer <hannes.wal

Re: Review request for JDK-8161930: Cleanup ScriptObject warnings

Nice, +1. Hannes > Am 20.07.2016 um 16:35 schrieb Attila Szegedi : > > Please review JDK-8161930 "Cleanup ScriptObject warnings" at > for > > > (Last one for the

Re: Review request for JDK-8161928: Dynalink documentation updates

Looks good. Thanks, Attila! Hannes > Am 20.07.2016 um 15:45 schrieb Attila Szegedi : > > Please review JDK-8161928 "Dynalink documentation updates" at > for > > >

Re: RFR 8160034: The `this` value in the `with` is broken by the repetition of a function call

Thanks for the review, Attila. Answer below. > Am 19.07.2016 um 19:04 schrieb Attila Szegedi <szege...@gmail.com>: > >> On 19 Jul 2016, at 18:20, Hannes Wallnöfer <hannes.wallnoe...@oracle.com> >> wrote: >> >> Please review: >> >> Webrev:

RFR 8160034: The `this` value in the `with` is broken by the repetition of a function call

Please review: Webrev: http://cr.openjdk.java.net/~hannesw/8160034/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8160034 The change in ScriptObject.megamorphicGet actually fixes the bug. It took me quite some time that it could be fixed so elegantly at this level. Before that, I

Re: RFR 8149929: Nashorn Parser API needs to be updated for ES6

Looks good. Great work, Sundar! Hannes > Am 12.07.2016 um 07:31 schrieb Sundararajan Athijegannathan > : > > Please review http://cr.openjdk.java.net/~sundar/8149929/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8149929 > > Nashorn Parser

RFR: 8160435: Source.baseURL is slow for URLs with unregistered protocol

Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8160435 Webrev: http://cr.openjdk.java.net/~hannesw/8160435/webrev.00/ This cleans up Source.baseURL() and avoids the potential performance problem of URL constructor throwing MalformedURLException. Thanks, Hannes

Re: Source.baseURL() overhead when using custom URL protocol scheme / stream handler

Hi Axel, Thanks for the explanation and code to reproduce the problem. I’m looking at it right now. Hannes > Am 27.06.2016 um 23:53 schrieb Axel Faust : > > Hello, > > TL;DR : I use custom URL protocol schemes and stream handlers that are not > globally

RFR: 8073653: Secondary heredoc eating wrong lines.

Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8073653 Webrev: http://cr.openjdk.java.net/~hannesw/8073653/webrev.00/ I don’t think there is a formal spec for heredoc out there, so I used documentation from other scripting languages as a guide. Hannes

RFR: 8137240: Negative lookahead in RegEx breaks backreference

Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8137240 Webrev: http://cr.openjdk.java.net/~hannesw/8137240/webrev/ Thanks, Hannes

Re: RFR 8160141: removed deprecated method calls in nashorn code

Looks good! Hannes > Am 23.06.2016 um 08:11 schrieb Michael Haupt : > > Hi Sundar, > > thumbs up. > > Best, > > Michael > >> Am 23.06.2016 um 06:28 schrieb Sundararajan Athijegannathan >> : >> >> Please review

RFR: 8159977: typeof operator does not see lexical bindings declared in other scripts

Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8159977 Webrev: http://cr.openjdk.java.net/~hannesw/8159977/webrev.00/ A let or const defined global should be visible from other scripts, but only if accessed as scope identifier. Thanks, Hannes

Re: Share context/JS bindings

e stats. Interesting to see that. One thing we did > was use strict mode and use Immediate Functions. This would keep variables > going to global scope I think. > > Thanks, > > Tony > > On Wed, Jun 15, 2016 at 8:02 AM, Hannes Wallnöfer > <hannes.wallnoe...@or

Re: RFR: 8159589: ScriptObjectMirror.clear() should remove all enumerable properties

re since I’m not following this further. Hannes > -Sundar > > On 6/17/2016 7:24 PM, Hannes Wallnöfer wrote: >> Please review JDK-8159589: ScriptObjectMirror.clear() should remove all >> enumerable properties: >> >> Bug: https://bugs.openjdk.java.net/br

RFR: 8159589: ScriptObjectMirror.clear() should remove all enumerable properties

Please review JDK-8159589: ScriptObjectMirror.clear() should remove all enumerable properties: Bug: https://bugs.openjdk.java.net/browse/JDK-8159589 Webrev: http://cr.openjdk.java.net/~hannesw/8159589/webrev.00/ In our current implementation, ScriptObjectMirror.clear() observes JS semantics by

RFR 8156614: Lazy parsing of ES6 shorthand method syntax is broken

Please review JDK-8156614: Lazy parsing of ES6 shorthand method syntax is broken: Bug: https://bugs.openjdk.java.net/browse/JDK-8156614 Webrev: http://cr.openjdk.java.net/~hannesw/8156614/webrev.00/ Thanks, Hannes

Re: RFR:8158817

> >> On 15 Jun 2016, at 13:47, Hannes Wallnöfer <hannes.wallnoe...@oracle.com> >> wrote: >> >> n >

Re: RFR: 8150219: ReferenceError in 1.8.0_72

ieb Hannes Wallnöfer > <hannes.wallnoe...@oracle.com>: > > Thanks for the comments, Sundar. > > I agree that using the existing ScriptContext thread local is a bit of a > hack. I chose this path because it allowed me to keep the changes minimal and > fix the pr

Re: Share context/JS bindings

I prototyped the proposed change to the clear() method. It seems to work well and makes a lot of sense to me, so I filed a bug for it: https://bugs.openjdk.java.net/browse/JDK-8159589 I haven’t discussed this with the other team members yet, so let’s see what they think. Hannes > Am

Re: RFR:8158817

Hi Srini, „it self“ should be a single word in Math.ceil and Math.floor. Otherwise looks good. Hannes > Am 15.06.2016 um 13:21 schrieb Michael Haupt : > > Hi Srini, > > lower-case thumbs up, with these corrections: > * Math.ceil, Math.floor: ... returns argument it

Re: RFR: 8150219: ReferenceError in 1.8.0_72

ical scoping is respected as expected! > > Besides the current "fix" works only the particular thread which feels > wrong as well. > > -Sundar > > On 6/14/2016 1:04 AM, Attila Szegedi wrote: >> +1 >> >>> On 13 Jun 2016, at 18:56, Hannes Walln

Re: Share context/JS bindings

Hi Axel, The problem seems to be that bindings.clear() uses the ECMAScript delete operation to clear the bindings, and that will only delete a property if it is configurable. However, var declarations are non-configurable and therefore „survive“. I’m not sure how to work around this, and

RFR: 8150219: ReferenceError in 1.8.0_72

Please review 8150219: ReferenceError in 1.8.0_72: Bug: https://bugs.openjdk.java.net/browse/JDK-8150219 Webrev: http://cr.openjdk.java.net/~hannesw/8150219/webrev.00/ This is a bit of a compromise that partially restores the behavior we had before JDK-8138616 by associating a ScriptContext

RFR: 8159220: Preserve position info in module import and export entries

Please review JDK-8159220: Preserve position info in module import and export entries http://cr.openjdk.java.net/~hannesw/8159220/ Note that this is labeled noreg-other as tests will be provided with the ES6 Parser API. Thanks, Hannes

Re: RFR 8158922: jjs tab completion of Java classes shows package-private, "hidden" classes too

Hi Sundar, Looks good. Hannes > Am 07.06.2016 um 14:34 schrieb Sundararajan Athijegannathan > : > > Please review http://cr.openjdk.java.net/~sundar/8158922/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8158922 > > Thanks, > > -Sundar >

Re: RFR(S) 8158338: Nashorn's ScriptLoader split delegation has to adjusted

This looks good to me. I’m wondering: what would be the consequences of class loader inheritance not reflecting module layer inheritance? Hannes > Am 01.06.2016 um 11:14 schrieb Sundararajan Athijegannathan > : > > I had to update webrev to handle

Review request for JDK-8066229: Fuzzing bug: Can't find scope depth

Please review JDK-8066229: Fuzzing bug: Can't find scope depth http://cr.openjdk.java.net/~hannesw/8066229/webrev/ This adds a test case for bug that is already fixed. It also removes the EXPECTED file added in the previous commit (JDK-8157250). Thanks, Hannes

Review request for JDK-8147558: Add support for ES6 collections

Please review JDK-8147558: Add support for ES6 collections: http://cr.openjdk.java.net/~hannesw/8147558/ The patch is rather large so here are a few things to point out: - The Map and Set collections use a custom linked map implementation (objects/LinkedMap) instead of using a standard Java

Re: URGENT: JDK 9 RFR of JDK-8142501: nashorn tests failing after recent changes

+1 Am Don, 12. Nov, 2015 um 5:43 schrieb Sundararajan Athijegannathan : Hi, [ Replying based on url from JIRA update. I'm yet to get email from nashorn-dev list] Nashorn team runs test via "ant clean test". Only a subset of tests are enabled for

Review request: JDK-8062030: Nashorn bug retrieving array property after key string concatenation

Please review JDK-8062030: Nashorn bug retrieving array property after key string concatenation: http://cr.openjdk.java.net/~hannesw/8062030/ Thanks, Hannes

<    1   2   3