Re: New Nashorn Project Lead: Attila Szegedi

Excellent news, Attila! I couldn’t think of a better person for this task than you. I’m glad there is a future for Nashorn, and I hope I’ll be able to contribute something to the project somewhere down the road. Hannes > Am 11.10.2020 um 09:26 schrieb Attila Szegedi : > > Thank you, Vladimi

Re: Questions about nashorn

Hello, Answers inline below. > Am 18.05.2020 um 05:40 schrieb 阮智 <1655362...@qq.com>: > > Hello, I have some questions about using nashorn in the project > > The first question: what is the usage scenario of > nashorn.option.class.cache.size, and what benefits can be brought by > modifying (i

Re: approval request for JDK-8138906:Test test/script/trusted/JDK-8087292.js intermittently fails

Hi Srini, backport looks good. Hannes Am 2016-06-06 um 17:41 schrieb Srinivas Dama: Hi, There are some 8u specific changes, Please do a backport review. Here are the links. Bug: https://bugs.openjdk.java.net/browse/JDK-8138906 Jdk9 review thread: http://mail.openjdk.java.net/pipermail/nash

Re: RFR 8158736: Adapter class loaders can avoid creating named dynamic modules

Looks good. Nice to see that code removed. Hannes Am 2016-06-06 um 11:38 schrieb Sundararajan Athijegannathan: Please review: http://cr.openjdk.java.net/~sundar/8158736/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8158736 Nashorn creates named, dynamic modules for java adapter class

Re: RFR 8158467: AccessControlException is thrown on public Java class access if "script app loader" is set to null

+1 Am 2016-06-02 um 07:10 schrieb Sundararajan Athijegannathan: Please review http://cr.openjdk.java.net/~sundar/8158467/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8158467 Thanks, -Sundar

Re: RFR 8158250: nashorn ant javadoc targets are broken

Looks good! Am 2016-05-31 um 17:00 schrieb Sundararajan Athijegannathan: Please review http://cr.openjdk.java.net/~sundar/8158250/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8158250 Thanks, -Sundar

Re: RFR 8158131: Nashorn should not use jdk.internal.module.Modules API

+1 for the incremental changes in the last iteration. Hannes Am 2016-05-31 um 09:17 schrieb Sundararajan Athijegannathan: Sorry, I have updated nashorn webrev again: http://cr.openjdk.java.net/~sundar/8158131/nashorn/webrev.02/ Incremental changes: * Missed "nashornModule" name in JavaAdapte

Re: RFR 8158131: Nashorn should not use jdk.internal.module.Modules API

Sorry for the slow review, I needed some explanation from Sundar about the difficulties of dynamic module creation, cross-layer read edges etc. With that knowledge +1 for this change. Hannes Am 2016-05-30 um 19:55 schrieb Alan Bateman: On 30/05/2016 11:43, Sundararajan Athijegannathan wrote:

Re: [8u] approval request for 8157680: Callback parameter of any JS builtin implementation should accept any Callable

Hi Sundar, the backport looks good. Hannes Am 2016-05-25 um 16:04 schrieb Sundararajan Athijegannathan: Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8157680 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-May/006225.html jdk8u webrev: http://cr.o

Re: RFR 8157819: TypeError when a java.util.Comparator object is invoked as a function

Looks good! Am 2016-05-25 um 14:29 schrieb Sundararajan Athijegannathan: Using Method.getParameterCount() per Rémi's suggestion. Updated: http://cr.openjdk.java.net/~sundar/8157819/webrev.02/ Thanks, -Sundar On 5/25/2016 5:39 PM, Remi Forax wrote: - Mail original - De: "Michael Ha

Re: RFR 8157680: Callback parameter of any JS builtin implementation should accept any Callable

This is a nice enhancement! +1 Am 2016-05-24 um 15:52 schrieb Sundararajan Athijegannathan: Please review http://cr.openjdk.java.net/~sundar/8157680/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8157680 Thanks, -Sundar

Re: RFR(XXS): 8157444: exclude jjs shebang handling test from runs

+1 Am 2016-05-20 um 15:47 schrieb Michael Haupt: Dear all, please review this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8157444 Webrev: http://cr.openjdk.java.net/~mhaupt/8157444/webrev.00/ Thanks, Michael

Re: RFR 8157310: jdk.dynalink.linker.support.Lookup should have more checks before adding module read link

Hi Sundar, I agree methods feel more in their place now. Hannes Am 2016-05-20 um 09:12 schrieb Sundararajan Athijegannathan: Hi, Thanks for the review. But, I adjusted the change slightly -- moved addModuleRead and caller-sensitive fallback attempt to CallerSensitiveDynamicMethod itself - lea

Re: RFR 8157310: jdk.dynalink.linker.support.Lookup should have more checks before adding module read link

+1 Am 2016-05-19 um 14:28 schrieb Sundararajan Athijegannathan: Please review http://cr.openjdk.java.net/~sundar/8157310/ for https://bugs.openjdk.java.net/browse/JDK-8157310 What is this fix? * When unreflecting caller sensitive methods, dynalink uses specific Lookup of actual caller (instead

Review request for JDK-8157263: Octane svn repository no longer exists

Please review JDK-8157263: Octane svn repository no longer exists: http://cr.openjdk.java.net/~hannesw/8157263/webrev/ Thanks, Hannes

Re: RFR 8157241: Remove javac warnings of Nashorn "ant clean test"

+1 Am 2016-05-18 um 14:01 schrieb Sundararajan Athijegannathan: Please review http://cr.openjdk.java.net/~sundar/8157241/ for https://bugs.openjdk.java.net/browse/JDK-8157241 Thanks, -Sundar

Re: RFR(S): 8157225: adopt method handle for array length getter in BeanLinker

+1 Am 2016-05-18 um 11:25 schrieb Michael Haupt: Dear all, please review this change. RFE: https://bugs.openjdk.java.net/browse/JDK-8157225 Webrev: http://cr.openjdk.java.net/~mhaupt/8157225/webrev.00/ Thanks, Michael

Re: RFR 8157160: JSON.stringify does not work on ScriptObjectMirror objects

+1 Am 2016-05-18 um 08:50 schrieb Sundararajan Athijegannathan: Please review http://cr.openjdk.java.net/~sundar/8157160/ for https://bugs.openjdk.java.net/browse/JDK-8157160 Thanks, -Sundar

Review request for JDK-8156714: Parsing issue with automatic semicolon insertion

Please review JDK-8156714: Parsing issue with automatic semicolon insertion: http://cr.openjdk.java.net/~hannesw/8156714/webrev/ Comments are irrelevant for newline detection so we should ignore them when assigning to AbstractParser.last. Note that this causes three endPositions to change in

Review request for JDK-8156896: Script stack trace should display function names

Review request for JDK-8156896: Script stack trace should display function names http://cr.openjdk.java.net/~hannesw/8156896/webrev/ This makes it possible to reliably get the original function name from Java method names for display in script stack traces. It replaces '$' with '#' as separat

Re: Stacktraces from dynamically-constructed functions not as expected

/file/4b118e012ac4/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/NashornException.java#l174 I've filed a bug for this: https://bugs.openjdk.java.net/browse/JDK-8156896 Hannes On Thu, May 12, 2016 at 2:12 PM, Hannes Wallnoefer mailto:hannes.wallnoe...@oracle.com>>

Re: Stacktraces from dynamically-constructed functions not as expected

Hi Vivin, What you see is some fuzziness in the translation from JS functions to Java methods and from there to the stack traces you see. When we compile a JS function, we create a Java method with the name of the function concatenated to the names of its parent functions, using '$' as separ

Re: RFR 8156820: Nashorn nightly test failure after fix for 8156738

+1 Am 2016-05-12 um 08:09 schrieb Sundararajan Athijegannathan: Please review http://cr.openjdk.java.net/~sundar/8156820/ for https://bugs.openjdk.java.net/browse/JDK-8156820 Thanks, -Sundar

Re: Review request for JDK-8156738: Use StackWalker for DynamicLinker.getLinkedCallSiteLocation

+1 Thanks, Attila! Am 2016-05-11 um 13:48 schrieb Attila Szegedi: Please review JDK-8156738 "Use StackWalker for DynamicLinker.getLinkedCallSiteLocation" at for Thanks, Attila.

Re: RFR 8156665: ES6 for..of should work on Java Iterables and Java arrays

+1 This is nice because it treats Java arrays (and lists) as JavaScript arrays in for..of. Another nice addition would be to treat java.util.Map and java.util.Set like ES6 Map and Set, respectively. Hannes Am 2016-05-10 um 16:56 schrieb Sundararajan Athijegannathan: Please review http://c

Re: RFR 8150731: Nashorn JSObject linker should be exposed as a service provider

+1 Minor issue: there's an unused import of java.util.ArrayList in Bootstrap.java Hannes Am 2016-05-05 um 06:39 schrieb Sundararajan Athijegannathan: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-March/006026.html Please review http://cr.openjdk.java.net/~sundar/8150731/webrev.02/

Re: Review request for JDK-8144711: (x) => x + 1 causes Assertion failure instead of SyntaxError

6 um 10:49 schrieb Hannes Wallnoefer mailto:hannes.wallnoe...@oracle.com>>: Please review JDK-8144711: (x) => x + 1 causes Assertion failure instead of SyntaxError: http://cr.openjdk.java.net/~hannesw/8144711/ <http://cr.openjdk.java.net/~hannesw/8144711/> Thanks, Hannes

Review request for JDK-8144711: (x) => x + 1 causes Assertion failure instead of SyntaxError

Please review JDK-8144711: (x) => x + 1 causes Assertion failure instead of SyntaxError: http://cr.openjdk.java.net/~hannesw/8144711/ Thanks, Hannes

Re: JDK-8148068 long is no longer a number

Hi Florian, Sorry about that. When we made that change we were aware of the fact that it could break existing code. However, the behaviour we had (treating longs as JS numbers) also caused some very real bugs when numbers grew larger than 53 bits. After some back and forth we decided to solve

Re: Review request for JDK-8134503: support ES6 parsing in Nashorn

ew IR node classes be final? ClassNode etc.? * .EXPECTED files have new endPosition now. are we being precise now? +1 -Sundar On 4/25/2016 5:19 PM, Hannes Wallnoefer wrote: Please review JDK-8134503: support ES6 parsing in Nashorn http://cr.openjdk.java.net/~hannesw/8134503/webrev/ The original

Re: RFR: 8155025: 0.001.toFixed(2) should return "0.00" not "0"

+1 Thanks for spotting this, Andreas! Hannes Am 2016-04-25 um 18:13 schrieb Andreas Woess: Please review: http://cr.openjdk.java.net/~aw/8155025/webrev/ https://bugs.openjdk.java.net/browse/JDK-8155025 This is a bug introduced by JDK-8010803, so it doesn't affect jdk8. Thanks, Andreas

Review request for JDK-8134503: support ES6 parsing in Nashorn

Please review JDK-8134503: support ES6 parsing in Nashorn http://cr.openjdk.java.net/~hannesw/8134503/webrev/ The original patch was contributed by Andreas Woess, I just did the integration into Nashorn tip. Thanks, Hannes

Re: Review request for JDK-8151700: Add support for ES6 for-of

ake sure "for.. of" results in SyntaxError in non-es6 mode. There are negative tests in test/script/basic/es6.js (the file name is a bit misleading). Hannes -Sundar On 3/24/2016 3:30 PM, Hannes Wallnoefer wrote: Thanks Attila, I've uploaded a new webrev with the

Re: Review request for JDK-8151700: Add support for ES6 for-of

f the Iterator in ScriptRuntime.toES6Iterator should have a pass-through catch block for Error too, e.g. instead of "catch(final RuntimeException r)” use “catch(final RuntimeException|Error r)” Other than this, +1. Attila. On Mar 21, 2016, at 10:34 AM, Hannes Wallnoefer wrote: Please

Re: RFR 8152268: jjs tool makefile should use --addmods ALL-SYSTEM

+1 Am 2016-03-23 um 09:59 schrieb Sundararajan Athijegannathan: Hi, Please review http://cr.openjdk.java.net/~sundar/8152268/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8152268 Thanks, -Sundar

Re: Review request for JDK-8151810: for-in iteration does not provide per-iteration scope

except for _es6 env check). Looking at CodeGenerator.providesScopeCreator it’s doing an awful lot of “block.” this and “block.” that. Other than that, +1. Attila. On Mar 21, 2016, at 10:23 AM, Hannes Wallnoefer wrote: Please review JDK-8151810: for-in iteration does not provide per-iterat

Review request for JDK-8151700: Add support for ES6 for-of

Please review JDK-8151700: Add support for ES6 for-of: http://cr.openjdk.java.net/~hannesw/8151700/webrev/ This enables ES6 for-of loops. The ES6 iterator is wrapped in a java.util.Iterator so it uses the exact same codegen infrastructure as for-in. Hannes

Review request for JDK-8151811: Const declarations do not work in for..in loops

Please review JDK-8151811: Const declarations do not work in for..in loops: http://cr.openjdk.java.net/~hannesw/8151811/webrev/ This is pretty trivial because most of it is fixed in JDK-8151810 (previous review request) already. Hannes

Review request for JDK-8151810: for-in iteration does not provide per-iteration scope

Please review JDK-8151810: for-in iteration does not provide per-iteration scope. http://cr.openjdk.java.net/~hannesw/8151810/webrev/ This issue popped up while I was implementing ES6 for-of statement. It turns out that like for-of, the ES5 for-in statement needs a per-iteration scope when us

Re: Nashorn increase in eval duration over time

016-03-14 17:44, Hannes Wallnoefer wrote: Hi Jan, This list is fine for reporting Nashorn related problems. Is it correct that the second batch of business logic is evaluated into a completely new set of script engines? In that case I'm not sure how the problem could be with Nashorn, since diffe

Re: Nashorn increase in eval duration over time

Hi Jan, This list is fine for reporting Nashorn related problems. Is it correct that the second batch of business logic is evaluated into a completely new set of script engines? In that case I'm not sure how the problem could be with Nashorn, since different script engines should not share an

Review request for JDK-8151809: ES6 Map/Set insertion with existing keys changes iteration order

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

Review request for JDK-8151515: $EXEC output is truncated

Please review JDK-8151515: $EXEC output is truncated. http://cr.openjdk.java.net/~hannesw/8151515/ Thanks, Hannes

Re: RFR(XS): 8151518: relax test requirements to reduce dependency on directory contents

+1 Am 2016-03-09 um 14:25 schrieb Michael Haupt: Dear all, please review this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8151518 Webrev: http://cr.openjdk.java.net/~mhaupt/8151518/webrev.00/ Thanks, Michael

Re: RFR(S): 8151291: $EXEC yields "unknown command" on Cygwin

Looks good! Hannes Am 2016-03-07 um 13:28 schrieb Michael Haupt: Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8151291 Webrev: http://cr.openjdk.java.net/~mhaupt/8151291/webrev.00/ For Cygwin, paths need special attention as the /cygdrive/x/... format is n

Re: Review request for JDK-8148148: Remove pluggable CodeStore API

: +1 On Mar 7, 2016, at 10:28 AM, Hannes Wallnoefer wrote: Please review JDK-8148148: Remove pluggable CodeStore API: Webrev: http://cr.openjdk.java.net/~hannesw/8148148/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8148148 Thanks, Hannes

Review request for JDK-8148148: Remove pluggable CodeStore API

Please review JDK-8148148: Remove pluggable CodeStore API: Webrev: http://cr.openjdk.java.net/~hannesw/8148148/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8148148 Thanks, Hannes

Re: Review request for JDK-8138906

Looks good. Hannes Am 2016-03-01 um 13:00 schrieb Srinivas Dama: Hi Michael, Thank you . Here is the latest webrev with all modifications. Bug : https://bugs.openjdk.java.net/browse/JDK-8138906 Webrev : http://cr.openjdk.java.net/~sdama/8138906/webrev.02/ Regards, Srinivas

Re: [8u] approval request for 8148379: jdk.nashorn.api.scripting spec. adjustments, clarifications

The backport looks good to me. Hannes Am 2016-02-25 um 12:31 schrieb Sundararajan Athijegannathan: On 2/25/2016 5:01 PM, Sundararajan Athijegannathan wrote: Please approve the following backport: bug: https://bugs.openjdk.java.net/browse/JDK-8148379 jdk9 review thread: http://mail.openjdk.

Re: nashorn Java8u45

Hi Roland, I think caching of scripts within a global scope was implemented from the initial JDK8 release. In 8u20 we broadened this to ScriptEngine scope, meaning that multiple global scopes running within the same engine could share compiled scripts. The cache size is limited to 50 scripts

Re: RFR 8148379: jdk.nashorn.api.scripting spec. adjustments, clarifications

+1 Am 2016-02-25 um 03:47 schrieb Sundararajan Athijegannathan: Please review http://cr.openjdk.java.net/~sundar/8148379/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8148379 Specdiff is here -> http://cr.openjdk.java.net/~sundar/8148379/specdiff0.1/overview-summary.html Thanks, -

Re: RFR(S): 8148140: arguments are handled differently in apply for JS functions and AbstractJSObjects

+1 Am 2016-02-16 um 15:40 schrieb Michael Haupt: Dear all, please review this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8148140 Webrev: http://cr.openjdk.java.net/~mhaupt/8148140/webrev.00/ The change fixes apply calls for functions defined as JSObjects by treating them like vararg c

Re: RFR(S): 8149744: fix testng.jar delivery in Nashorn build.xml

+1 Am 2016-02-12 um 16:36 schrieb Michael Haupt: Dear all, please review this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8149744 Webrev: http://cr.openjdk.java.net/~mhaupt/8149744/webrev.00/ Nashorn's build.xml used to download a TestNG ZIP file and extract the required testng.jar fr

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

taste of it did not seem too strong :) Since the patch is quite large I've also uploaded a patch with just the changes from the first webrev: http://cr.openjdk.java.net/~hannesw/8147558/changes-attila Thanks, Hannes Am 2016-02-05 um 16:31 schrieb Attila Szegedi: On Feb 5, 2016, at 3

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

Thanks for the review, Attila! Am 2016-02-05 um 14:17 schrieb Attila Szegedi: Global.java: - Documentation for Global.setWeakSet() is wrong. - It’s kinda too bad we can’t generalize those getters with lazy sentinel and builtin getters. I guess we could if they weren’t stored in fields. Sounds l

Re: RFR 8148926: Call site profiling fails on braces-wrapped anonymous function

+1 Am 2016-02-04 um 12:55 schrieb Sundararajan Athijegannathan: Please review http://cr.openjdk.java.net/~sundar/8148926/ for https://bugs.openjdk.java.net/browse/JDK-8148926 Thanks, -Sundar

Re: RFR 8148617: top level make docs target does not generate javadocs for dynalink API

+1 Am 2016-01-29 um 18:11 schrieb Sundararajan Athijegannathan: Added newline before line 1270 in Javadoc.gmk. Updated webrev: http://cr.openjdk.java.net/~sundar/8148617/webrev.01/ -Sundar On 1/29/2016 9:53 PM, Hannes Wallnoefer wrote: Looks good. Hannes Am 2016-01-29 um 17:13 schrieb

Re: RFR 8148617: top level make docs target does not generate javadocs for dynalink API

Looks good. Hannes Am 2016-01-29 um 17:13 schrieb Sundararajan Athijegannathan: Please review http://cr.openjdk.java.net/~sundar/8148617/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8148617 Dynalink API is specified by JEP-276 (http://openjdk.java.net/jeps/276). The current chang

Re: callback every x instruction

Hi Walid, We don't have plans for an instruction count/callback feature. One idea behind Nashorn is that it should be part of the Java platform instead just sitting on top of it. That also means it should make use of existing infrastructure and tools instead of providing a half-hearted versio

Re: RFR(M): 8147591: Revisit Collection.toArray(new T[size]) calls in nashorn and dynalink code

+1 I don't think it will have any measurable effect but it looks tidier anyway. Hannes Am 2016-01-28 um 10:49 schrieb Michael Haupt: Dear all, please review this change by Srinivas Dama, which I'm sponsoring. Bug: https://bugs.openjdk.java.net/browse/JDK-8147591 Webrev: http://cr.openjdk.java

Review request for backport of JDK-8146274: Thread spinning on WeakHashMap.getEntry() with concurrent use of nashorn

Please review backport of JDK-8146274. Webrev: http://cr.openjdk.java.net/~hannesw/8146274/webrev-8u/ Bug: https://bugs.openjdk.java.net/browse/JDK-8146274 The patch needed a small change because the key type of the listeners map changed. Also, the original patch included jjs documentation, whi

Review request for JDK-8148214 : Slow object allocation due to multiple synchronization

Please review JDK-8148214: Slow object allocation due to multiple synchronization: http://cr.openjdk.java.net/~hannesw/8148214/ Thanks, Hannes

Review request for JDK-8148040 : jjs -fx test does not exit

Please review JDK-8148040: jjs -fx test does not exit: http://cr.openjdk.java.net/~hannesw/8148040/webrev/ Thanks, Hannes

Re: RFR(XXS): 8134933: re-enable LambdaFormEditor assertions in Nashorn testing

+1 Am 2016-01-22 um 11:08 schrieb Michael Haupt: Dear all, please review this change. Task: https://bugs.openjdk.java.net/browse/JDK-8134933 Change: http://cr.openjdk.java.net/~mhaupt/8134933/webrev.00 These assertions can be re-enabled, especially given that Nashorn depends on JDK 9 to be bu

Re: Review request for JDK-8147845: Varargs Array functions still leaking longs

er is bit confusing. Too many toNumber overloads and a overload returning a different type... -Sundar On 1/21/2016 3:21 PM, Hannes Wallnoefer wrote: Please review JDK-8147845: Varargs Array functions still leaking longs: webrev: http://cr.openjdk.java.net/~hannesw/8147845/webrev/

Review request for JDK-8147845: Varargs Array functions still leaking longs

Please review JDK-8147845: Varargs Array functions still leaking longs: webrev: http://cr.openjdk.java.net/~hannesw/8147845/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8147845 Thanks, Hannes

Review request for backport of JDK-8143896: java.lang.Long is implicitly converted to double

Please review backport of JDK-8143896: java.lang.Long is implicitly converted to double: http://cr.openjdk.java.net/~hannesw/8143896/webrev-8u/ This builds on the JDK-8144020 backport which I posted earlier. Some manual merging was necessary in runtime/JSType.java and objects/NativeNumber.jav

Review request for backport of JDK-8144020: Remove long as an internal numeric type

Please review backport to 8u-dev of JDK-8144020: Remove long as an internal numeric type: http://cr.openjdk.java.net/~hannesw/8144020/webrev-8u/ There was some manual merging necessary in the following files: src/jdk/nashorn/internal/codegen/LocalVariableTypesCalculator.java src/jdk/nashorn/in

Review request for JDK-8147630: Wrong test result pushed to 8u-dev

In my previous backport to 8u-dev I applied the patch twice and not noticed new lines were added twice to test/script/basic/minuszero.js.EXPECTED. Please review: Webrev: http://cr.openjdk.java.net/~hannesw/8147630/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8147630 Thanks and sorry

Review request for backport of JDK-8144131: ArrayData.getInt implementations do not convert to int32

Please review backport to 8u-dev of JDK-8144131: ArrayData.getInt implementations do not convert to int32: http://cr.openjdk.java.net/~hannesw/8144131/webrev-8u/ This required manual merging of the import statements in NumberArray.java, otherwise the patch applied cleanly. Thanks, Hannes

Re: Review request for JDK-8133299: Nashorn Java adapters should not early bind to functions

Looks good. Wow, this must have been a lot of work! Am 2016-01-19 um 15:00 schrieb Attila Szegedi: Yes. If we want to backport, we’ll create an adjusted patch. FWIW, backporting would depend on backporting Hannes’ long removal too, as the generated bytecode now has logic compatible with that (

Re: Review request for JDK-8146274: Thread spinning on WeakHashMap.getEntry() with concurrent use of nashorn

t and decided that copying the weak maps is better than sharing WeakPropertyMapSet objects and making their methods synchronized. On Jan 15, 2016, at 12:49 PM, Hannes Wallnoefer wrote: Please review: Webrev: http://cr.openjdk.java.net/~hannesw/8146274/ Bug: https://bugs.openjdk.java.net/brows

Re: Review request for JDK-8146274: Thread spinning on WeakHashMap.getEntry() with concurrent use of nashorn

=returns a string representation this object ... should be "... of this object" Likewise, for +Function.prototype.toString=returns a string representation this function Best, Michael Am 15.01.2016 um 12:49 schrieb Hannes Wallnoefer mailto:hannes.wallnoe...@oracle.com>>: Please

Review request for JDK-8146274: Thread spinning on WeakHashMap.getEntry() with concurrent use of nashorn

Please review: Webrev: http://cr.openjdk.java.net/~hannesw/8146274/ Bug: https://bugs.openjdk.java.net/browse/JDK-8146274 I was not able to reproduce the issue although I tried my best to follow the instructions. However, it is pretty clear that the issue is that the cause for the concurrent m

Re: RFR(S): 8145305: fix Nashorn shebang handling on Cygwin

+1 Am 2016-01-15 um 11:31 schrieb Michael Haupt: Dear all, please review this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8145305 Webrev: http://cr.openjdk.java.net/~mhaupt/8145305/webrev.00/ It adapts the test for shebang handling so that it passes on Cygwin. Some documentation extens

Re: RFR(S): 8036977: Make process singleton options to be context wide

+1 Am 2016-01-14 um 10:37 schrieb Michael Haupt: Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8036977 Webrev: http://cr.openjdk.java.net/~mhaupt/8036977/webrev.00 The push solely consists of a test, as the original bug was fixed in an earlier push. Best,

Re: RFR 8147070: Dynalink GuardedInvocation must check the Class object passed

+1 Am 2016-01-14 um 10:21 schrieb Sundararajan Athijegannathan: Please review http://cr.openjdk.java.net/~sundar/8147070/ for https://bugs.openjdk.java.net/browse/JDK-8147070 Thanks, -Sundar

Re: Review request for JDK-8147008: Nashorn primitive linker should handle ES6 symbols

t see a separate JDK-8147008.js. You may want add a comment in that bug to refer to the bug. -Sundar On 1/14/2016 12:13 AM, Hannes Wallnoefer wrote: Please review JDK-8147008: Nashorn primitive linker should handle ES6 symbols: http://cr.openjdk.java.net/~hannesw/8147008/ Thanks, Hannes

Review request for JDK-8147008: Nashorn primitive linker should handle ES6 symbols

Please review JDK-8147008: Nashorn primitive linker should handle ES6 symbols: http://cr.openjdk.java.net/~hannesw/8147008/ Thanks, Hannes

Re: Review request for JDK-8143896: java.lang.Long is implicitly converted to double

a bug for this. hannes Attila. On Jan 12, 2016, at 10:33 AM, Hannes Wallnoefer wrote: I uploaded a new webrev without the changes to the parser API. http://cr.openjdk.java.net/~hannesw/8143896/webrev.03/ Note that parserapi.js.EXPECTED changes because of the changes in parserapi.js,

Review request for JDK-8146888: Wrong license headers in test files

Please review JDK-8146888: Wrong license headers in test files: http://cr.openjdk.java.net/~hannesw/8146888/webrev/ Thanks, Hannes

Re: Review request for JDK-8143896: java.lang.Long is implicitly converted to double

:57 schrieb Sundararajan Athijegannathan: As discussed offline, please leave Nashorn Parser API changes for a separate issue. -Sundar On 1/11/2016 8:07 PM, Hannes Wallnoefer wrote: I fixed a bug with converstion to number for the strict equality operator, which also revealed some left over usage

Re: Review request for JDK-8143896: java.lang.Long is implicitly converted to double

ver it was called). Since Nashorn does not use object wrappers, I think it would be hard to distinguish between primitive numbers and object wrappers in this way. It would als feel kind of arbitrary to me. Hannes Attila. On Jan 11, 2016, at 1:48 PM, Hannes Wallnoefer wrote: You are right

Re: Review request for JDK-8143896: java.lang.Long is implicitly converted to double

I fixed a bug with converstion to number for the strict equality operator, which also revealed some left over usage of long in Nashorn internals. New webrev is here: http://cr.openjdk.java.net/~hannesw/8143896/webrev.02/ Hannes Am 2016-01-11 um 13:48 schrieb Hannes Wallnoefer: You are right

Re: Review request for JDK-8143896: java.lang.Long is implicitly converted to double

problem -- we also have another (somewhat related) BigDecimal, BigInteger toString / String conversion issue. We need to discuss this. -Sundar On 1/2/2016 8:29 PM, Attila Szegedi wrote: +1 On Dec 18, 2015, at 3:54 PM, Hannes Wallnoefer wrote: Please review JDK-8143896: java.lang.Long is

Review request for JDK-8143896: java.lang.Long is implicitly converted to double

Please review JDK-8143896: java.lang.Long is implicitly converted to double http://cr.openjdk.java.net/~hannesw/8143896/webrev/ Thanks, Hannes

Re: RFR 8145750: jjs fails to run simple scripts with security manager turned on

Looks good. Some of the new test scripts have an incomplete @summary line, e.g. jjs-strictTest.sh: # @summary Test that output of 'jjs -strict' Hannes Am 2015-12-18 um 13:23 schrieb Sundararajan Athijegannathan: Please review http://cr.openjdk.java.net/~sundar/8145750/webrev.00/ for https://bu

Re: RFR 8145669: apply2call optimized callsite fails after becoming megamorphic

+1 Am 2015-12-17 um 13:28 schrieb Sundararajan Athijegannathan: Please review http://cr.openjdk.java.net/~sundar/8145669/ for https://bugs.openjdk.java.net/browse/JDK-8145669 Thanks, -Sundar

Re: RFR 8145630: accidental debug printlns in NativeFunction.java

+1 Am 2015-12-17 um 06:43 schrieb Sundararajan Athijegannathan: Please review http://cr.openjdk.java.net/~sundar/8145630/ for https://bugs.openjdk.java.net/browse/JDK-8145630 Thanks, -Sundar

Re: RFR 8145550: Megamorphic invoke should use CompiledFunction variants without any LinkLogic

Looks good. Am 2015-12-16 um 14:30 schrieb Sundararajan Athijegannathan: Please review http://cr.openjdk.java.net/~sundar/8145550/ for https://bugs.openjdk.java.net/browse/JDK-8145550 Thanks, -Sundar

Re: RFR 8145486: jjs should support documentation key shortcut in interactive mode

Added doc for NativeJavaPackage objects * Added missing "final" in Console.bind method. Incremental changes are only in Main.java and Console.java Please review.. -Sundar On 12/16/2015 2:48 PM, Hannes Wallnoefer wrote: Very nice, and works like a charm on Linux. One nit

Re: RFR 8145486: jjs should support documentation key shortcut in interactive mode

Very nice, and works like a charm on Linux. One nitpick: documentation for NativeObject.setIndexedPropertiesToExternalArrayData should start with "sets" rather than "set" to be consistent with the rest. Hannes Am 2015-12-16 um 05:38 schrieb Sundararajan Athijegannathan: Please review http://

Re: Use of long in Nashorn

I spent significant time testing this with octane and sunspider, and didn't find any regressions. Hannes Am 2015-12-15 um 09:55 schrieb Marcus Lagergren: All octane benchmarks and stuff like that run with no serious regressions, I hope? On 14 Dec 2015, at 17:30, Hannes Wallnoefer

Re: Use of long in Nashorn

For the record, I tried the integer index optimization for array iterators, but didn't really see a difference running a microbenchmark using Array.prototype.forEach, so I left it out after all. Hannes Am 2015-12-11 um 16:30 schrieb Hannes Wallnoefer: Am 2015-12-11 um 16:21 schrieb A

Re: RFR 8145314: jjs tab-completion should support camel case completion

+1 Am 2015-12-14 um 16:05 schrieb Sundararajan Athijegannathan: Please review http://cr.openjdk.java.net/~sundar/8145314/ for https://bugs.openjdk.java.net/browse/JDK-8145314 Thanks, -Sundar

Re: Review request for JDK-8144914: Eagerly lookup browser JS object class in BrowserJSObjectLinker

Sorry, I missed the intial request. +1 Hannes Am 2015-12-14 um 16:44 schrieb Attila Szegedi: 2nd review, please? On Tue, Dec 8, 2015 at 12:58 PM, Sundararajan Athijegannathan < sundararajan.athijegannat...@oracle.com> wrote: +1 -Sundar On 12/8/2015 5:23 PM, Attila Szegedi wrote: Pleas

Re: Use of long in Nashorn

Am 2015-12-11 um 16:21 schrieb Attila Szegedi: On Dec 11, 2015, at 4:08 PM, Hannes Wallnoefer wrote: I didn't implement the int/double overloading of array iterator actions. Unless I missed something, I would have to implement two forEach methods in each subclass, which seem ugly and

Review request for JDK-8144020: Remove long as an internal numeric type

Please review JDK-8144020: Remove long as an internal numeric type: http://cr.openjdk.java.net/~hannesw/8144020/webrev.01/ Attila already reviewed a previous version of this patch: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-December/005669.html This version contains most of the ch

Re: Use of long in Nashorn

patch. Hannes Am 2015-12-06 um 11:12 schrieb Hannes Wallnoefer: Thanks for the quick review, Attila. Answers inline. Am 2015-12-04 um 18:39 schrieb Attila Szegedi: * In CodeGenerator SHR implementations (both self-assign and ordinary) you have method.shr() in loadStack instead of consumeStack.

Re: RFR 8145186: jjs package completion should have a fallback when javac is not available

+1 "atleast" should be two words (in a comment) Hannes Am 2015-12-11 um 14:31 schrieb Sundararajan Athijegannathan: Please review http://cr.openjdk.java.net/~sundar/8145186/ for https://bugs.openjdk.java.net/browse/JDK-8145186 Thanks, -Sundar

  1   2   3   4   5   6   7   8   9   >