Resigning as OpenJDK Nashorn Project Lead

I hereby resign as Nashorn Project Lead. Nashorn [1] started in 2010 as a small JavaScript prototype to fill in for the discontinued JavaFX compiler project [2] and as a testing ground for Java's "new" invoke dynamic instructions [3]. Though Nashorn became somewhat a niche tool, it found

Re: RFR 8246113: re-visit javax/script test that still requires jdk.scripting.nashorn module

+1 > On Jul 15, 2020, at 12:58 PM, sundararajan.athijegannat...@oracle.com wrote: > > Hi, > > Please review - removing these tests. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8246113 > > Webrev: http://cr.openjdk.java.net/~sundar/8246113/webrev.00/ > > Thanks > > -Sundar >

Re: JDK-8229011: Workaround?

Not sure if it will help but you could try the "--optimistic-types=false" option. > On Jun 9, 2020, at 6:22 AM, STAMPF Lukas wrote: > > Hello, > > I wanted to ask if there is any workaround for the memory leak described in > https://bugs.openjdk.java.net/browse/JDK-8229011 > > Unfortunatly

Re: Bug in extractVarNodesFromDeadCode. Variable "x" has already been declared

Obviously, this wasn't intended for the list. To clarify, since Nashorn is being deprecated, we are taking input such as this and recording it as a bug in case someone adopts Nashorn in future. Cheers, -- Jim > On Oct 28, 2019, at 12:36 PM, Jim Laskey wrote: > > You wan

Re: Bug in extractVarNodesFromDeadCode. Variable "x" has already been declared

You want to take this on? File a bug and put the e-mail (change set) in it, then tell the user Nashorn is deprecated. > On Oct 28, 2019, at 12:21 PM, Anton Mitrofanov wrote: > > Hi. > > We have encountered another bug in Nashorn. It can be reproduced by > evaluation of this script with "jjs

Re: JDK 14 RFR of JDK-8231557: Suppress warnings on non-serializable instance fields in jdk.scripting.nashorn module

+1 > On Sep 26, 2019, at 7:45 PM, Joe Darcy wrote: > > Hello, > > Another part of an on-going cleanup of library serialization usage ahead of > augmented javac -Xlint warnings (JDK-8160675), the non-serializable instance > fields of serializable types in the jdk.scripting.nashorn module

Re: RFR: 8223451: Make optimistic types disabled by default

+1 > On Jul 9, 2019, at 11:48 AM, Hannes Wallnöfer > wrote: > > Please review: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8223451 > Webrev: http://cr.openjdk.java.net/~hannesw/8223451/webrev.00/ > > A lot of Nashorn usage we see is with command line scripts from the Node.js > and Web

Re: (Adopt)OpenJDK 8 and Nashorn

Nashorn is part of the JDK, so should be present. Note however, Nashorn is deprecated until a replacement finds its way in. Cheers, -- Jim > On May 23, 2019, at 9:48 AM, Houtman, Roland > wrote: > > Dear Devs, > > Today I learned by surprise that the AdoptOpenJDK 8 contains the Nashorn >

Re: RFR: 8214795: Add safety check to dynalink inner class lookup

Wouldn’t you still use innerClasses.putIfAbsent in case there is a race? > On Dec 5, 2018, at 10:33 AM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214795 > Webrev: http://cr.openjdk.java.net/~hannesw/8214795/webrev.00/ > > This is to make

Re: RFR: 8214525: Bit rot in Nashorn Ant script

+1 too bad you have to hardcode the version > On Nov 30, 2018, at 6:58 AM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214525 > Webrev: http://cr.openjdk.java.net/~hannesw/8214525/webrev.00/ > > This enables gzip encoding for the YUI

Re: RFR: 8210943: Hiding of inner classes not resolved properly

+1 > On Nov 29, 2018, at 1:01 PM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210943 > Webrev: http://cr.openjdk.java.net/~hannesw/8210943/webrev.00/ > > AccessibleMembersLookup#lookupAccessibleMembers adds all nested classes > returned

Re: Supporting TypeScript natively on Nashorn

The Nashorn team has no plans but you might check the GraalVM https://www.graalvm.org project to see what they might have in this area. Cheers, — Jim > On Aug 9, 2018, at 7:01 AM, Erko Knoll wrote: > > Hi, > > Great job with Nashorn, I really love it. However, based on the blog post > of >

Re: RFR 8204492 Add deprecation annotation to Nashorn APIs and warning to nashorn, jjs

+1 > On Jun 27, 2018, at 1:16 AM, Sundararajan Athijegannathan > wrote: > > Please review. > > Bug https://bugs.openjdk.java.net/browse/JDK-8204492 > Webrev http://cr.openjdk.java.net/~sundar/8204492/webrev.01 > > Related: > > JEP http://openjdk.java.net/jeps/335 > CSR

Re: RFR: 8204290: Add check to limit number of capture groups

+1 > On Jun 5, 2018, at 9:44 AM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8204290 > Webrev: http://cr.openjdk.java.net/~hannesw/8204290/webrev/ > > This (like the previous RFR) is another backport from jruby/joni. > > Thanks, > Hannes

Re: RFR: 8204288: Matching the end of a string followed by an empty greedy regex and a word boundary fails

+1 > On Jun 4, 2018, at 1:42 PM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8204288 > Webrev: http://cr.openjdk.java.net/~hannesw/8204288/webrev/ > > Thanks, > Hannes >

Re: RFR: 8200716: Object propertyIsEnumerable buggy behavior on short integer-string key

+1 > On May 7, 2018, at 1:40 PM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200716 > Webrev: http://cr.openjdk.java.net/~hannesw/8200716/webrev/ > > Thanks, > Hannes

Re: RFR: 8198816: AbstractScriptEngine.getScriptContext creation of SimpleScriptContext is inefficient

+1 > On Apr 23, 2018, at 12:34 PM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198816 > Webrev: http://cr.openjdk.java.net/~hannesw/8198816/webrev/ > > Thanks, > Hannes

Re: RFR: 8201466: Nashorn: defineProperty setters/getters on prototype object ignored with numeric property names

+1 > On Apr 23, 2018, at 10:49 AM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8201466 > Webrev: http://cr.openjdk.java.net/~hannesw/8201466/webrev/ > > Thanks, > Hannes

Re: RFR 8200215: 17th loop of "let foo = ''"; throws ReferenceError

+1 > On Mar 26, 2018, at 9:00 AM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8200215/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8200215 > > Thanks, > -Sundar

Re: RFR: 8199443: Nashorn multithread bottleneck with "use strict"

+1 > On Mar 15, 2018, at 10:30 AM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199443 > Webrev: http://cr.openjdk.java.net/~hannesw/8199443/webrev/ > > If we make sure the property maps for strict functions

Re: RFR: 8199236: Nashorn uses deprecated HTML tags in Javadoc

+1 > On Mar 7, 2018, at 1:08 PM, Hannes Wallnöfer > wrote: > > Please review 8199236: Nashorn uses deprecated HTML tags in Javadoc: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199236 > Webrev: http://cr.openjdk.java.net/~hannesw/8199236/webrev/ > >

Re: RFR: 8196959: NullPointerException in discovery003.java

+1 > On Feb 14, 2018, at 1:24 AM, Srinivas Dama wrote: > > Jim, > > May I have second review for this thread in core-libs-dev group. > > Regards, > Srinivas > > - Forwarded Message - > From: sundararajan.athijegannat...@oracle.com > To:

Re: RFR: 8147614: add jjs test for -t option

+1 > On Jan 23, 2018, at 2:34 AM, Priya Lakshmi Muthuswamy > wrote: > > Hi, > > Kindly review JDK-8147614: add jjs test for -t option > > JBS: https://bugs.openjdk.java.net/browse/JDK-8147614 > webrev:

Re: RFR 8195829 Parsing a nameless ES6 class results in a thrown NullPointerException.

+1 > On Jan 22, 2018, at 10:44 AM, Sundararajan Athijegannathan > wrote: > > Please review. > > Webrev: http://cr.openjdk.java.net/~sundar/8195829/webrev.00/index.html > Bug: https://bugs.openjdk.java.net/browse/JDK-8195829 > > Thanks, > -Sundar

Re: RFR: 8195123: Very large regressions in Octane benchmarks using 10-b39

+1 > On Jan 17, 2018, at 11:36 AM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8195123 > Webrev: http://cr.openjdk.java.net/~hannesw/8195123/webrev.00/ > > This undoes the recent fix for JDK-8193567 (Attila,

Re: RFR: 8193567: Conversion of comparison nodes affects local slots in optimistic continuation

+1 > On Dec 21, 2017, at 11:36 AM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193567 > Webrev: http://cr.openjdk.java.net/~hannesw/8193567/webrev.00/ > > I’ve tried finding a smaller fix like just tagging the

Re: RFR: 8193508: Expressions in split literals must never be optimistic

+1 > On Dec 14, 2017, at 1:38 PM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193508 > Webrev: http://cr.openjdk.java.net/~hannesw/8193508/webrev.00/ > > The actual fix is quite simple: stop visiting when we

Re: RFR:8193491:JavaImporter fails to resolve method elements within functions, that contain too many statements

+1 > On Dec 20, 2017, at 10:01 AM, Priya Lakshmi Muthuswamy > wrote: > > Removed __noSuchProperty__ methods in NativeJavaImporter > > updated webrev : http://cr.openjdk.java.net/~pmuthuswamy/8193491/webrev.01/ > > Thanks, > Priya > On 12/20/2017 11:41

Re: Review request for JDK-8192970: Element getters/setters with fixed key fail to link properly

Please wait for Sundar > On Dec 6, 2017, at 3:52 PM, Attila Szegedi wrote: > > Is it okay to commit this with one +1 or should I wait for another approval? > > Thanks, > Attila. > >> On 2017. Dec 4., at 16:36, Hannes Wallnöfer >> wrote: >>

Re: RFR: 8191891: Update minumum Ant version in Nashorn build.xml

+1 > On Nov 28, 2017, at 10:26 AM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191891 > Webrev: http://cr.openjdk.java.net/~hannesw/8191891/webrev.00/ > > Thanks, > Hannes

Re: RFR: 8059835: Optimistic splitting doesn't work with let and const

+1 > On Nov 28, 2017, at 10:03 AM, Hannes Wallnöfer > wrote: >

Re: RFR 8191771: nashorn ant makefile uses javadoc -link which may fail

+1 > On Nov 22, 2017, at 12:43 PM, Sundararajan Athijegannathan > wrote: > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191771 > Webrev: http://cr.openjdk.java.net/~sundar/8191771/webrev.00/ > > Thanks, > -Sundar

Re: RFR 8191468: jdk.scripting.nashorn.shell (jjs) module should use optional dependency for java.compiler module

+1 > On Nov 17, 2017, at 5:16 AM, Hannes Wallnöfer > wrote: > > Looks good! > > Hannes > >> Am 17.11.2017 um 07:30 schrieb Sundararajan Athijegannathan >> : >> >> Please review. >> >> Bug:

Re: RFR 8191306: Math.abs corner case with optimistic typing

+1 > On Nov 15, 2017, at 9:22 AM, Sundararajan Athijegannathan > wrote: > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191306 > Webrev: http://cr.openjdk.java.net/~sundar/8191306/webrev.00/index.html > > Thanks > -Sundar

Re: RFR: 8191133: Ant task to fetch underscore.js requires gzip decoding option

+1 > On Nov 14, 2017, at 5:28 AM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191133 > Webrev: http://cr.openjdk.java.net/~hannesw/8191133/webrev/ > > Thanks, > Hannes

Re: RFR: 8185119: Uninitialized const when using multiple threads

+1 > On Nov 13, 2017, at 1:25 PM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8185119 > Webrev: http://cr.openjdk.java.net/~hannesw/8185119/webrev/ > > Thanks, > Hannes

Re: RFR: 8191131: Nashorn test comparator breaks comparator contract

+1 > On Nov 13, 2017, at 12:49 PM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191131 > Webrev: http://cr.openjdk.java.net/~hannesw/8191131/webrev/ > > Thanks, > Hannes

Re: RFR: 8190427 : Test for JDK-8165198 fails intermittently because of GC

+1 > On Nov 7, 2017, at 8:45 AM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190427 > Webrev: http://cr.openjdk.java.net/~hannesw/8190427/webrev.02/ > > This started as simple bug fix but turned into a full

Re: RFR 8190795: jjs should show javadoc for java methods on shift-tab

+1 > On Nov 6, 2017, at 10:37 AM, Sundararajan Athijegannathan > wrote: > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190795 > Webrev: http://cr.openjdk.java.net/~sundar/8190795/webrev.00/ > > Piggybacking refactoring of other

Re: RFR 8190698: jjs tool of jdk.scripting.nashorn.shell module should not statically depend on java.desktop

+1 Does jshell have similar dependencies? > On Nov 3, 2017, at 6:10 AM, Sundararajan Athijegannathan > wrote: > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190698 > Webrev: http://cr.openjdk.java.net/~sundar/8190698/webrev.00 >

Re: RFR: 8189617: Remove undocumented --print-mem-usage option

+1 > On Oct 19, 2017, at 7:32 AM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8189617 > Webrev: http://cr.openjdk.java.net/~hannesw/8189617/webrev.00/ > > Thanks, > Hannes

Re: RFR: 8068513: Adding elements to a javascript 'object' (a map) is slow

+1 > On Oct 13, 2017, at 11:25 AM, Hannes Wallnöfer > wrote: > > I uploaded a new webrev, please review: > > http://cr.openjdk.java.net/~hannesw/8068513/webrev.02/ > > Changes to previous webrev: > > - updated to consolidated repository layout > - fixed typos

Re: RFR: 8027302: Identifiers containing unicode escapes are not recognized as reserved words

+1 > On Oct 13, 2017, at 5:36 AM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8027302 > Webrev: http://cr.openjdk.java.net/~hannesw/8027302/webrev.01 > > ES6 and ES5 require different handling regarding

Re: RFR:8147076(LinkerCallSite.ARGLIMIT is used incorrectly)

+1 > On Sep 29, 2017, at 11:33 AM, Srinivas Dama wrote: > > Hi Hannes, > > Thank you for the comments > > -Modified test case already covers both > ARGLIMIT and with double). > I have added a new test case for double arguments.anyway,I will modify the > test as you

Re: RFR 8180274: Fix links in nashorn documentation

+1 > On Sep 29, 2017, at 1:56 AM, Sundararajan Athijegannathan > wrote: > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8180274 > Webrev: http://cr.openjdk.java.net/~sundar/8180274/webrev.00/ > > Thanks, > -Sundar

Re: RFR 8188098: NPE in SimpleTreeVisitorES6 visitor when parsing a tagged template literal

+1 > On Sep 28, 2017, at 1:38 PM, Sundararajan Athijegannathan > wrote: > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8188098 > Webrev: http://cr.openjdk.java.net/~sundar/8188098/webrev.00/ > > Thanks, > -Sundar

Re: RFR 8188082: autoimports.js sample is broken

+1 > On Sep 28, 2017, at 2:37 AM, Sundararajan Athijegannathan > wrote: > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8188082 > Webrev: http://cr.openjdk.java.net/~sundar/8188082/webrev.00/ > > PS. Piggybacking to push another

Re: RFR: 8186815: Java.from has a bug, when element is ScriptObject

+1 > On Sep 27, 2017, at 11:44 AM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8186815 > Webrev: http://cr.openjdk.java.net/~hannesw/8186815/webrev/ > > Thanks, > Hannes

Re: RFR 8188023: Avoid -source and -target javac options in nashorn ant compilation

+1 > On Sep 27, 2017, at 8:59 AM, Sundararajan Athijegannathan > wrote: > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8188023 > Webrev: http://cr.openjdk.java.net/~sundar/8188023/webrev.00/index.html > > Piggybacking to take

Re: RFR 8187965: dynalink samples under $jdk10/src/sample/nashorn/dynalink are broken

+1 nicer too > On Sep 26, 2017, at 10:58 AM, Sundararajan Athijegannathan > wrote: > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187965 > > Webrev: http://cr.openjdk.java.net/~sundar/8187965/webrev.00/ > > Dynalink samples

Re: RFR 8187934: dropping a shebang script in src/sample/nashorn directory results in test failure

+1 > On Sep 25, 2017, at 11:15 AM, Sundararajan Athijegannathan > wrote: > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187934 > Webrev: http://cr.openjdk.java.net/~sundar/8187934/webrev.00/ > > PS. Piggybacking a sample script

Re: RFR: 8186646: Nashorn: "duplicate code" assertion when binding a vararg function that just passes arguments along

+1 > On Sep 21, 2017, at 7:22 AM, Hannes Wallnöfer > wrote: > > Please review 8186646: Nashorn: "duplicate code" assertion when binding a > vararg function that just passes arguments along > > Bug: https://bugs.openjdk.java.net/browse/JDK-8186646 > Webrev:

Re: RFR 8187782: no ant build artifact should be produced under make/nashorn directory

+1 Too bad there isn’t any refactoring tools for this sort of thing. > On Sep 21, 2017, at 9:06 AM, Sundararajan Athijegannathan > wrote: > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187782 > Webrev:

Re: RFR 8187773: nashorn ant javadoc, nashornapi, dynalinkapi, run, debug, octane, sunspider targets fail

+1 > On Sep 21, 2017, at 4:19 AM, Sundararajan Athijegannathan > wrote: > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187773 > Webrev: http://cr.openjdk.java.net/~sundar/8187773/webrev.00/ > > Thanks, > -Sundar

Re: RFR:8181792:nashorn samples/exec.js has some incorrect examples

+1 > On Sep 8, 2017, at 6:42 AM, Priya Lakshmi Muthuswamy > wrote: > > Removed the redundant example(ls -l -a). > > Updated patch : http://cr.openjdk.java.net/~pmuthuswamy/8181792/webrev.01/ > > Thanks, > Priya > > On 9/8/2017 2:25 PM, Priya Lakshmi

Re: RFR:8169233:LengthNotWritableFilter extraElements.remove(index) has no effect

+1 > On Sep 1, 2017, at 1:32 AM, Priya Lakshmi Muthuswamy > wrote: > > Hi, > > Please review JDK-8169233 : LengthNotWritableFilter: > extraElements.remove(index) has no effect > > JBS: https://bugs.openjdk.java.net/browse/JDK-8169233 > webrev :

Re: RFR:8177691:Labeled break in catch and finally works wrongly, when invoked through nashorn

+1 > On Aug 29, 2017, at 10:55 AM, Srinivas Dama wrote: > > Hi, > > > > Please review http://cr.openjdk.java.net/~sdama/8177691/webrev.00/ > > for https://bugs.openjdk.java.net/browse/JDK-8177691 > > > > Regards, > > Srinivas

Re: RFR:8073640:Nashorn scripting: here document with only whitespace gives error

+1 > On Aug 31, 2017, at 8:01 AM, Hannes Wallnöfer > wrote: > > +1 > > Does this change behaviour for non-empty strings? > > Hannes > >> Am 31.08.2017 um 10:51 schrieb Srinivas Dama : >> >> Hi, >> >> Please review

Re: [10] RFR: 8184893: jdk8u152 b06 : issues with nashorn when running kraken benchmarks

+1 > On Jul 25, 2017, at 10:44 AM, Hannes Wallnöfer > wrote: > > Please review 8184893: jdk8u152 b06 : issues with nashorn when running kraken > benchmarks > > Kraken benchmark contains some files that invokes the Array constructor with > lots of number

Re: RFR: 8180727(Use jdk.editpad to replace jdk.nashorn.tools.jjs.EditPad duplicated class)

+1 > On Jul 25, 2017, at 10:54 AM, Srinivas Dama wrote: > > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8180727/webrev.00/ > > for https://bugs.openjdk.java.net/browse/JDK-8180727 > > > > Regards, > > Srinivas

Re: RFR: 8184241(Fix nashorn/samples/filebrowser.js)

Forgot. +1 > On Jul 19, 2017, at 5:45 AM, Srinivas Dama wrote: > > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8184241/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8184241. > > Regards, > Srinivas

Re: RFR: 8184239(Fix broken nashorn/samples)

+1 > On Jul 12, 2017, at 3:41 PM, Srinivas Dama <srinivas.d...@oracle.com> wrote: > > Hi, > > Please review the updated patch. Sorry I missed one sample earlier. > http://cr.openjdk.java.net/~sdama/8184239/webrev.01/ > > Regards, > Srinivas > > -O

Re: RFR: 8184239(Fix broken nashorn/samples)

+1 > On Jul 12, 2017, at 6:00 AM, Srinivas Dama wrote: > > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8184239/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8184239 > > Regards, > Srinivas

Re: RFR: 8182996: Incorrect mapping Long type to JavaScript equivalent

+1 > On Jun 28, 2017, at 10:34 AM, Hannes Wallnöfer > wrote: > > Please review 8182996: Incorrect mapping Long type to JavaScript equivalent: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8182996 > Webrev: http://cr.openjdk.java.net/~hannesw/8182996/webrev/ >

Re: RFR: 8181105: Nashorn file descriptor leaks

+1 > On Jun 21, 2017, at 10:13 PM, Andrey Nazarov > wrote: > > Hi, > > Please review fix for 8181105 > Webrev: http://cr.openjdk.java.net/~anazarov/JDK-8181105/webrev.00/webrev/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8181105 > > > —Andrei

Re: RFR (10): JDK-8181191: getUint32 returning Long

+1 > On Jun 13, 2017, at 12:51 PM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8181191 > Webrev: http://cr.openjdk.java.net/~hannesw/8181191/webrev/ > > Thanks, > Hannes

Re: Pass js array to a Java method pointer

d your solution and it works. but it needs to > invoke java method so it's more complex. After all, what's the different > between f1, f2 and f4. > > 2017年5月17日 上午2:28，"Jim Laskey (Oracle)" <james.las...@oracle.com>写道： > It could have inferred that you meant to pas

Re: Pass js array to a Java method pointer

It could have inferred that you meant to pass in a single element object array. Nashorn needs a bit more to determine that you wanted to convert to an java object array. System.out.println(nashorn.eval("var ObjectArray = Java.type('java.lang.Object[]'); f4(Java.to([1,2],

Re: RFR: 8179891: JavaDoc for for..in is incorrect

+1 > On May 11, 2017, at 6:00 AM, Srinivas Dama wrote: > > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8179891/webrev.00/index.html > for > https://bugs.openjdk.java.net/browse/JDK-8179891 > > Regards, > Srinivas

Re: Nashorn Parser API Javadoc

Will file a bug. — Jim > On May 8, 2017, at 4:01 AM, Dai Conrad wrote: > > I was looking at the parser API and I noticed that in the class > ForOfLoopTree, the methods getStatement() and getVariable() > have the following javadoc, respectively: > >The statement

Running JS code on a server

From: Eliezer Julian > Subject: Running JS code on a server Date: May 1, 2017 at 6:28:05 AM ADT To: "nashorn-dev@openjdk.java.net "

Re: how to help with ES6 features

If we can get more people involved, maybe I should come up with some scheme of free Nashorn t-shirts for those people that contribute code. :-) > On Apr 27, 2017, at 9:07 AM, Paulo Lopes wrote: > > I can make it work with nashorn. Currently it does run on nashorn jdk8 plus

Re: Exception while using ES6 features (template strings) with Nashorn on JDK 9

You need to specify --language=es6 on the command line > On Apr 26, 2017, at 10:25 AM, Mohammed Sanaulla wrote: > > Hello All, > > I am using build b166 of JDK 9. > > And I tried to run the following code: > > ScriptEngineManager engineManager = new

Re: RFR 8179304: Please review minor changes to doc comments

+1 > On Apr 25, 2017, at 10:32 PM, Jonathan Gibbons > wrote: > > Please review these minor changes to make the doc comments HTML5 compliant. > > Mostly, the changes are about changing to or {@code} tags. > > There is one minor adjustment to the text content --

Re: RFR 8178954: jjs uses wrong javadoc base URL

+1 > On Apr 19, 2017, at 1:43 AM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8178954/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8178954 > > Thanks, > -Sundar

Re: Can we define a method name alias when using a Java object/class form Nashorn?

You might consider using an ordinary JS object to wrap the Java Promise Object. Even though the wrapper exists, the indirection should eventually optimize out (more so than for JSObject.) As far as having more objects about, I think it’s small relative to other objects in the background

Re: Efficiency of context-per-thread on shared engine vs. engine + context per thread?

From basic experience I found that using a single engine, using JavaScript code to create the new threads and using loadWithNewGlobal to start each thread gave the best overall performance. - Jim > On Feb 27, 2017, at 7:58 AM, Frantzius, Jörg > wrote: > > Hi, >

Re: Getting Input From User

>> jjs -scripting jjs> var name = readLine("Your name >> "); Your name >> Jim jjs> print(name) Jim That sort of thing? — Jim > On Feb 25, 2017, at 5:24 AM, Koray wrote: > > Hello, > > I apologize if this is not the place to ask, but I couldn't get a > satisfying answer

Re: RFR of JDK-8174699: Fix @since in module-info.java in dev/nashorn repo

+1 Go ahead and push. > On Feb 9, 2017, at 11:43 PM, Hamlin Li wrote: > > Would you please review the below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8174699 > > webrev: http://cr.openjdk.java.net/~mli/8174699/webrev.00/ > > > Thank you > > -Hamlin >

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

+1 > On Feb 3, 2017, at 7:37 AM, Hannes Wallnöfer > wrote: > > 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

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

+1 > On Jan 30, 2017, at 6:22 AM, Hannes Wallnöfer > wrote: > > Please review 8173480: in operator should work on java objects and classes. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8173480 > Webrev:

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

+1 > On Jan 25, 2017, at 12:45 PM, Hannes Wallnöfer > wrote: > > >> Am 25.01.2017 um 17:39 schrieb Attila Szegedi : >> >> Well, filterInternalObjects itself doesn’t change the method handle type. I >> guess what happens is that the delegate

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

+1 > On Jan 24, 2017, at 4:56 AM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8173257/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8173257 > > Thanks, > -Sundar

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

+1 > On Jan 10, 2017, at 10:50 AM, Hannes Wallnöfer > wrote: > > 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 >

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

+1 > On Jan 10, 2017, at 4:45 AM, Sundararajan Athijegannathan > wrote: > > 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 of

Re: Minor discepancy for multiline regexps

Bug filed on your behalf. https://bugs.openjdk.java.net/browse/JDK-8172353 — Jim > On Jan 6, 2017, at 7:27 AM, Esben Andreasen wrote: > > Hi > > I stumbled upon a minor discrepancy between Nashorn and other > JavaScript

Re: RFR 8164391: Provide a javadoc description for jdk.scripting.nashorn

+1 > On Jan 4, 2017, at 7:25 AM, Attila Szegedi wrote: > > +1 > >> On 04 Jan 2017, at 11:40, Sundararajan Athijegannathan >> wrote: >> >> Please review http://cr.openjdk.java.net/~sundar/8164391/webrev.00/ for >>

Re: RFR 8172183: Provide a javadoc description for jdk.dynalink module

+1 > On Jan 3, 2017, at 1:17 AM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8172183/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8172183 > > Piggybacking couple of README cleanups in nashorn

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

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

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

+1 > On Dec 22, 2016, at 11:18 AM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166187 > Webrev: http://cr.openjdk.java.net/~hannesw/8166187/webrev/ > > It was actually the combination of having a

Re: RFR: 8170977: SparseArrayData should not grow its underlying dense array data

+1 > On Dec 22, 2016, at 11:15 AM, Hannes Wallnöfer > wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170977 > Webrev: http://cr.openjdk.java.net/~hannesw/8170977/webrev/ > > With this we keep whatever is already allocated as dense

Re: RFR 8171503: Nashorn build, test failures with the latest jdk9-dev forest - javadoc target and test target fail

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

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

+1 > On Dec 15, 2016, at 6:48 AM, Hannes Wallnöfer > wrote: > > 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

Re: Can't get Multithreaded Nashorn uses to Scale

"\"level\": 30,\n" + > "\"expPoints\": 0,\n" + > "\"infPoints\": 412616,\n" + > "\"revisionDate\": 1480771055000\n" + > " },\n&q

Re: Can't get Multithreaded Nashorn uses to Scale

k.nashorn.internal.runtime.arrays.DeletedArrayFilter > which just keeps growing forever. > > On Tue, Dec 6, 2016 at 6:30 AM, Jim Laskey (Oracle) <james.las...@oracle.com > <mailto:james.las...@oracle.com>> wrote: > >> On Dec 6, 2016, at 9:56 AM, Jesus Luzon <jlu...

Re: Can't get Multithreaded Nashorn uses to Scale

ter 8 threads. If it’s a 2x4 core machine then I can see 4 being a threshold depending on System performance. Transport: I meant if you were using sockets to provide the script. In your example, pull up Invocable invocable = generateInvocable(script); out of the loop and use the same i

Re: Can't get Multithreaded Nashorn uses to Scale

rate from each > other. Of course there are many factors involved n performance. How many cores do you have on the test machine? How much memory in the process? What transport are you using between threads? That sort of thing. Other than constructing then engine and context Nashorn performance

Re: Can't get Multithreaded Nashorn uses to Scale

Jesus, Probably the most informative information is in this blog. https://blogs.oracle.com/nashorn/entry/nashorn_multi_threading_and_mt This example uses Executors but threads would work as well. I did a talk that looked

Re: Review request for JDK-8170594: >>>=0 generates invalid bytecode for BaseNode LHS

+1 > On Dec 1, 2016, at 9:19 AM, Attila Szegedi wrote: > > Please review JDK-8170594 ">>>=0 generates invalid bytecode for BaseNode LHS" > at for > > > Thanks, >

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

+1 > On Dec 1, 2016, at 8:48 AM, Sundararajan Athijegannathan > wrote: > > Good catch Hannes! Please review the updated webrev : > http://cr.openjdk.java.net/~sundar/8170565/webrev.01/ > > PS. Had to use Function.prototype.call.call to pass undefined

  1   2   3   4   >