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

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

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 >

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

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

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

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

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

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: RFR:8158817

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

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

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

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

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

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

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

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

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

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

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

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

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

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: JDK 9 RFR of JDK-8173864: Problem list src/jdk/nashorn/api/tree/test/ParseAPITest.java for some platforms

+1 Hannes > Am 03.02.2017 um 09:57 schrieb Sundararajan Athijegannathan > : > > +1 > > -Sundar > > On 03/02/17, 10:24 AM, Amy Lu wrote: >> src/jdk/nashorn/api/tree/test/ParseAPITest.java >> >> This nashorn test keeps failing at linux-i586,

Re: Function object cannot be called with different context

Am 31.01.2017 um 11:39 schrieb Frantzius, Jörg : > > As the function object is dynamically created within some 3rd party > Javascript that I cannot modify, I’m not able to create a CompiledScript > instead. > Then your best bet is probably to evaluate the script

RFR: 8173888: Test for JDK-8169481 causes stack overflows in parser tests

Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8173888 Webrev: http://cr.openjdk.java.net/~hannesw/8173888/webrev.00/ Note that the bug that introduced the problematic test is confidential, the changeset contained adjustments to the splitter weight calculation:

Re: Map should support hasOwnProperty?

Hi Jörg, We have currently no plans to make Object.prototype.hasOwnProperty on non-JavaScript objects. However, I recently pushed a change that makes the in-operator work with Java objects, maps, lists, and arrays to JDK 9. https://bugs.openjdk.java.net/browse/JDK-8173480 Hannes > Am

Re: RFR 8173257: test/script/trusted/JDK-8021189.js and test/script/trusted/JDK-8021129.js fail in nashorn nightly

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

Re: [PATCH] typos

Thanks Ahmed, I included your patch in my last commit. Hannes > Am 07.01.2017 um 02:39 schrieb Ahmed Ashour : > > Hi all, > > > Please find below a proposed patch, for some typos. > > > Thanks, > > Ahmed Ashour > > > diff --git a/README b/README > --- a/README > +++

Supporting [[hasProperty]] on JavaBeans

I noticed today that we don’t support the „in“ operator on JavaBeans. ScriptRuntime.IN(Object, Object) returns false if the second argument is a generic object (not a ScriptObject or JSObject). I was wondering if this is an oversight or intentional. If it is the former, how would we implement

RFR: 8173480: in operator should work on java objects and classes

Please review 8173480: in operator should work on java objects and classes. Bug: https://bugs.openjdk.java.net/browse/JDK-8173480 Webrev: http://cr.openjdk.java.net/~hannesw/8173480/webrev.00/nashorn.patch Thanks, Hannes

Re: Function object cannot be called with different context

There are a few problems with this code. The first is that a function declaration evaluates as undefined in Javascript, so your jsFunction variable is null. One way to work around this is to make the function an expression, e.g. by wrapping it in parentheses: engine.eval(„function test() {

RFR: 8172006: Nashorn JavaScript engine fails to call @FunctionalInterface with a java.util.List argument

Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8172006 Webrev: http://cr.openjdk.java.net/~hannesw/8172006/webrev.00/ The final invocation of linkerServices.filterInternalObjects was redundant, and in fact caused the argument to be converted to ScripObjectMirror when the actual

Re: RFR: 8172006: Nashorn JavaScript engine fails to call @FunctionalInterface with a java.util.List argument

t filtering would add a script > object mirror wrapper – the method handle’s parameter is typed as List, isn’t > it? DefaultInternalObjectFilter should only operate on parameters declared as > Object. > > Attila. > >> On 25 Jan 2017, at 17:05, Hannes Wallnöfer <hannes.wallno

Re: RFR: 8172006: Nashorn JavaScript engine fails to call @FunctionalInterface with a java.util.List argument

sions > (I completely forgot about shared scope…) > > Attila. > >> On 25 Jan 2017, at 17:32, Hannes Wallnöfer <hannes.wallnoe...@oracle.com> >> wrote: >> >> The problem is that the first invocation of filtertInternalObjects (that >> happens close

Re: Mustache.js on Nashorn

Hi Iñigo, I’ve looked at your project. The array of todo items is converted correctly, and access to the items in the array from JS works as expected. I guess you should have a look at what’s going on inside mustache.js. Hannes > Am 23.01.2017 um 23:24 schrieb Iñigo Telleria

Re: Supporting [[hasProperty]] on JavaBeans

se, but it could be a nice addition for 10. Hannes > Attila. > >> On 26 Jan 2017, at 13:57, Hannes Wallnöfer <hannes.wallnoe...@oracle.com> >> wrote: >> >> I noticed today that we don’t support the „in“ operator on JavaBeans. >> ScriptRuntime.IN(Obj

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

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:

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

Please review 8077149: __noSuchProperty__ and __noSuchMethod__ invocations are not properly guarded. Webrev: http://cr.openjdk.java.net/~hannesw/8077149/ Bug: https://bugs.openjdk.java.net/browse/JDK-8077149 Thanks, Hannes

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: RFR: 8167289 : Backport ES6 updates from Graal.js

Node.getElementExpressions().get(literalNode.getElementExpressions().size() > - 1).getToken()); > +} > > +1 otherwise. (I’m also fine if you decide to not make this change; it’s > admittedly no big deal.) > > Attila. > > >> On 07 Oct 2016

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: 8167289 : Backport ES6 updates from Graal.js

:27 schrieb Sundararajan Athijegannathan > <sundararajan.athijegannat...@oracle.com>: > > +1 > > -Sundar > > > On 10/6/2016 8:21 PM, Hannes Wallnöfer wrote: >> Please review: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8167289 >> Webr

RFR: 8167289 : Backport ES6 updates from Graal.js

Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8167289 Webrev: http://cr.openjdk.java.net/~hannesw/8167289/webrev.00/ These is mostly refactoring Andreas did in the Graal.js parser. It also contains minor ES6 parsing fixes. Tests for these will be included together with other

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 > <sundararajan.athijegannat...@oracle.com>: > > +1, Nice! > > -Sundar > > > On 9/22/2016 9:06 PM, Hannes

RFR: 8164467: ES6 computed properties are implemented wrongly

Please review 8164467: ES6 computed properties are implemented wrongly. Bug: https://bugs.openjdk.java.net/browse/JDK-8164467 Webrev: http://cr.openjdk.java.net/~hannesw/8164467/webrev.00/ This makes our support of ES6 computed property names fully spec compliant with one little exception:

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: 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: 8162955: Activate anonymous class loading for small sources

en.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 > Marcu

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

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.wallnoe...@oracle.com> >> wrote: >> >> It’s unfortunate JS considers null to be of typ

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

il.com>: > > +1; good work. I'm kinda embarrassed I didn’t think of this case… > > Attila. > >> On 30 Sep 2016, at 18:18, Marcus Lagergren <mar...@lagergren.net> wrote: >> >> +1. Good catch, Hannes! >> >> /M >> >>> On 30 Sep

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

RFR: 8168049: Fix Performance of Lexer.isJSWhitespace

Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8168049 Webrev: http://cr.openjdk.java.net/~hannesw/8168049/webrev/ This improves parse time by 5 - 10% in most scripts I’ve looked at. Thanks, Hannes

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

RFR: 8168146 : Infinite recursion in Uint8ClampedArray.set

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

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 >

RFR: 8157723: --no-java should disable POJO methods on JS primitives

Please review: Bug: http://cr.openjdk.java.net/~hannesw/8157723/webrev/ Webrev: http://cr.openjdk.java.net/~hannesw/8157723/webrev/ Thanks, Hannes

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

+1 Hannes > Am 14.11.2016 um 04:09 schrieb Sundararajan Athijegannathan > : > > Looks good > > PS. LiteralNode in catch should be an array literal, right? i.e., false > or 3.14 or "hello" won't be accepted as catch param. Perhaps worth > adding a

RFR: 8161579: Array-like AbstractJSObject-based instance not treated as array by native array functions

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

RFR: 8170322: Specialized functions convert booleans to numbers

Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8170322 Webrev: http://cr.openjdk.java.net/~hannesw/8170322/webrev/ This adds a new „convertsNumericArgs“ property to the SpecializedFunction annotation that defines whether it is safe to convert non-numeric arguments for this

Re: RFR: 8170322: Specialized functions convert booleans to numbers

Thanks for the review. > Am 25.11.2016 um 14:31 schrieb Attila Szegedi : > > If I understand it correctly, it was only Array.concat and Array.push that > needed this? That’s good, it means it wasn't a really widespread problem. > Yes, those are the only number-specialized

Re: RFR 8170402: Compilation warning with NashornException

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

RFR: 8162839: JavaAdapters do not work with ScriptObjectMirror objects

Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8162839 Webrev: http://cr.openjdk.java.net/~hannesw/8162839/webrev.00/ This makes JavaAdapters work with ScriptObjectMirrors in addition to ScriptObjects and ScriptFunctions. A few notes: - NashornLinker.getSamTypeConverter now gets

Re: RFR: 8162839: JavaAdapters do not work with ScriptObjectMirror objects

Would be nice if we have with security manager test (perhaps .js > test?) that exercises ScriptObjectMirror to adapter conversion. But, no > biggie.. > > -Sundar > > > On 11/16/2016 8:43 PM, Hannes Wallnöfer wrote: >> Please review: >> >> Bug: h

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

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:

;szege...@gmail.com>: > >> >> On 17 Oct 2016, at 03:21, Hannes Wallnöfer <hannes.wallnoe...@oracle.com> >> wrote: >> >> Hi Esben, >> >> >>> Am 17.10.2016 um 09:11 schrieb Esben Andreasen <es...@esbena.dk>: >>> >>>

Re: Can't get Multithreaded Nashorn uses to Scale

ed a run changing all > the IDs in the array we pass in to number from 1-38 and this thing went > blazing fast. When putting a break point in the same place, this array in > SpareArrayData was now of size 39. We then changed an id in the array we take > in to be 1337 and the size of the array in

RFR: 8171219: Missing checks in sparse array shift() implementation

Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8171219 Webrev: http://cr.openjdk.java.net/~hannesw/8171219/webrev/ This fixes a number of bugs around the Array.prototype.shift on sparse array data (and its underlying dense data). Unlikely as it may seem, all these issues where

Re: RFR: 8171219: Missing checks in sparse array shift() implementation

s lots of fixes. Some of these bugs are so glaring I’m astonished > they we did not spot them earlier, like failing to set a new length in > shiftLeft. It’s great you fixed these. > > Attila. > >> On 15 Dec 2016, at 11:48, Hannes Wallnöfer <hannes.wallnoe...@oracle.com

Re: RFR: 8166187: Regression: NPE during reparse when using persistent code cache and optimistic types

I just realized I used the wrong bug id for the second webrev linked below. Here’s the webrev again, with the correct id: http://cr.openjdk.java.net/~hannesw/8166187/webrev.01/ Hannes > Am 23.12.2016 um 12:20 schrieb Hannes Wallnöfer > <hannes.wallnoe...@oracle.com>: > > Th

Re: Can't get Multithreaded Nashorn uses to Scale

gt; one we should be using over the other? > > Lastly thanks for filing the bug. I'll keep track of it so I can make sure to > upgrade when a fix comes out. > > On Fri, Dec 9, 2016 at 2:37 AM, Hannes Wallnöfer > <hannes.wallnoe...@oracle.com> wrote: > Jesus, >

[8u-dev] Request for Approval: 8171219: Missing checks in sparse array shift() implementation

Please approve backport to 8u-dev: Bug: https://bugs.openjdk.java.net/browse/JDK-8171219 JDK9 Webrev: http://cr.openjdk.java.net/~hannesw/8171219/webrev/ JDK8u Webrev: http://cr.openjdk.java.net/~hannesw/8171219/webrev-8u/ Review thread:

Re: NoSuchElementException in PropertyMapIterator

Hi Ahmed, yes, this is a bug, thanks for reporting it. Out of curiosity, , since it is not an exported API class: How are you using PropertyMap? Hannes > Am 03.12.2016 um 10:00 schrieb Ahmed Ashour : > > Hi all, > I believe there is a bug in next() of

Re: RFR 8170565: JSObject call() is passed undefined for the argument 'thiz'

Hi Sundar, The problem with this approach is that it will replace any occurrence of undefined this with the global object. However, this should only occur for scope calls. For example, the following call would see undefined replaced with global: func.call(undefined) This is probably not a

Re: RFR 8170565: JSObject call() is passed undefined for the argument 'thiz'

a.net/~sundar/8170565/webrev.01/ > > PS. Had to use Function.prototype.call.call to pass undefined this explicitly > (as JSObject.call can't be called from script). > > -Sundar > > On 01/12/16, 3:13 PM, Hannes Wallnöfer wrote: >> Hi Sundar, >> >> The probl

Re: RFR 8172493: Nashorn FX example 3-4 using load for fx: scripts fails to run with latest jdk9 ea build

+1 Hannes > Am 10.01.2017 um 09:45 schrieb Sundararajan Athijegannathan > : > > Please review http://cr.openjdk.java.net/~sundar/8172493/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8172493 > > PS. I've not added an automated test because

Re: Surprising difference between /usr/bin/jjs and .getEngineByName("JavaScript")

Hi Esben, The reason you get null instead of undefined with the embedded script engine is that undefined is a language specific artefact that can’t be represented in Java. The script API translates undefined to null when it is returned by a script. Hannes > Am 21.12.2016 um 11:09 schrieb

Re: RFR: 8151994 (test/script/basic/JDK-8141209.js fails)

+1 Hannes > Am 20.12.2016 um 16:01 schrieb Srinivas Dama : > > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8151994/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8151994 > > Added @fork tag in test case since test runner without fork uses

Re: RFR: 8166187: Regression: NPE during reparse when using persistent code cache and optimistic types

; 3. make sure there’s a null check on SerializedAst.cachedAst read in > getCachedAst() (as now it can actually be null on deserialization, it was an > invariant that it was never null before) > > Attila. > >> On 22 Dec 2016, at 16:18, Hannes Wallnöfer <hannes.wallnoe...@oracle.

RFR: 8170781: PropertyMapIterator throws NoSuchElementException on last element

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

Re: Review request for JDK-8171849: Collection and Queue conversions not prioritized for Arrays

+1 Thanks! Hannes > Am 22.12.2016 um 17:44 schrieb Jim Laskey (Oracle) : > > +1 > >> On Dec 22, 2016, at 12:32 PM, Attila Szegedi wrote: >> >> Please review JDK-8171849 "Collection and Queue conversions not prioritized >> for Arrays" at

Re: Can't get Multithreaded Nashorn uses to Scale

Hi Jesus, I’m trying to reproduce the problem, and just want to make sure I get the missing pieces right. You already showed us how you’re setting up the engine and the JS code you’re running. I assume the JSON code you’re parsing is a simple array of objects? And you’re just calling

  1   2   3   >