From sundararajan.athijegannathan at oracle.com Wed Jun 1 04:40:38 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 1 Jun 2016 10:10:38 +0530 Subject: "not an object" In-Reply-To: References: Message-ID: <9af5d5d2-a8f7-9083-ff5f-325980f486d7@oracle.com> Hi, Java objects are treated "as is" in nashorn. i.e., Nashorn uses wrapperless Java object access. So, Java objects are *not* ECMAScript objects. Dynamic property addition, prototype manipulation etc. won't work on Java objects. But, you can create a helper ECMAScript object whose properties are bound to the properties of a Java object. You can use Object.bindProperties extension for this [ https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-Object.bindProperties ] Example: var props = java.lang.System.properties; var obj = Object.bindProperties({}, props); // create a new script object and bind it's properties to that of Java object Object.getOwnPropertyNames(obj).forEach(function(val) { print(val) }); Note that Java Maps are treated as 'special' in that keys can be used as properties. [ https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-JavaMapkeysasproperties ] That also could be used to provide script friendly return object from your Java code. Hope this helps, -Sundar On 6/1/2016 1:53 AM, yikes aroni wrote: > So from a javascript function i call a java method that returns a java > object. What gets returned is not a simple bean. It has properties and > methods on it. > > var xxx = MyJavaClass.getMeSomething(); > > The *typeof* xxx is "object" according to Nashorn. However, when i try to > do things with it -- as if it were a Javascript object -- I get the message > > TypeError: testSample is not an Object > > Is there something specific i need to do to be able to manipulate xxx as a > javascript object? For example, I want to be able to add properties and > functions to it > > xxx['someProp'] = 3.14; > xxx['someFn'] = function() { > print('hello!'); > } > > I want to be able to get stuff from it > > Object.getOwnPropertyNames(xxx).forEach(function(val) { print(val) }); > > Stuff like that... but i can't because it's not seen as a native JS > "object" > > thanks. I hope i am clear. From sundararajan.athijegannathan at oracle.com Wed Jun 1 06:46:21 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 1 Jun 2016 12:16:21 +0530 Subject: RFR(S) 8158338: Nashorn's ScriptLoader split delegation has to adjusted Message-ID: <488d5d5f-b843-0727-da9d-67e3072390e9@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8158338/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8158338 Thanks, -Sundar From marcus at lagergren.net Wed Jun 1 07:17:13 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Wed, 1 Jun 2016 09:17:13 +0200 Subject: RFR 8158250: nashorn ant javadoc targets are broken In-Reply-To: <03781f02-5423-1048-1772-7aae89f96d3a@oracle.com> References: <03781f02-5423-1048-1772-7aae89f96d3a@oracle.com> Message-ID: +1 > On 31 May 2016, at 17:00, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8158250/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8158250 > > Thanks, > > -Sundar > From marcus at lagergren.net Wed Jun 1 07:19:15 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Wed, 1 Jun 2016 09:19:15 +0200 Subject: RFR(S) 8158338: Nashorn's ScriptLoader split delegation has to adjusted In-Reply-To: <488d5d5f-b843-0727-da9d-67e3072390e9@oracle.com> References: <488d5d5f-b843-0727-da9d-67e3072390e9@oracle.com> Message-ID: <2EECF93D-D948-4643-9E74-7E982BCCA772@lagergren.net> This looks good. Is it possible to test it? /M > On 01 Jun 2016, at 08:46, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8158338/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8158338 > > Thanks, > > -Sundar > From sundararajan.athijegannathan at oracle.com Wed Jun 1 07:29:12 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 1 Jun 2016 12:59:12 +0530 Subject: RFR(S) 8158338: Nashorn's ScriptLoader split delegation has to adjusted In-Reply-To: <2EECF93D-D948-4643-9E74-7E982BCCA772@lagergren.net> References: <488d5d5f-b843-0727-da9d-67e3072390e9@oracle.com> <2EECF93D-D948-4643-9E74-7E982BCCA772@lagergren.net> Message-ID: <51c5b6bc-1836-e7cb-1783-686995c82d64@oracle.com> Hi, Thanks for the review. We have an existing test that depends on "split" delegation implemented in the ScriptLoader. http://hg.openjdk.java.net/jdk9/dev/nashorn/file/7fb2bf00347b/test/script/basic/JDK-8024619.js The current code adjustment is about which loader is "parent" and which one "side" delegatee. Previously, parent was Context's appLoader and side-delegatee was the structure loader. Now, it is other way around. But, the behavior seen from scripts should remain same in either case. The aforementioned test (along with other nashorn tests) passes with the adjusted delegation setup as well. -Sundar On 6/1/2016 12:49 PM, Marcus Lagergren wrote: > This looks good. Is it possible to test it? > > /M > >> On 01 Jun 2016, at 08:46, Sundararajan Athijegannathan wrote: >> >> Please review http://cr.openjdk.java.net/~sundar/8158338/webrev.00/ for >> https://bugs.openjdk.java.net/browse/JDK-8158338 >> >> Thanks, >> >> -Sundar >> From sundararajan.athijegannathan at oracle.com Wed Jun 1 09:14:37 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 1 Jun 2016 14:44:37 +0530 Subject: RFR(S) 8158338: Nashorn's ScriptLoader split delegation has to adjusted In-Reply-To: <51c5b6bc-1836-e7cb-1783-686995c82d64@oracle.com> References: <488d5d5f-b843-0727-da9d-67e3072390e9@oracle.com> <2EECF93D-D948-4643-9E74-7E982BCCA772@lagergren.net> <51c5b6bc-1836-e7cb-1783-686995c82d64@oracle.com> Message-ID: I had to update webrev to handle the case of appLoader being null in ScriptLoader. I had used Class.forName(String, boolean, ClassLoader). But that methods introduces a security check when caller is not bootstrap (like nashorn) and ClassLoader is null! In any case, bootloader delegation has already happened via parent delegation. So, I'm checking and handling appLoader null case by throwing ClassNotFoundException. Updated webrev: http://cr.openjdk.java.net/~sundar/8158338/webrev.01/ -Sundar On 6/1/2016 12:59 PM, Sundararajan Athijegannathan wrote: > Hi, > > Thanks for the review. > > We have an existing test that depends on "split" delegation implemented > in the ScriptLoader. > > http://hg.openjdk.java.net/jdk9/dev/nashorn/file/7fb2bf00347b/test/script/basic/JDK-8024619.js > > The current code adjustment is about which loader is "parent" and which > one "side" delegatee. Previously, parent was Context's appLoader and > side-delegatee was the structure loader. > Now, it is other way around. But, the behavior seen from scripts should > remain same in either case. The aforementioned test (along with other > nashorn tests) passes with the adjusted > delegation setup as well. > > -Sundar > > On 6/1/2016 12:49 PM, Marcus Lagergren wrote: >> This looks good. Is it possible to test it? >> >> /M >> >>> On 01 Jun 2016, at 08:46, Sundararajan Athijegannathan wrote: >>> >>> Please review http://cr.openjdk.java.net/~sundar/8158338/webrev.00/ for >>> https://bugs.openjdk.java.net/browse/JDK-8158338 >>> >>> Thanks, >>> >>> -Sundar >>> From hannes.wallnoefer at oracle.com Wed Jun 1 09:33:38 2016 From: hannes.wallnoefer at oracle.com (=?windows-1252?Q?Hannes_Walln=F6fer?=) Date: Wed, 1 Jun 2016 11:33:38 +0200 Subject: RFR(S) 8158338: Nashorn's ScriptLoader split delegation has to adjusted In-Reply-To: References: <488d5d5f-b843-0727-da9d-67e3072390e9@oracle.com> <2EECF93D-D948-4643-9E74-7E982BCCA772@lagergren.net> <51c5b6bc-1836-e7cb-1783-686995c82d64@oracle.com> Message-ID: 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 the case of appLoader being null in > ScriptLoader. I had used Class.forName(String, boolean, ClassLoader). > But that methods introduces a security check when caller is not > bootstrap (like nashorn) and ClassLoader is null! In any case, > bootloader delegation has already happened via parent delegation. So, > I'm checking and handling appLoader null case by throwing > ClassNotFoundException. > > Updated webrev: http://cr.openjdk.java.net/~sundar/8158338/webrev.01/ > > -Sundar > > On 6/1/2016 12:59 PM, Sundararajan Athijegannathan wrote: >> Hi, >> >> Thanks for the review. >> >> We have an existing test that depends on "split" delegation implemented >> in the ScriptLoader. >> >> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/7fb2bf00347b/test/script/basic/JDK-8024619.js >> >> The current code adjustment is about which loader is "parent" and which >> one "side" delegatee. Previously, parent was Context's appLoader and >> side-delegatee was the structure loader. >> Now, it is other way around. But, the behavior seen from scripts should >> remain same in either case. The aforementioned test (along with other >> nashorn tests) passes with the adjusted >> delegation setup as well. >> >> -Sundar >> >> On 6/1/2016 12:49 PM, Marcus Lagergren wrote: >>> This looks good. Is it possible to test it? >>> >>> /M >>> >>>> On 01 Jun 2016, at 08:46, Sundararajan Athijegannathan wrote: >>>> >>>> Please review http://cr.openjdk.java.net/~sundar/8158338/webrev.00/ for >>>> https://bugs.openjdk.java.net/browse/JDK-8158338 >>>> >>>> Thanks, >>>> >>>> -Sundar >>>> > From sundararajan.athijegannathan at oracle.com Wed Jun 1 09:41:06 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 1 Jun 2016 15:11:06 +0530 Subject: RFR(S) 8158338: Nashorn's ScriptLoader split delegation has to adjusted In-Reply-To: References: <488d5d5f-b843-0727-da9d-67e3072390e9@oracle.com> <2EECF93D-D948-4643-9E74-7E982BCCA772@lagergren.net> <51c5b6bc-1836-e7cb-1783-686995c82d64@oracle.com> Message-ID: <7f57199b-0ab8-25a4-73f0-d06060265d8f@oracle.com> Just clean code so that Module Layer parent/child mimics class loader delegation chain. Thanks for the review! -Sundar On 6/1/2016 3:03 PM, Hannes Walln?fer wrote: > 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 the case of appLoader being null in >> ScriptLoader. I had used Class.forName(String, boolean, ClassLoader). >> But that methods introduces a security check when caller is not >> bootstrap (like nashorn) and ClassLoader is null! In any case, >> bootloader delegation has already happened via parent delegation. So, >> I'm checking and handling appLoader null case by throwing >> ClassNotFoundException. >> >> Updated webrev: http://cr.openjdk.java.net/~sundar/8158338/webrev.01/ >> >> -Sundar >> >> On 6/1/2016 12:59 PM, Sundararajan Athijegannathan wrote: >>> Hi, >>> >>> Thanks for the review. >>> >>> We have an existing test that depends on "split" delegation implemented >>> in the ScriptLoader. >>> >>> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/7fb2bf00347b/test/script/basic/JDK-8024619.js >>> >>> The current code adjustment is about which loader is "parent" and which >>> one "side" delegatee. Previously, parent was Context's appLoader and >>> side-delegatee was the structure loader. >>> Now, it is other way around. But, the behavior seen from scripts should >>> remain same in either case. The aforementioned test (along with other >>> nashorn tests) passes with the adjusted >>> delegation setup as well. >>> >>> -Sundar >>> >>> On 6/1/2016 12:49 PM, Marcus Lagergren wrote: >>>> This looks good. Is it possible to test it? >>>> >>>> /M >>>> >>>>> On 01 Jun 2016, at 08:46, Sundararajan Athijegannathan wrote: >>>>> >>>>> Please review http://cr.openjdk.java.net/~sundar/8158338/webrev.00/ for >>>>> https://bugs.openjdk.java.net/browse/JDK-8158338 >>>>> >>>>> Thanks, >>>>> >>>>> -Sundar >>>>> From james.laskey at oracle.com Wed Jun 1 10:56:44 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 1 Jun 2016 07:56:44 -0300 Subject: RFR(S) 8158338: Nashorn's ScriptLoader split delegation has to adjusted In-Reply-To: References: <488d5d5f-b843-0727-da9d-67e3072390e9@oracle.com> <2EECF93D-D948-4643-9E74-7E982BCCA772@lagergren.net> <51c5b6bc-1836-e7cb-1783-686995c82d64@oracle.com> Message-ID: <68F8C08B-EDBF-4573-A3E6-AC7CB546BDE8@oracle.com> +1 > On Jun 1, 2016, at 6:14 AM, Sundararajan Athijegannathan wrote: > > I had to update webrev to handle the case of appLoader being null in > ScriptLoader. I had used Class.forName(String, boolean, ClassLoader). > But that methods introduces a security check when caller is not > bootstrap (like nashorn) and ClassLoader is null! In any case, > bootloader delegation has already happened via parent delegation. So, > I'm checking and handling appLoader null case by throwing > ClassNotFoundException. > > Updated webrev: http://cr.openjdk.java.net/~sundar/8158338/webrev.01/ > > -Sundar > > On 6/1/2016 12:59 PM, Sundararajan Athijegannathan wrote: >> Hi, >> >> Thanks for the review. >> >> We have an existing test that depends on "split" delegation implemented >> in the ScriptLoader. >> >> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/7fb2bf00347b/test/script/basic/JDK-8024619.js >> >> The current code adjustment is about which loader is "parent" and which >> one "side" delegatee. Previously, parent was Context's appLoader and >> side-delegatee was the structure loader. >> Now, it is other way around. But, the behavior seen from scripts should >> remain same in either case. The aforementioned test (along with other >> nashorn tests) passes with the adjusted >> delegation setup as well. >> >> -Sundar >> >> On 6/1/2016 12:49 PM, Marcus Lagergren wrote: >>> This looks good. Is it possible to test it? >>> >>> /M >>> >>>> On 01 Jun 2016, at 08:46, Sundararajan Athijegannathan wrote: >>>> >>>> Please review http://cr.openjdk.java.net/~sundar/8158338/webrev.00/ for >>>> https://bugs.openjdk.java.net/browse/JDK-8158338 >>>> >>>> Thanks, >>>> >>>> -Sundar >>>> > From sundararajan.athijegannathan at oracle.com Wed Jun 1 12:13:21 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 1 Jun 2016 17:43:21 +0530 Subject: [8u] approval request for 8158338: Nashorn's ScriptLoader split delegation has to be adjusted Message-ID: Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8158338 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-June/006259.html jdk8u webrev: http://cr.openjdk.java.net/~sundar/8158338/8u/webrev.00/ Backport patch wouldn't apply "as is" because of jdk9/Module specific changes in jdk9 are not applicable to jdk8u. CC'ing this approval to nashorn team for backport webrev review. Thanks, -Sundar From marcus at lagergren.net Wed Jun 1 13:02:16 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Wed, 1 Jun 2016 15:02:16 +0200 Subject: [8u] approval request for 8158338: Nashorn's ScriptLoader split delegation has to be adjusted In-Reply-To: References: Message-ID: <6C9A3E24-3C81-40DD-A7E6-B2014DEE4B13@lagergren.net> +1 > On 01 Jun 2016, at 14:13, Sundararajan Athijegannathan wrote: > > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158338 > > jdk9 review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-June/006259.html > > jdk8u webrev: http://cr.openjdk.java.net/~sundar/8158338/8u/webrev.00/ > > Backport patch wouldn't apply "as is" because of jdk9/Module specific > changes in jdk9 are not applicable to jdk8u. > > CC'ing this approval to nashorn team for backport webrev review. > > Thanks, > > -Sundar > > From sean.coffey at oracle.com Wed Jun 1 13:04:59 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 1 Jun 2016 14:04:59 +0100 Subject: [8u] approval request for 8158338: Nashorn's ScriptLoader split delegation has to be adjusted In-Reply-To: <6C9A3E24-3C81-40DD-A7E6-B2014DEE4B13@lagergren.net> References: <6C9A3E24-3C81-40DD-A7E6-B2014DEE4B13@lagergren.net> Message-ID: <574EDD7B.4070308@oracle.com> Approved for jdk8u-dev. Regards, Sean. On 01/06/16 14:02, Marcus Lagergren wrote: > +1 > >> On 01 Jun 2016, at 14:13, Sundararajan Athijegannathan wrote: >> >> Please approve. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8158338 >> >> jdk9 review thread: >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-June/006259.html >> >> jdk8u webrev: http://cr.openjdk.java.net/~sundar/8158338/8u/webrev.00/ >> >> Backport patch wouldn't apply "as is" because of jdk9/Module specific >> changes in jdk9 are not applicable to jdk8u. >> >> CC'ing this approval to nashorn team for backport webrev review. >> >> Thanks, >> >> -Sundar >> >> From silas.baronda at gmail.com Wed Jun 1 13:32:08 2016 From: silas.baronda at gmail.com (Silas Baronda) Date: Wed, 1 Jun 2016 09:32:08 -0400 Subject: Review request for JDK-8156714: Parsing issue with automatic semicolon insertion In-Reply-To: References: <5735F83F.9080404@oracle.com> Message-ID: Sorry for the late reply, but is this [1] going to be backported to 8u? This would be extremely helpful for webpack generated files used for Server Side Rendering. [1]: https://bugs.openjdk.java.net/browse/JDK-8156714 ?Silas On Fri, May 13, 2016 at 12:12 PM, Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > +1 > > > On 5/13/2016 9:22 PM, Hannes Wallnoefer wrote: > > 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 > > test/script/nosecurity/parserapi.js.EXPECTED. This is caused by the > > parser API no longer including trailing comments to functions. > > > > For example consider the following code (taken from parserapi.js > > itself, this is the first changed endPosition): > > > > function Parser() { > > // create nashorn parser > > this._parser = Parser.create(); > > } > > > > // Java types used > > > > > > Previously the endPosition of the Parser function would be the end of > > the trailing comment. With this change, the function's endPosition is > > before the trailing comment starts, which seems more correct. > > > > Hannes > > From sundararajan.athijegannathan at oracle.com Wed Jun 1 13:34:20 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 1 Jun 2016 19:04:20 +0530 Subject: Review request for JDK-8156714: Parsing issue with automatic semicolon insertion In-Reply-To: References: <5735F83F.9080404@oracle.com> Message-ID: It has been backported to 8u already! https://bugs.openjdk.java.net/browse/JDK-8157926 http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn/rev/133a3c6c906e -Sundar On 6/1/2016 7:02 PM, Silas Baronda wrote: > Sorry for the late reply, but is this [1] going to be backported to > 8u? This would be extremely helpful for webpack generated files used > for Server Side Rendering. > > [1]: https://bugs.openjdk.java.net/browse/JDK-8156714 > > ?Silas > > On Fri, May 13, 2016 at 12:12 PM, Sundararajan Athijegannathan > > wrote: > > +1 > > > On 5/13/2016 9:22 PM, Hannes Wallnoefer wrote: > > 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 > > test/script/nosecurity/parserapi.js.EXPECTED. This is caused by the > > parser API no longer including trailing comments to functions. > > > > For example consider the following code (taken from parserapi.js > > itself, this is the first changed endPosition): > > > > function Parser() { > > // create nashorn parser > > this._parser = Parser.create(); > > } > > > > // Java types used > > > > > > Previously the endPosition of the Parser function would be the > end of > > the trailing comment. With this change, the function's > endPosition is > > before the trailing comment starts, which seems more correct. > > > > Hannes > > From silas.baronda at gmail.com Wed Jun 1 13:37:14 2016 From: silas.baronda at gmail.com (Silas Baronda) Date: Wed, 1 Jun 2016 09:37:14 -0400 Subject: Review request for JDK-8156714: Parsing issue with automatic semicolon insertion In-Reply-To: References: <5735F83F.9080404@oracle.com> Message-ID: Sorry for the noise. Look forward to this fix! Thanks :) ?Silas On Wed, Jun 1, 2016 at 9:34 AM, Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > It has been backported to 8u already! > > https://bugs.openjdk.java.net/browse/JDK-8157926 > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn/rev/133a3c6c906e > > -Sundar > > > On 6/1/2016 7:02 PM, Silas Baronda wrote: > > Sorry for the late reply, but is this [1] going to be backported to 8u? > This would be extremely helpful for webpack generated files used for Server > Side Rendering. > > [1]: https://bugs.openjdk.java.net/browse/JDK-8156714 > > ?Silas > > On Fri, May 13, 2016 at 12:12 PM, Sundararajan Athijegannathan < > > sundararajan.athijegannathan at oracle.com> wrote: > >> +1 >> >> >> On 5/13/2016 9:22 PM, Hannes Wallnoefer wrote: >> > 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 >> > test/script/nosecurity/parserapi.js.EXPECTED. This is caused by the >> > parser API no longer including trailing comments to functions. >> > >> > For example consider the following code (taken from parserapi.js >> > itself, this is the first changed endPosition): >> > >> > function Parser() { >> > // create nashorn parser >> > this._parser = Parser.create(); >> > } >> > >> > // Java types used >> > >> > >> > Previously the endPosition of the Parser function would be the end of >> > the trailing comment. With this change, the function's endPosition is >> > before the trailing comment starts, which seems more correct. >> > >> > Hannes >> >> > > From daniel.smith at oracle.com Wed Jun 1 21:58:58 2016 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 1 Jun 2016 15:58:58 -0600 Subject: General Registration -- 2016 JVM Language Summit Message-ID: GENERAL REGISTRATION -- JVM LANGUAGE SUMMIT, AUGUST 2016 General registration for the 2016 JVM Language Summit is now open. The event will be held at Oracle's Santa Clara campus on August 1-3, 2016. We've also decided to extend speaker registration, keeping it open for one more week, until June 8. If you or someone you know is interested in presenting, take advantage and submit an abstract ASAP! See http://jvmlangsummit.com for detailed speaker instructions. The JVM Language Summit is an open technical collaboration among language designers, compiler writers, tool builders, runtime engineers, and VM architects. We will share our experiences as creators of both the JVM and programming languages for the JVM. We also welcome non-JVM developers of similar technologies to attend or speak on their runtime, VM, or language of choice. Presentations will be recorded and made available to the public. This event is being organized by language and JVM engineers?no marketers involved! So bring your slide rules and be prepared for some seriously geeky discussions. Format The summit is held in a single classroom-style room to support direct communication between participants. About 100-120 attendees are expected. The schedule consists of a single track of traditional presentations (about 7 each day) interspersed with less-formal multitrack "workshop" discussion groups (2-3 each day) and, possibly, impromptu "lightning talks." Workshops will be less structured than in the past, favoring an open discussion format with only a small amount of prepared material. Thus, rather than collecting workshop abstracts from speakers, we're asking each registrant to suggest a few topics of interest. After choosing the most popular topics, we'll ask some registrants if they'd like to act as discussion leaders. To register: register.jvmlangsummit.com For further information: jvmlangsummit.com Questions: inquire2016 at jvmlangsummit.com From sundararajan.athijegannathan at oracle.com Thu Jun 2 05:10:10 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 2 Jun 2016 10:40:10 +0530 Subject: RFR 8158467: AccessControlException is thrown on public Java class access if "script app loader" is set to null Message-ID: Please review http://cr.openjdk.java.net/~sundar/8158467/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8158467 Thanks, -Sundar From michael.haupt at oracle.com Thu Jun 2 06:46:20 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 2 Jun 2016 08:46:20 +0200 Subject: RFR 8158467: AccessControlException is thrown on public Java class access if "script app loader" is set to null In-Reply-To: References: Message-ID: <7CA77FD0-4C1F-4F92-A4C8-6F36D7EBABBB@oracle.com> Hi Sundar, lower-case thumbs up! Best, Michael > Am 02.06.2016 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 > -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From hannes.wallnoefer at oracle.com Thu Jun 2 09:15:40 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 2 Jun 2016 11:15:40 +0200 Subject: RFR 8158467: AccessControlException is thrown on public Java class access if "script app loader" is set to null In-Reply-To: References: Message-ID: <574FF93C.7080305@oracle.com> +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 > From srinivas.dama at oracle.com Fri Jun 3 12:39:12 2016 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Fri, 3 Jun 2016 05:39:12 -0700 (PDT) Subject: RFR:DK-8148457(Remove jdk.nashorn.tools.FXShell class and associated build.xml cruft) Message-ID: <7c5cc96b-6bf0-43dd-bdf2-2b877dced1bd@default> Hi, Please review: http://cr.openjdk.java.net/~sdama/8148457/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8148457 I have verified all debug logs generated out of make targets for jdk9 forest build and nashorn ant targets. Regards, Srinivas From james.laskey at oracle.com Fri Jun 3 12:50:06 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 3 Jun 2016 09:50:06 -0300 Subject: RFR:DK-8148457(Remove jdk.nashorn.tools.FXShell class and associated build.xml cruft) In-Reply-To: <7c5cc96b-6bf0-43dd-bdf2-2b877dced1bd@default> References: <7c5cc96b-6bf0-43dd-bdf2-2b877dced1bd@default> Message-ID: <4BB8CDA1-8C2A-4498-9681-AAD95BFC0D97@oracle.com> +1 > On Jun 3, 2016, at 9:39 AM, Srinivas Dama wrote: > > Hi, > > Please review: > http://cr.openjdk.java.net/~sdama/8148457/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8148457 > > I have verified all debug logs generated out of make targets for jdk9 forest build and > nashorn ant targets. > > Regards, > Srinivas From sundararajan.athijegannathan at oracle.com Fri Jun 3 12:56:34 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 3 Jun 2016 18:26:34 +0530 Subject: RFR:DK-8148457(Remove jdk.nashorn.tools.FXShell class and associated build.xml cruft) In-Reply-To: <7c5cc96b-6bf0-43dd-bdf2-2b877dced1bd@default> References: <7c5cc96b-6bf0-43dd-bdf2-2b877dced1bd@default> Message-ID: +1 On 6/3/2016 6:09 PM, Srinivas Dama wrote: > Hi, > > Please review: > http://cr.openjdk.java.net/~sdama/8148457/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8148457 > > I have verified all debug logs generated out of make targets for jdk9 forest build and > nashorn ant targets. > > Regards, > Srinivas From michael.haupt at oracle.com Fri Jun 3 13:05:40 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 3 Jun 2016 15:05:40 +0200 Subject: RFR:DK-8148457(Remove jdk.nashorn.tools.FXShell class and associated build.xml cruft) In-Reply-To: <7c5cc96b-6bf0-43dd-bdf2-2b877dced1bd@default> References: <7c5cc96b-6bf0-43dd-bdf2-2b877dced1bd@default> Message-ID: Hi Srini, lower-case thumbs up, and I'll be happy to sponsor the push. Best, Michael > Am 03.06.2016 um 14:39 schrieb Srinivas Dama : > > Hi, > > Please review: > http://cr.openjdk.java.net/~sdama/8148457/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8148457 > > I have verified all debug logs generated out of make targets for jdk9 forest build and > nashorn ant targets. > > Regards, > Srinivas -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Fri Jun 3 13:10:29 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 3 Jun 2016 15:10:29 +0200 Subject: RFR:DK-8148457(Remove jdk.nashorn.tools.FXShell class and associated build.xml cruft) In-Reply-To: References: <7c5cc96b-6bf0-43dd-bdf2-2b877dced1bd@default> Message-ID: Hi Srini, > Am 03.06.2016 um 15:05 schrieb Michael Haupt : > lower-case thumbs up, and I'll be happy to sponsor the push. I accidentally used my user ID for the push. Sorry about that. Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From marcus at lagergren.net Sat Jun 4 16:56:35 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Sat, 4 Jun 2016 18:56:35 +0200 Subject: RFR 8158467: AccessControlException is thrown on public Java class access if "script app loader" is set to null In-Reply-To: References: Message-ID: <5EF26D7B-FC20-4B46-9536-127A6A9D1540@lagergren.net> +1 > On 02 Jun 2016, at 07:10, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8158467/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8158467 > > Thanks, > > -Sundar > From sundararajan.athijegannathan at oracle.com Mon Jun 6 09:38:28 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 6 Jun 2016 15:08:28 +0530 Subject: RFR 8158736: Adapter class loaders can avoid creating named dynamic modules Message-ID: 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 classes. This can be avoided and we can use the default, unnamed module created for the adapter class loader. Nashorn allows only subtyping of public, exported supertypes be implemented in scripts. The only package used in adapter module is exported and the adapter type is public as well. There is no need for named dynamic module - as there is nothing to encapsulate. Nashorn module can still selectively export packages to adapter module [ so that generated adapter class can access nashorn internals as needed]. This avoids having to generate read-links to the modules of the reference types used by the adapter class - because unnamed adapter module has read edges to all the modules. Thanks, -Sundar From hannes.wallnoefer at oracle.com Mon Jun 6 12:19:41 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 6 Jun 2016 14:19:41 +0200 Subject: RFR 8158736: Adapter class loaders can avoid creating named dynamic modules In-Reply-To: References: Message-ID: <57556A5D.60102@oracle.com> 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 classes. This > can be avoided and we can use the default, unnamed module created for > the adapter class loader. Nashorn allows only subtyping of public, > exported supertypes be implemented in scripts. The only package used in > adapter module is exported and the adapter type is public as well. > > There is no need for named dynamic module - as there is nothing to > encapsulate. Nashorn module can still selectively export packages to > adapter module [ so that generated adapter class can access nashorn > internals as needed]. > > This avoids having to generate read-links to the modules of the > reference types used by the adapter class - because unnamed adapter > module has read edges to all the modules. > > Thanks, > > -Sundar > From michael.haupt at oracle.com Mon Jun 6 12:24:07 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 6 Jun 2016 14:24:07 +0200 Subject: RFR 8158736: Adapter class loaders can avoid creating named dynamic modules In-Reply-To: References: Message-ID: <453EA277-A8F2-47BF-A8C2-1C3C5BB78E0C@oracle.com> Hi Sundar, lower-case thumbs up! Best, Michael > Am 06.06.2016 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 classes. This > can be avoided and we can use the default, unnamed module created for > the adapter class loader. Nashorn allows only subtyping of public, > exported supertypes be implemented in scripts. The only package used in > adapter module is exported and the adapter type is public as well. > > There is no need for named dynamic module - as there is nothing to > encapsulate. Nashorn module can still selectively export packages to > adapter module [ so that generated adapter class can access nashorn > internals as needed]. > > This avoids having to generate read-links to the modules of the > reference types used by the adapter class - because unnamed adapter > module has read edges to all the modules. > > Thanks, > > -Sundar > -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From srinivas.dama at oracle.com Mon Jun 6 15:41:39 2016 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Mon, 6 Jun 2016 08:41:39 -0700 (PDT) Subject: approval request for JDK-8138906:Test test/script/trusted/JDK-8087292.js intermittently fails In-Reply-To: <574C3F4D.1010704@oracle.com> References: <2370da2a-7ade-4915-bdf8-a89977f4147e@default> <574C3F4D.1010704@oracle.com> Message-ID: <0916b5b4-6f76-4528-819c-05b4b53f68c0@default> 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/nashorn-dev/2016-March/006022.html Jdk9 webrev : http://cr.openjdk.java.net/~sdama/8138906/webrev.00/ Jdk8u webrev: http://cr.openjdk.java.net/~sdama/8138906/8u/webrev.01/ Regards, Srinivas -----Original Message----- From: Se?n Coffey Sent: Monday, May 30, 2016 6:56 PM To: Srinivas Dama Subject: Re: approval request for JDK-8138906:Test test/script/trusted/JDK-8087292.js intermittently fails Approved for jdk8u-dev. If the code differs from the JDK 9 fix, please obtain a code review before pushing. Regards, Sean. On 26/05/16 17:30, Srinivas Dama wrote: > Hi, > > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8138906 > Jdk9 review thread : > http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-February/00599 > 1.html Jdk8u-webrev : > http://cr.openjdk.java.net/~sdama/8138906/8u/webrev.00/ > > Regards, > Srinivas From hannes.wallnoefer at oracle.com Mon Jun 6 16:21:16 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 6 Jun 2016 18:21:16 +0200 Subject: approval request for JDK-8138906:Test test/script/trusted/JDK-8087292.js intermittently fails In-Reply-To: <0916b5b4-6f76-4528-819c-05b4b53f68c0@default> References: <2370da2a-7ade-4915-bdf8-a89977f4147e@default> <574C3F4D.1010704@oracle.com> <0916b5b4-6f76-4528-819c-05b4b53f68c0@default> Message-ID: <5755A2FC.6040304@oracle.com> 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/nashorn-dev/2016-March/006022.html > Jdk9 webrev : > http://cr.openjdk.java.net/~sdama/8138906/webrev.00/ > > Jdk8u webrev: > http://cr.openjdk.java.net/~sdama/8138906/8u/webrev.01/ > > Regards, > Srinivas > > -----Original Message----- > From: Se?n Coffey > Sent: Monday, May 30, 2016 6:56 PM > To: Srinivas Dama > Subject: Re: approval request for JDK-8138906:Test test/script/trusted/JDK-8087292.js intermittently fails > > Approved for jdk8u-dev. If the code differs from the JDK 9 fix, please obtain a code review before pushing. > > Regards, > Sean. > > On 26/05/16 17:30, Srinivas Dama wrote: >> Hi, >> >> Please approve. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8138906 >> Jdk9 review thread : >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-February/00599 >> 1.html Jdk8u-webrev : >> http://cr.openjdk.java.net/~sdama/8138906/8u/webrev.00/ >> >> Regards, >> Srinivas From blackdrag at gmx.org Mon Jun 6 19:00:41 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Mon, 6 Jun 2016 21:00:41 +0200 Subject: RFR 8158736: Adapter class loaders can avoid creating named dynamic modules In-Reply-To: References: Message-ID: <5755C859.6080100@gmx.org> On 06.06.2016 11:38, Sundararajan Athijegannathan wrote: [...] > There is no need for named dynamic module - as there is nothing to > encapsulate. Nashorn module can still selectively export packages to > adapter module [ so that generated adapter class can access nashorn > internals as needed]. does that mean the only user of named dynamic modules is gone now? bye Jochen From sundararajan.athijegannathan at oracle.com Tue Jun 7 03:55:52 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 7 Jun 2016 09:25:52 +0530 Subject: RFR 8158736: Adapter class loaders can avoid creating named dynamic modules In-Reply-To: <5755C859.6080100@gmx.org> References: <5755C859.6080100@gmx.org> Message-ID: No, there are still named, dynamic modules in Nashorn. That comment was specific to adapter module in nashorn. StructureLoader and ScriptLoaders load generated classes that require encapsulation. And so these loader classes do create named, dynamic modules still. -Sundar On 6/7/2016 12:30 AM, Jochen Theodorou wrote: > On 06.06.2016 11:38, Sundararajan Athijegannathan wrote: > [...] >> There is no need for named dynamic module - as there is nothing to >> encapsulate. Nashorn module can still selectively export packages to >> adapter module [ so that generated adapter class can access nashorn >> internals as needed]. > > does that mean the only user of named dynamic modules is gone now? > > bye Jochen > From sundararajan.athijegannathan at oracle.com Tue Jun 7 04:04:50 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 7 Jun 2016 09:34:50 +0530 Subject: RFR 8158736: Adapter class loaders can avoid creating named dynamic modules In-Reply-To: References: <5755C859.6080100@gmx.org> Message-ID: The relevant code in jdk9-dev/nashorn repo: createModuleTrusted method in Context.java: http://hg.openjdk.java.net/jdk9/dev/nashorn/file/b1de131a3fed/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java calls to these in StructureLoader.java and ScriptLoader.java: http://hg.openjdk.java.net/jdk9/dev/nashorn/file/b1de131a3fed/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/StructureLoader.java http://hg.openjdk.java.net/jdk9/dev/nashorn/file/b1de131a3fed/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptLoader.java ModuleGraphManipulator.java: of this class creates addExports links from dynamic modules to nashorn module. http://hg.openjdk.java.net/jdk9/dev/nashorn/file/b1de131a3fed/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/scripts/ModuleGraphManipulator.java -Sundar On 6/7/2016 9:25 AM, Sundararajan Athijegannathan wrote: > No, there are still named, dynamic modules in Nashorn. That comment > was specific to adapter module in nashorn. StructureLoader and > ScriptLoaders load generated classes that require encapsulation. And so > these loader classes do create named, dynamic modules still. > > -Sundar > > > On 6/7/2016 12:30 AM, Jochen Theodorou wrote: >> On 06.06.2016 11:38, Sundararajan Athijegannathan wrote: >> [...] >>> There is no need for named dynamic module - as there is nothing to >>> encapsulate. Nashorn module can still selectively export packages to >>> adapter module [ so that generated adapter class can access nashorn >>> internals as needed]. >> does that mean the only user of named dynamic modules is gone now? >> >> bye Jochen >> From szegedia at gmail.com Tue Jun 7 05:29:20 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 6 Jun 2016 22:29:20 -0700 Subject: RFR 8158736: Adapter class loaders can avoid creating named dynamic modules In-Reply-To: References: Message-ID: +1. Echoing Hannes? sentiment, it?s nice to see that extra code gone. > On 06 Jun 2016, at 02:38, Sundararajan Athijegannathan wrote: > > 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 classes. This > can be avoided and we can use the default, unnamed module created for > the adapter class loader. Nashorn allows only subtyping of public, > exported supertypes be implemented in scripts. The only package used in > adapter module is exported and the adapter type is public as well. > > There is no need for named dynamic module - as there is nothing to > encapsulate. Nashorn module can still selectively export packages to > adapter module [ so that generated adapter class can access nashorn > internals as needed]. > > This avoids having to generate read-links to the modules of the > reference types used by the adapter class - because unnamed adapter > module has read edges to all the modules. > > Thanks, > > -Sundar > From michael.haupt at oracle.com Tue Jun 7 07:06:51 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 7 Jun 2016 09:06:51 +0200 Subject: approval request for JDK-8138906:Test test/script/trusted/JDK-8087292.js intermittently fails In-Reply-To: <5755A2FC.6040304@oracle.com> References: <2370da2a-7ade-4915-bdf8-a89977f4147e@default> <574C3F4D.1010704@oracle.com> <0916b5b4-6f76-4528-819c-05b4b53f68c0@default> <5755A2FC.6040304@oracle.com> Message-ID: <97BA0A13-3FC7-4283-9D41-CE68AFC5B77E@oracle.com> Hi all, I'll sponsor the push. Best, Michael > Am 06.06.2016 um 18:21 schrieb Hannes Wallnoefer : > > 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/nashorn-dev/2016-March/006022.html >> Jdk9 webrev : >> http://cr.openjdk.java.net/~sdama/8138906/webrev.00/ >> >> Jdk8u webrev: >> http://cr.openjdk.java.net/~sdama/8138906/8u/webrev.01/ >> >> Regards, >> Srinivas >> >> -----Original Message----- >> From: Se?n Coffey >> Sent: Monday, May 30, 2016 6:56 PM >> To: Srinivas Dama >> Subject: Re: approval request for JDK-8138906:Test test/script/trusted/JDK-8087292.js intermittently fails >> >> Approved for jdk8u-dev. If the code differs from the JDK 9 fix, please obtain a code review before pushing. >> >> Regards, >> Sean. >> >> On 26/05/16 17:30, Srinivas Dama wrote: >>> Hi, >>> >>> Please approve. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138906 >>> Jdk9 review thread : >>> http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-February/00599 >>> 1.html Jdk8u-webrev : >>> http://cr.openjdk.java.net/~sdama/8138906/8u/webrev.00/ >>> >>> Regards, >>> Srinivas > -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From marcus at lagergren.net Tue Jun 7 08:05:05 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Tue, 7 Jun 2016 10:05:05 +0200 Subject: RFR 8158736: Adapter class loaders can avoid creating named dynamic modules In-Reply-To: References: Message-ID: Nice and clean! +1 /M > On 06 Jun 2016, at 11:38, Sundararajan Athijegannathan wrote: > > 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 classes. This > can be avoided and we can use the default, unnamed module created for > the adapter class loader. Nashorn allows only subtyping of public, > exported supertypes be implemented in scripts. The only package used in > adapter module is exported and the adapter type is public as well. > > There is no need for named dynamic module - as there is nothing to > encapsulate. Nashorn module can still selectively export packages to > adapter module [ so that generated adapter class can access nashorn > internals as needed]. > > This avoids having to generate read-links to the modules of the > reference types used by the adapter class - because unnamed adapter > module has read edges to all the modules. > > Thanks, > > -Sundar > From rob.mckenna at oracle.com Tue Jun 7 12:15:34 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 7 Jun 2016 13:15:34 +0100 Subject: approval request for JDK-8138906:Test test/script/trusted/JDK-8087292.js intermittently fails In-Reply-To: <5755A2FC.6040304@oracle.com> References: <2370da2a-7ade-4915-bdf8-a89977f4147e@default> <574C3F4D.1010704@oracle.com> <0916b5b4-6f76-4528-819c-05b4b53f68c0@default> <5755A2FC.6040304@oracle.com> Message-ID: <5756BAE6.7020305@oracle.com> Approved -Rob On 06/06/16 17:21, Hannes Wallnoefer wrote: > 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/nashorn-dev/2016-March/006022.html >> Jdk9 webrev : >> http://cr.openjdk.java.net/~sdama/8138906/webrev.00/ >> >> Jdk8u webrev: >> http://cr.openjdk.java.net/~sdama/8138906/8u/webrev.01/ >> >> Regards, >> Srinivas >> >> -----Original Message----- >> From: Se?n Coffey >> Sent: Monday, May 30, 2016 6:56 PM >> To: Srinivas Dama >> Subject: Re: approval request for JDK-8138906:Test >> test/script/trusted/JDK-8087292.js intermittently fails >> >> Approved for jdk8u-dev. If the code differs from the JDK 9 fix, please >> obtain a code review before pushing. >> >> Regards, >> Sean. >> >> On 26/05/16 17:30, Srinivas Dama wrote: >>> Hi, >>> >>> Please approve. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138906 >>> Jdk9 review thread : >>> http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-February/00599 >>> 1.html Jdk8u-webrev : >>> http://cr.openjdk.java.net/~sdama/8138906/8u/webrev.00/ >>> >>> Regards, >>> Srinivas > From sundararajan.athijegannathan at oracle.com Tue Jun 7 12:34:29 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 7 Jun 2016 18:04:29 +0530 Subject: RFR 8158922: jjs tab completion of Java classes shows package-private, "hidden" classes too Message-ID: <63471723-f526-bce8-ec09-c3e6c2069e1b@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8158922/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8158922 Thanks, -Sundar From hannes.wallnoefer at oracle.com Tue Jun 7 12:48:05 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 7 Jun 2016 14:48:05 +0200 Subject: RFR 8158922: jjs tab completion of Java classes shows package-private, "hidden" classes too In-Reply-To: <63471723-f526-bce8-ec09-c3e6c2069e1b@oracle.com> References: <63471723-f526-bce8-ec09-c3e6c2069e1b@oracle.com> Message-ID: <85DA85A1-08DC-4DDF-B1D9-8376159D18F2@oracle.com> 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 > From michael.haupt at oracle.com Tue Jun 7 13:06:48 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 7 Jun 2016 15:06:48 +0200 Subject: RFR 8158922: jjs tab completion of Java classes shows package-private, "hidden" classes too In-Reply-To: <63471723-f526-bce8-ec09-c3e6c2069e1b@oracle.com> References: <63471723-f526-bce8-ec09-c3e6c2069e1b@oracle.com> Message-ID: <01B822EF-A182-495D-9CA9-02385A671137@oracle.com> Hi Sundar, lower-case thumbs up! Best, Michael > 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 > -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From marcus at lagergren.net Wed Jun 8 06:31:43 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Wed, 8 Jun 2016 08:31:43 +0200 Subject: RFR 8158922: jjs tab completion of Java classes shows package-private, "hidden" classes too In-Reply-To: <63471723-f526-bce8-ec09-c3e6c2069e1b@oracle.com> References: <63471723-f526-bce8-ec09-c3e6c2069e1b@oracle.com> Message-ID: Looks good! +1 /M > On 07 Jun 2016, at 14:34, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8158922/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8158922 > > Thanks, > > -Sundar > From hannes.wallnoefer at oracle.com Wed Jun 8 11:18:44 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 8 Jun 2016 13:18:44 +0200 Subject: RFR: 8159031: jjs throws NoSuchFileException if ~/.jjs.history does not exist Message-ID: <7FCC7826-D025-47CB-9A6A-0119E4DE1D23@oracle.com> Please review the following changes: Bug: https://bugs.openjdk.java.net/browse/JDK-8159031 JDK webrev: http://cr.openjdk.java.net/~hannesw/8159031/jdk/webrev.00/ Nashorn webrev: http://cr.openjdk.java.net/~hannesw/8159031/nashorn/webrev.00/ These are two one-liners that add a file existence check in Nashorn and a null check in jline. Thanks, Hannes From sundararajan.athijegannathan at oracle.com Wed Jun 8 11:30:44 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 8 Jun 2016 17:00:44 +0530 Subject: RFR: 8159031: jjs throws NoSuchFileException if ~/.jjs.history does not exist In-Reply-To: <7FCC7826-D025-47CB-9A6A-0119E4DE1D23@oracle.com> References: <7FCC7826-D025-47CB-9A6A-0119E4DE1D23@oracle.com> Message-ID: <9c68a30d-736d-48b3-a62a-e1bba5ca0beb@oracle.com> +1 On 6/8/2016 4:48 PM, Hannes Walln?fer wrote: > Please review the following changes: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159031 > JDK webrev: http://cr.openjdk.java.net/~hannesw/8159031/jdk/webrev.00/ > Nashorn webrev: http://cr.openjdk.java.net/~hannesw/8159031/nashorn/webrev.00/ > > These are two one-liners that add a file existence check in Nashorn and a null check in jline. > > Thanks, > Hannes > From sundararajan.athijegannathan at oracle.com Wed Jun 8 12:01:37 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 8 Jun 2016 17:31:37 +0530 Subject: RFR 8159034: 4 nashorn ant tests fail with latest jdk9-dev build with IncompatibleClassChangeError Message-ID: Please review http://cr.openjdk.java.net/~sundar/8159034/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8159034 No new regression test added as there are already tests cover calling inherited default methods on interfaces. Thanks, -Sundar From hannes.wallnoefer at oracle.com Wed Jun 8 12:05:18 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 8 Jun 2016 14:05:18 +0200 Subject: RFR 8159034: 4 nashorn ant tests fail with latest jdk9-dev build with IncompatibleClassChangeError In-Reply-To: References: Message-ID: <0A2D5AFD-D32D-4555-AEAE-BD9DA4C01FA8@oracle.com> +1 > Am 08.06.2016 um 14:01 schrieb Sundararajan Athijegannathan : > > Please review http://cr.openjdk.java.net/~sundar/8159034/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8159034 > > No new regression test added as there are already tests cover calling > inherited default methods on interfaces. > > Thanks, > > -Sundar > From james.laskey at oracle.com Wed Jun 8 12:06:07 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 8 Jun 2016 09:06:07 -0300 Subject: RFR 8159034: 4 nashorn ant tests fail with latest jdk9-dev build with IncompatibleClassChangeError In-Reply-To: References: Message-ID: <26F639F9-679E-4EF5-801A-63F30025C70B@oracle.com> +1 > On Jun 8, 2016, at 9:01 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8159034/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8159034 > > No new regression test added as there are already tests cover calling > inherited default methods on interfaces. > > Thanks, > > -Sundar > From michael.haupt at oracle.com Wed Jun 8 13:35:25 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 8 Jun 2016 15:35:25 +0200 Subject: RFR: 8159031: jjs throws NoSuchFileException if ~/.jjs.history does not exist In-Reply-To: <7FCC7826-D025-47CB-9A6A-0119E4DE1D23@oracle.com> References: <7FCC7826-D025-47CB-9A6A-0119E4DE1D23@oracle.com> Message-ID: <09936699-3D99-422E-BA42-840C653323B8@oracle.com> Hi Hannes, lower-case thumbs up for both the JDK and Nashorn changes. Best, Michael > Am 08.06.2016 um 13:18 schrieb Hannes Walln?fer : > > Please review the following changes: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159031 > JDK webrev: http://cr.openjdk.java.net/~hannesw/8159031/jdk/webrev.00/ > Nashorn webrev: http://cr.openjdk.java.net/~hannesw/8159031/nashorn/webrev.00/ > > These are two one-liners that add a file existence check in Nashorn and a null check in jline. > > Thanks, > Hannes > -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From hannes.wallnoefer at oracle.com Fri Jun 10 14:56:27 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Fri, 10 Jun 2016 16:56:27 +0200 Subject: RFR: 8159220: Preserve position info in module import and export entries Message-ID: <8388BCA3-6498-4926-B699-5B8094DF7454@oracle.com> 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 From emilian.bold at gmail.com Fri Jun 10 15:35:12 2016 From: emilian.bold at gmail.com (Emilian Bold) Date: Fri, 10 Jun 2016 18:35:12 +0300 Subject: Nashorn comment nodes in the syntax tree In-Reply-To: References: Message-ID: BTW, jdk.nashorn.internal.ir.IdentNode (and other classes) seem to have the habit of "absorbing" the nearby comments and have incorrect start/finish offsets. Is this intentional or a bug? I haven't tested yet but I wonder if it propagates to the TreeAPI (ie. does IdentifierTree also swallow adjacent comments?) --emi On Wed, Apr 27, 2016 at 5:18 PM, Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > Hi, > > I filed an enhancement request: > https://bugs.openjdk.java.net/browse/JDK-8155242 > > Thanks, > > -Sundar > > > On 4/27/2016 12:40 AM, Emilian Bold wrote: > > Hello, > > > > NetBeans used a modified Rhino that had useful features for an IDE like > > comment nodes and parser-level sanitization. > > > > As far as I know there is no way to get the comments in the Nashorn Tree > > API (created as part of JEP 236) or in the jdk.nashorn.internal.ir Node > > subclasses. > > > > Obviously having access to comment contents and comment offsets is very > > useful. An IDE, for example, would provide code folding for the multiline > > comment. > > > > Am I missing some proper way to get this information? > > > > I believe an extra option for Parser.create() would be nice (plus a > > CommentTree and a visitComment method). > > > > --emi > > From sundararajan.athijegannathan at oracle.com Fri Jun 10 15:36:36 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 10 Jun 2016 21:06:36 +0530 Subject: RFR: 8159220: Preserve position info in module import and export entries In-Reply-To: <8388BCA3-6498-4926-B699-5B8094DF7454@oracle.com> References: <8388BCA3-6498-4926-B699-5B8094DF7454@oracle.com> Message-ID: <6f598eae-1db2-c78e-84a9-ec32ee5e9e80@oracle.com> +1 On 6/10/2016 8:26 PM, Hannes Walln?fer wrote: > 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 From billreed63 at gmail.com Fri Jun 10 17:03:28 2016 From: billreed63 at gmail.com (Bill Reed) Date: Fri, 10 Jun 2016 13:03:28 -0400 Subject: JSON.stringify does not support Java class that extends AbstractJSObject Message-ID: I have a Java class ExampleTuple2 that extends AbstractJSObject. My ExampleTuple2 has a toJSON method. I instantiate the object in JavaScript (nashorn) if I do a JSON.stringify(tuple2Instance) the result "undefined" The API documentation for AbstractJSObject https://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/AbstractJSObject.html states *"This is the base class for nashorn ScriptObjectMirror class. This class can also be subclassed by an arbitrary Java class. Nashorn will treat objects of such classes just like nashorn script objects. Usual nashorn operations like obj[i], obj.foo, obj.func(), delete obj.foo will be glued to appropriate method call of this class." * Should my toJSON method be calls when using JSON.stringify for this type of object? Example of the Java code. package org.eclairjs.nashorn.wrap; import jdk.nashorn.api.scripting.AbstractJSObject; import org.eclairjs.nashorn.Utils; public class ExampleTuple2 extends AbstractJSObject { public abstract class WrappedFunction extends AbstractJSObject { @Override public boolean isFunction() { return true; } } Object _1; Object _2; public ExampleTuple2(scala.Tuple2 tuple2) { _1=Utils.javaToJs(tuple2._1(),null); _2=Utils.javaToJs(tuple2._2(),null); } public ExampleTuple2(Object _1, Object _2) { this._1=_1; this._2=_2; } WrappedFunction F_toJSON = new WrappedFunction () { @Override public Object call(Object thiz, Object... args) { return "{\"0\":" + _1 + ",\"1\":" + _2 + "}" ; } }; WrappedFunction F_toString = new WrappedFunction () { @Override public Object call(Object thiz, Object... args) { return "(" + _1 + "," + _2 + ")" ; } }; WrappedFunction F_valueOf = new WrappedFunction () { @Override public Object call(Object thiz, Object... args) { return "(" + _1 + "," + _2 + ")"; } }; WrappedFunction F_1 = new WrappedFunction () { @Override public Object call(Object thiz, Object... args) { return _1; } }; WrappedFunction F_2 = new WrappedFunction () { @Override public Object call(Object thiz, Object... args) { return _2; } }; // get the value of that named property @Override public Object getMember(String name) { switch (name) { case "_1": return F_1; case "_2": return F_2; case "valueOf": return F_valueOf; case "toJSON": return F_toJSON; case "toString": return F_toString; } throw new RuntimeException("Tuple2."+name+" is not defined"); } @Override public boolean hasMember(String name) { switch (name) { case "_1": case "_2": case "valueOf": case "toJSON": case "toString": return true; } return super.hasMember(name); } } Example of the JavaScript code. var Tuple2 = Java.type('org.eclairjs.nashorn.wrap.ExampleTuple2'); var t = new Tuple2("value1", "value2"); print("t1 " + t._1()); print("t " + t); print(JSON.stringify(t)); From marcus at lagergren.net Sun Jun 12 17:58:35 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Sun, 12 Jun 2016 19:58:35 +0200 Subject: RFR: 8159220: Preserve position info in module import and export entries In-Reply-To: <8388BCA3-6498-4926-B699-5B8094DF7454@oracle.com> References: <8388BCA3-6498-4926-B699-5B8094DF7454@oracle.com> Message-ID: <0D9F0F27-1091-4065-A386-22C413E23BDF@lagergren.net> +1 > On 10 Jun 2016, at 16:56, Hannes Walln?fer wrote: > > 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 From marcus at lagergren.net Sun Jun 12 18:01:42 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Sun, 12 Jun 2016 20:01:42 +0200 Subject: RFR: 8159031: jjs throws NoSuchFileException if ~/.jjs.history does not exist In-Reply-To: <7FCC7826-D025-47CB-9A6A-0119E4DE1D23@oracle.com> References: <7FCC7826-D025-47CB-9A6A-0119E4DE1D23@oracle.com> Message-ID: +1 > On 08 Jun 2016, at 13:18, Hannes Walln?fer wrote: > > Please review the following changes: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159031 > JDK webrev: http://cr.openjdk.java.net/~hannesw/8159031/jdk/webrev.00/ > Nashorn webrev: http://cr.openjdk.java.net/~hannesw/8159031/nashorn/webrev.00/ > > These are two one-liners that add a file existence check in Nashorn and a null check in jline. > > Thanks, > Hannes > From sundararajan.athijegannathan at oracle.com Mon Jun 13 03:31:01 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 13 Jun 2016 09:01:01 +0530 Subject: Nashorn comment nodes in the syntax tree In-Reply-To: References: Message-ID: <8893b1c1-2db3-c4dc-faa7-cfae238c4bdf@oracle.com> start and finish should not include comments around. If it does, it is a bug. Please do file a bug and send us test case here and we'll file a bug Thanks, -Sundar On 6/10/2016 9:05 PM, Emilian Bold wrote: > BTW, jdk.nashorn.internal.ir.IdentNode (and other classes) seem to > have the habit of "absorbing" the nearby comments and have incorrect > start/finish offsets. > > Is this intentional or a bug? > > I haven't tested yet but I wonder if it propagates to the TreeAPI (ie. > does IdentifierTree also swallow adjacent comments?) > > > > --emi > > On Wed, Apr 27, 2016 at 5:18 PM, Sundararajan Athijegannathan > > wrote: > > Hi, > > I filed an enhancement request: > https://bugs.openjdk.java.net/browse/JDK-8155242 > > Thanks, > > -Sundar > > > On 4/27/2016 12:40 AM, Emilian Bold wrote: > > Hello, > > > > NetBeans used a modified Rhino that had useful features for an > IDE like > > comment nodes and parser-level sanitization. > > > > As far as I know there is no way to get the comments in the > Nashorn Tree > > API (created as part of JEP 236) or in the > jdk.nashorn.internal.ir Node > > subclasses. > > > > Obviously having access to comment contents and comment offsets > is very > > useful. An IDE, for example, would provide code folding for the > multiline > > comment. > > > > Am I missing some proper way to get this information? > > > > I believe an extra option for Parser.create() would be nice (plus a > > CommentTree and a visitComment method). > > > > --emi > > From sundararajan.athijegannathan at oracle.com Mon Jun 13 03:46:21 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 13 Jun 2016 09:16:21 +0530 Subject: JSON.stringify does not support Java class that extends AbstractJSObject In-Reply-To: References: Message-ID: Well, the basic property access/modification, indexed element access/modification, function call etc. are indeed glued to JSObject methods. Nashorn includes separate dynalink linker to implement this. But, a JSObject is *not* a Nashorn ScriptObject in *every* possible context. This is by design. This applies to Java POJOs as well. Nashorn tries to give illusion of scriptobject-like behavior for Java POJOs using dynalink "beans linker". That said, we have been trying to increase number of places where JSObjects and ScriptObjects are uniformly treated. There was a recent fix: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/c24beef07d1b https://bugs.openjdk.java.net/browse/JDK-8157160 And that has been backported to 8u as well. Thanks, -Sundar On 6/10/2016 10:33 PM, Bill Reed wrote: > I have a Java class ExampleTuple2 that extends AbstractJSObject. My > ExampleTuple2 has a toJSON method. I instantiate the object in JavaScript > (nashorn) if I do a JSON.stringify(tuple2Instance) the result "undefined" > > The API documentation for AbstractJSObject > https://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/AbstractJSObject.html > states *"This is the base class for nashorn ScriptObjectMirror class. This > class can also be subclassed by an arbitrary Java class. Nashorn will treat > objects of such classes just like nashorn script objects. Usual nashorn > operations like obj[i], obj.foo, obj.func(), delete obj.foo will be glued > to appropriate method call of this class." * > > Should my toJSON method be calls when using JSON.stringify for this type of > object? > > Example of the Java code. > > package org.eclairjs.nashorn.wrap; > > import jdk.nashorn.api.scripting.AbstractJSObject; > > import org.eclairjs.nashorn.Utils; > > public class ExampleTuple2 extends AbstractJSObject { > > public abstract class WrappedFunction extends AbstractJSObject { > > @Override > > public boolean isFunction() { > > return true; > > } > > } > > Object _1; > > Object _2; > > public ExampleTuple2(scala.Tuple2 tuple2) { > > _1=Utils.javaToJs(tuple2._1(),null); > > _2=Utils.javaToJs(tuple2._2(),null); > > } > > public ExampleTuple2(Object _1, Object _2) { > > this._1=_1; > > this._2=_2; > > } > > WrappedFunction F_toJSON = new WrappedFunction () { > > @Override > > public Object call(Object thiz, Object... args) { > > return "{\"0\":" + _1 + ",\"1\":" + _2 + "}" ; > > } > > }; > > WrappedFunction F_toString = new WrappedFunction () { > > @Override > > public Object call(Object thiz, Object... args) { > > return "(" + _1 + "," + _2 + ")" ; > > } > > }; > > WrappedFunction F_valueOf = new WrappedFunction () { > > @Override > > public Object call(Object thiz, Object... args) { > > return "(" + _1 + "," + _2 + ")"; > > } > > }; > > WrappedFunction F_1 = new WrappedFunction () { > > @Override > > public Object call(Object thiz, Object... args) { > > return _1; > > } > > }; > > WrappedFunction F_2 = new WrappedFunction () { > > @Override > > public Object call(Object thiz, Object... args) { > > return _2; > > } > > }; > > // get the value of that named property > > @Override > > public Object getMember(String name) { > > switch (name) { > > case "_1": return F_1; > > case "_2": return F_2; > > case "valueOf": return F_valueOf; > > case "toJSON": return F_toJSON; > > case "toString": return F_toString; > > } > > throw new RuntimeException("Tuple2."+name+" is not defined"); > > } > > @Override > > public boolean hasMember(String name) { > > switch (name) { > > case "_1": > > case "_2": > > case "valueOf": > > case "toJSON": > > case "toString": > > return true; > > } > > return super.hasMember(name); > > } > > } > > > Example of the JavaScript code. > > var Tuple2 = Java.type('org.eclairjs.nashorn.wrap.ExampleTuple2'); > > var t = new Tuple2("value1", "value2"); > > print("t1 " + t._1()); > > print("t " + t); > > print(JSON.stringify(t)); From hannes.wallnoefer at oracle.com Mon Jun 13 16:56:06 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Mon, 13 Jun 2016 18:56:06 +0200 Subject: RFR: 8150219: ReferenceError in 1.8.0_72 Message-ID: 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 with a Nashorn Global, but only in the very specific case where a script is evaluated with a non-default ScriptContext that does not have a Nashorn Global yet, and the Global is created for that specific ScriptContext. Also, we use the existing setScriptContext method and ThreadLocal field in Global instead of introducing an extra field as we had it before. The purpose is to make functions obtained from such globals use the ScriptContext they were evaluated with. Thanks, Hannes From szegedia at gmail.com Mon Jun 13 19:34:37 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 13 Jun 2016 21:34:37 +0200 Subject: RFR: 8150219: ReferenceError in 1.8.0_72 In-Reply-To: References: Message-ID: +1 > On 13 Jun 2016, at 18:56, Hannes Walln?fer wrote: > > 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 with a Nashorn Global, but only in the very specific case where a script is evaluated with a non-default ScriptContext that does not have a Nashorn Global yet, and the Global is created for that specific ScriptContext. Also, we use the existing setScriptContext method and ThreadLocal field in Global instead of introducing an extra field as we had it before. > > The purpose is to make functions obtained from such globals use the ScriptContext they were evaluated with. > > Thanks, > Hannes > From sundararajan.athijegannathan at oracle.com Tue Jun 14 02:32:54 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 14 Jun 2016 08:02:54 +0530 Subject: RFR: 8150219: ReferenceError in 1.8.0_72 In-Reply-To: References: Message-ID: Sorry, I'm not sure I'm comfortable with this fix :( Global.setScriptContext sets the ScriptContext for the *current thread* [because that Global class methods set thread local]. This means that this ReferenceError goes away only for the thread in a new Global is created and associated with that ScriptContext. For other threads, you'll continue to get ReferenceError. The root of the issue is the Invocable's methods are expected to use the default ScriptContext. That means that if you eval code or put globals in another ScriptContext, you can't do Invocable calls on it! That is the limitation of javax.script. While eval's have ScriptContext, Bindings accepting variants, there are no similar methods exists for Invocable and Compilable. These two use script engine's default ScriptContext! BTW, there is clear Nashorn alternative - which is to use jdk.scripting.api.scripting.ScriptObjectMirror's call or eval method. These take care of using the right global in which the function was defined - lexical 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?fer wrote: >> >> 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 with a Nashorn Global, but only in the very specific case where a script is evaluated with a non-default ScriptContext that does not have a Nashorn Global yet, and the Global is created for that specific ScriptContext. Also, we use the existing setScriptContext method and ThreadLocal field in Global instead of introducing an extra field as we had it before. >> >> The purpose is to make functions obtained from such globals use the ScriptContext they were evaluated with. >> >> Thanks, >> Hannes >> From sundararajan.athijegannathan at oracle.com Tue Jun 14 02:36:18 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 14 Jun 2016 08:06:18 +0530 Subject: RFR: 8150219: ReferenceError in 1.8.0_72 In-Reply-To: References: Message-ID: <97be4026-af55-6958-a45d-27a493dfa2ac@oracle.com> Sorry, leave my comment on Compilable. CompiledScript does have evals accepting Bindings, ScriptContext. My comment is applicable to Invocable though. -Sundar On 6/14/2016 8:02 AM, Sundararajan Athijegannathan wrote: > Sorry, I'm not sure I'm comfortable with this fix :( > > Global.setScriptContext sets the ScriptContext for the *current thread* > [because that Global class methods set thread local]. This means that > this ReferenceError goes away only for the thread in a new Global is > created and associated with that ScriptContext. For other threads, > you'll continue to get ReferenceError. > > The root of the issue is the Invocable's methods are expected to use the > default ScriptContext. That means that if you eval code or put globals > in another ScriptContext, you can't do Invocable calls on it! That is > the limitation of javax.script. While eval's have ScriptContext, > Bindings accepting variants, there are no similar methods exists for > Invocable and Compilable. These two use script engine's default > ScriptContext! > > BTW, there is clear Nashorn alternative - which is to use > jdk.scripting.api.scripting.ScriptObjectMirror's call or eval method. > These take care of using the right global in which the function was > defined - lexical 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?fer wrote: >>> >>> 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 with a Nashorn Global, but only in the very specific case where a script is evaluated with a non-default ScriptContext that does not have a Nashorn Global yet, and the Global is created for that specific ScriptContext. Also, we use the existing setScriptContext method and ThreadLocal field in Global instead of introducing an extra field as we had it before. >>> >>> The purpose is to make functions obtained from such globals use the ScriptContext they were evaluated with. >>> >>> Thanks, >>> Hannes >>> From axeld at pinc-software.de Tue Jun 14 07:09:31 2016 From: axeld at pinc-software.de (=?UTF-8?Q?Axel_D=c3=b6rfler?=) Date: Tue, 14 Jun 2016 09:09:31 +0200 Subject: Share context/JS bindings Message-ID: <8d64c559-092d-34c6-67ab-b4dc08684119@pinc-software.de> Hi there, I'm trying to reduce the overhead of running JavaScript code. It looks like the best thing you can do is a) share a single engine, and b) reuse the script context. I'm using a per-thread context like this: public static ScriptContext createJavaScriptContext() { ScriptContext context = new SimpleScriptContext(); Bindings bindings = perThreadGlobalScope.get(); if (bindings == null) { bindings = getJavaScriptEngine().createBindings(); perThreadGlobalScope.set(bindings); } else bindings.clear(); context.setBindings(bindings, ScriptContext.ENGINE_SCOPE); return context; } Now I'm facing the problem that JavaScript variables are shared between different uses. Ie. a: var found; print found; found = 1; Would print "1" on the second run. Is there a way to avoid this? Bye, Axel. From hannes.wallnoefer at oracle.com Tue Jun 14 07:53:04 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 14 Jun 2016 09:53:04 +0200 Subject: Share context/JS bindings In-Reply-To: <8d64c559-092d-34c6-67ab-b4dc08684119@pinc-software.de> References: <8d64c559-092d-34c6-67ab-b4dc08684119@pinc-software.de> Message-ID: <04A1114A-DBC6-4ECA-B71F-91D15FEBFA6B@oracle.com> 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 possibly we should fix our implementation of clear to include non-configurable (declared) variables. Regards, Hannes > Am 14.06.2016 um 09:09 schrieb Axel D?rfler : > > Hi there, > > I'm trying to reduce the overhead of running JavaScript code. It looks like the best thing you can do is a) share a single engine, and b) reuse the script context. > > I'm using a per-thread context like this: > > public static ScriptContext createJavaScriptContext() { > ScriptContext context = new SimpleScriptContext(); > Bindings bindings = perThreadGlobalScope.get(); > if (bindings == null) { > bindings = getJavaScriptEngine().createBindings(); > perThreadGlobalScope.set(bindings); > } else > bindings.clear(); > > context.setBindings(bindings, ScriptContext.ENGINE_SCOPE); > > return context; > } > > Now I'm facing the problem that JavaScript variables are shared between different uses. > Ie. a: > > var found; > print found; > found = 1; > > Would print "1" on the second run. > > Is there a way to avoid this? > > Bye, > Axel. From hannes.wallnoefer at oracle.com Tue Jun 14 08:22:59 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 14 Jun 2016 10:22:59 +0200 Subject: RFR: 8150219: ReferenceError in 1.8.0_72 In-Reply-To: References: Message-ID: 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 problem for the most predominant and reasonable use case. What I absolutely do not agree with is to have a method to evaluate a script with a non-default ScriptContext and then ignore that ScriptContext on invocation of a function obtained from that evaluation. This breaks about every assumption a somewhat experienced JavaScript developer would have, and it also is a regression against JDK up to u71. Note that my change does not go back to the behavior of pre-u72, so engine?s default ScriptContext is still used for all globals created the ?normal? way (e.g. using NashornScriptEngine.createBindings method, or the default global created in NashornScriptEngine constructor). The only case we set the engine this way is for evals with a non-default ScriptEngine which does not already have a Nashorn global. This is of course also reflected by the tests you added for JDK-8138616 still passing. I hope we can find some common ground here. Hannes > Am 14.06.2016 um 04:32 schrieb Sundararajan Athijegannathan : > > Sorry, I'm not sure I'm comfortable with this fix :( > > Global.setScriptContext sets the ScriptContext for the *current thread* > [because that Global class methods set thread local]. This means that > this ReferenceError goes away only for the thread in a new Global is > created and associated with that ScriptContext. For other threads, > you'll continue to get ReferenceError. > > The root of the issue is the Invocable's methods are expected to use the > default ScriptContext. That means that if you eval code or put globals > in another ScriptContext, you can't do Invocable calls on it! That is > the limitation of javax.script. While eval's have ScriptContext, > Bindings accepting variants, there are no similar methods exists for > Invocable and Compilable. These two use script engine's default > ScriptContext! > > BTW, there is clear Nashorn alternative - which is to use > jdk.scripting.api.scripting.ScriptObjectMirror's call or eval method. > These take care of using the right global in which the function was > defined - lexical 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?fer wrote: >>> >>> 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 with a Nashorn Global, but only in the very specific case where a script is evaluated with a non-default ScriptContext that does not have a Nashorn Global yet, and the Global is created for that specific ScriptContext. Also, we use the existing setScriptContext method and ThreadLocal field in Global instead of introducing an extra field as we had it before. >>> >>> The purpose is to make functions obtained from such globals use the ScriptContext they were evaluated with. >>> >>> Thanks, >>> Hannes >>> > From axeld at pinc-software.de Tue Jun 14 08:41:01 2016 From: axeld at pinc-software.de (=?UTF-8?Q?Axel_D=c3=b6rfler?=) Date: Tue, 14 Jun 2016 10:41:01 +0200 Subject: Share context/JS bindings In-Reply-To: <04A1114A-DBC6-4ECA-B71F-91D15FEBFA6B@oracle.com> References: <8d64c559-092d-34c6-67ab-b4dc08684119@pinc-software.de> <04A1114A-DBC6-4ECA-B71F-91D15FEBFA6B@oracle.com> Message-ID: <9b2ca05e-bec7-7cc7-5845-97463292d6ff@pinc-software.de> Hi Hannes, Am 14/06/2016 um 09:53 schrieb Hannes Walln?fer: > 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 possibly we should fix our > implementation of clear to include non-configurable (declared) > variables. That would be great! Is there any other way of reusing the JS context that does not exhibit the issue? Recreating for every call is very expensive (having a single engine, using compiled scripts, and sharing the context brought a 100x speedup in execution time -- and the context was responsible for half of it IIRC). Bye, Axel. From benjamin.sieffert at metrigo.de Tue Jun 14 09:06:56 2016 From: benjamin.sieffert at metrigo.de (Benjamin Sieffert) Date: Tue, 14 Jun 2016 11:06:56 +0200 Subject: Share context/JS bindings In-Reply-To: <9b2ca05e-bec7-7cc7-5845-97463292d6ff@pinc-software.de> References: <8d64c559-092d-34c6-67ab-b4dc08684119@pinc-software.de> <04A1114A-DBC6-4ECA-B71F-91D15FEBFA6B@oracle.com> <9b2ca05e-bec7-7cc7-5845-97463292d6ff@pinc-software.de> Message-ID: Hi Axel, I tried doing a similar thing for a while and found there is no pretty way to do it from the Java-side. I think the best solution is making your JS-code have no global state, by utilizing function scopes* and maybe small (custom, mutable) context objects that get passed around. Generally, the public API for providing bindings etc. certainly looks nice, but in practice I think some use-cases might just be too complicated to be supported. Regards, Benjamin * For your small example, simply wrapping it in a function would already get rid of the issue and would even be completely thread-safe. (function() { var found; print found; found = 1; })(); On 14 June 2016 at 10:41, Axel D?rfler wrote: > Hi Hannes, > > Am 14/06/2016 um 09:53 schrieb Hannes Walln?fer: >> >> 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 possibly we should fix our >> implementation of clear to include non-configurable (declared) >> variables. > > > That would be great! > > Is there any other way of reusing the JS context that does not exhibit the > issue? Recreating for every call is very expensive (having a single engine, > using compiled scripts, and sharing the context brought a 100x speedup in > execution time -- and the context was responsible for half of it IIRC). > > Bye, > Axel. -- Benjamin Sieffert metrigo GmbH | A Zalando Company Lagerstra?e 36 20357 Hamburg Gesch?ftsf?hrer: Tobias Schlottke, Philipp Erler Die Gesellschaft ist eingetragen beim Registergericht Hamburg HRB 120447 From axeld at pinc-software.de Tue Jun 14 09:58:28 2016 From: axeld at pinc-software.de (=?UTF-8?Q?Axel_D=c3=b6rfler?=) Date: Tue, 14 Jun 2016 11:58:28 +0200 Subject: Share context/JS bindings In-Reply-To: References: <8d64c559-092d-34c6-67ab-b4dc08684119@pinc-software.de> <04A1114A-DBC6-4ECA-B71F-91D15FEBFA6B@oracle.com> <9b2ca05e-bec7-7cc7-5845-97463292d6ff@pinc-software.de> Message-ID: Hi Benjamin, Am 14/06/2016 um 11:06 schrieb Benjamin Sieffert: > I tried doing a similar thing for a while and found there is no pretty > way to do it from the Java-side. > I think the best solution is making your JS-code have no global state, > by utilizing function scopes* and maybe small (custom, mutable) > context objects that get passed around. Yeah, it looks like I'll just have to document the fact for the time being, and hope for future improvements :-) > Generally, the public API for providing bindings etc. certainly looks > nice, but in practice I think some use-cases might just be too > complicated to be supported. I think having a low overhead solution to reusing contexts would be very beneficial. Another thing that I missed was Invocable supporting passing a ScriptContext. Thanks! Bye, Axel. From tonyzakula at gmail.com Tue Jun 14 15:52:56 2016 From: tonyzakula at gmail.com (Tony Zakula) Date: Tue, 14 Jun 2016 10:52:56 -0500 Subject: Share context/JS bindings In-Reply-To: References: <8d64c559-092d-34c6-67ab-b4dc08684119@pinc-software.de> <04A1114A-DBC6-4ECA-B71F-91D15FEBFA6B@oracle.com> <9b2ca05e-bec7-7cc7-5845-97463292d6ff@pinc-software.de> Message-ID: Have you tried reusing the engine and only creating a new Context for every run? Also, have you turned on caching for scripts as the engine parameter? We have seen good performance doing that. Would be interested to know if you do. Thanks, Tony On Jun 14, 2016 4:58 AM, "Axel D?rfler" wrote: Hi Benjamin, Am 14/06/2016 um 11:06 schrieb Benjamin Sieffert: > I tried doing a similar thing for a while and found there is no pretty > way to do it from the Java-side. > I think the best solution is making your JS-code have no global state, > by utilizing function scopes* and maybe small (custom, mutable) > context objects that get passed around. > Yeah, it looks like I'll just have to document the fact for the time being, and hope for future improvements :-) Generally, the public API for providing bindings etc. certainly looks > nice, but in practice I think some use-cases might just be too > complicated to be supported. > I think having a low overhead solution to reusing contexts would be very beneficial. Another thing that I missed was Invocable supporting passing a ScriptContext. Thanks! Bye, Axel. From axeld at pinc-software.de Tue Jun 14 17:20:59 2016 From: axeld at pinc-software.de (=?UTF-8?Q?Axel_D=c3=b6rfler?=) Date: Tue, 14 Jun 2016 19:20:59 +0200 Subject: Share context/JS bindings In-Reply-To: References: <8d64c559-092d-34c6-67ab-b4dc08684119@pinc-software.de> <04A1114A-DBC6-4ECA-B71F-91D15FEBFA6B@oracle.com> <9b2ca05e-bec7-7cc7-5845-97463292d6ff@pinc-software.de> Message-ID: Am 14/06/2016 um 17:52 schrieb Tony Zakula: > Have you tried reusing the engine and only creating a new Context for > every run? Sure, but creating a new ScriptContext has a substantial overhead. AFAICT sharing the engine only enables caching the compiled scripts, as well as making Compilables work. IIRC both (reuse context, reuse engine) had a similar impact on performance. > Also, have you turned on caching for scripts as the engine > parameter? We have seen good performance doing that. Would be > interested to know if you do. I'm not sure what you mean. AFAIK Nashorn caches scripts automatically as soon as you start reusing your engine, you don't even have to use Compilables. Bye, Axel. From tonyzakula at gmail.com Tue Jun 14 20:09:09 2016 From: tonyzakula at gmail.com (Tony Zakula) Date: Tue, 14 Jun 2016 15:09:09 -0500 Subject: Share context/JS bindings In-Reply-To: References: <8d64c559-092d-34c6-67ab-b4dc08684119@pinc-software.de> <04A1114A-DBC6-4ECA-B71F-91D15FEBFA6B@oracle.com> <9b2ca05e-bec7-7cc7-5845-97463292d6ff@pinc-software.de> Message-ID: Interesting. We use on global context and create a new engine context with each run. The initial compile of several scripts is over 100ms, but then we see that drop to under 10ms. The context creation seems to have very little overhead. We have not timed that specifically though, just total process time. We use the built in Nashorn compiles, not compilable. On Jun 14, 2016 12:21 PM, "Axel D?rfler" wrote: > Am 14/06/2016 um 17:52 schrieb Tony Zakula: > >> Have you tried reusing the engine and only creating a new Context for >> every run? >> > > Sure, but creating a new ScriptContext has a substantial overhead. > AFAICT sharing the engine only enables caching the compiled scripts, as > well as making Compilables work. IIRC both (reuse context, reuse engine) > had a similar impact on performance. > > Also, have you turned on caching for scripts as the engine >> parameter? We have seen good performance doing that. Would be >> interested to know if you do. >> > > I'm not sure what you mean. AFAIK Nashorn caches scripts automatically as > soon as you start reusing your engine, you don't even have to use > Compilables. > > Bye, > Axel. > > From srinivas.dama at oracle.com Wed Jun 15 06:54:53 2016 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Tue, 14 Jun 2016 23:54:53 -0700 (PDT) Subject: RFR:8158817 Message-ID: <8d50b8be-212c-42db-892a-93d936881246@default> Hi, Please review http://cr.openjdk.java.net/~sdama/8158817/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8158817 Regards, Srinivas From axeld at pinc-software.de Wed Jun 15 09:24:44 2016 From: axeld at pinc-software.de (=?UTF-8?Q?Axel_D=c3=b6rfler?=) Date: Wed, 15 Jun 2016 11:24:44 +0200 Subject: Share context/JS bindings In-Reply-To: References: <8d64c559-092d-34c6-67ab-b4dc08684119@pinc-software.de> <04A1114A-DBC6-4ECA-B71F-91D15FEBFA6B@oracle.com> <9b2ca05e-bec7-7cc7-5845-97463292d6ff@pinc-software.de> Message-ID: <0804fd0b-f7e6-7a09-066c-5ee7a25d7a27@pinc-software.de> Am 14.06.2016 um 22:09 schrieb Tony Zakula: > Interesting. We use on global context and create a new engine context > with each run. The initial compile of several scripts is over 100ms, > but then we see that drop to under 10ms. The context creation seems to > have very little overhead. We have not timed that specifically though, > just total process time. In my special use case which was a very short JavaScript that was used as Comparator, actual execution time was very short, so the impact of the optimizations were pretty obvious. Sorting about 15000 entries took way over 10 minutes before any optimization. IIRC after using a single global engine this dropped to about 2 minutes. After also reusing the JS context, it went down to 10 seconds. Bye, Axel. From michael.haupt at oracle.com Wed Jun 15 11:21:05 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 15 Jun 2016 13:21:05 +0200 Subject: RFR:8158817 In-Reply-To: <8d50b8be-212c-42db-892a-93d936881246@default> References: <8d50b8be-212c-42db-892a-93d936881246@default> Message-ID: <05600B62-467C-4787-976E-CFBE0EA2CF2E@oracle.com> Hi Srini, lower-case thumbs up, with these corrections: * Math.ceil, Math.floor: ... returns argument it self ... -> ... returns argument itself ... * Math.random, Math.sin: insert space after comma Best, Michael > Am 15.06.2016 um 08:54 schrieb Srinivas Dama : > > Hi, > > Please review > http://cr.openjdk.java.net/~sdama/8158817/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8158817 > > Regards, > Srinivas -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From hannes.wallnoefer at oracle.com Wed Jun 15 11:47:01 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 15 Jun 2016 13:47:01 +0200 Subject: RFR:8158817 In-Reply-To: <05600B62-467C-4787-976E-CFBE0EA2CF2E@oracle.com> References: <8d50b8be-212c-42db-892a-93d936881246@default> <05600B62-467C-4787-976E-CFBE0EA2CF2E@oracle.com> Message-ID: <3D2E1C05-FC6D-4F91-A295-32D5C6A0759F@oracle.com> 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 self ... -> ... returns argument itself ... > * Math.random, Math.sin: insert space after comma > > Best, > > Michael > >> Am 15.06.2016 um 08:54 schrieb Srinivas Dama : >> >> Hi, >> >> Please review >> http://cr.openjdk.java.net/~sdama/8158817/webrev.00/ >> for https://bugs.openjdk.java.net/browse/JDK-8158817 >> >> Regards, >> Srinivas > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | LangTools Team | Nashorn > Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany > > ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > Oracle is committed to developing practices and products that help protect the environment > From hannes.wallnoefer at oracle.com Wed Jun 15 13:02:29 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 15 Jun 2016 15:02:29 +0200 Subject: Share context/JS bindings In-Reply-To: <0804fd0b-f7e6-7a09-066c-5ee7a25d7a27@pinc-software.de> References: <8d64c559-092d-34c6-67ab-b4dc08684119@pinc-software.de> <04A1114A-DBC6-4ECA-B71F-91D15FEBFA6B@oracle.com> <9b2ca05e-bec7-7cc7-5845-97463292d6ff@pinc-software.de> <0804fd0b-f7e6-7a09-066c-5ee7a25d7a27@pinc-software.de> Message-ID: 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 15.06.2016 um 11:24 schrieb Axel D?rfler : > > Am 14.06.2016 um 22:09 schrieb Tony Zakula: >> Interesting. We use on global context and create a new engine context >> with each run. The initial compile of several scripts is over 100ms, >> but then we see that drop to under 10ms. The context creation seems to >> have very little overhead. We have not timed that specifically though, >> just total process time. > > In my special use case which was a very short JavaScript that was used as Comparator, actual execution time was very short, so the impact of the optimizations were pretty obvious. > Sorting about 15000 entries took way over 10 minutes before any optimization. IIRC after using a single global engine this dropped to about 2 minutes. After also reusing the JS context, it went down to 10 seconds. > > Bye, > Axel. > From hannes.wallnoefer at oracle.com Wed Jun 15 15:20:32 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 15 Jun 2016 17:20:32 +0200 Subject: RFR: 8150219: ReferenceError in 1.8.0_72 In-Reply-To: References: Message-ID: <6F58235D-F8B2-4DBF-B33B-3A7239183219@oracle.com> I?ve uploaded a new webrev that reintroduces the Global.initscontext field instead of reusing the current context thread local so it will behave the same from all threads. Please review. http://cr.openjdk.java.net/~hannesw/8150219/webrev.01/ Thanks, Hannes > Am 14.06.2016 um 10:22 schrieb Hannes Walln?fer : > > 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 problem for the most predominant and reasonable use case. > > What I absolutely do not agree with is to have a method to evaluate a script with a non-default ScriptContext and then ignore that ScriptContext on invocation of a function obtained from that evaluation. This breaks about every assumption a somewhat experienced JavaScript developer would have, and it also is a regression against JDK up to u71. > > Note that my change does not go back to the behavior of pre-u72, so engine?s default ScriptContext is still used for all globals created the ?normal? way (e.g. using NashornScriptEngine.createBindings method, or the default global created in NashornScriptEngine constructor). The only case we set the engine this way is for evals with a non-default ScriptEngine which does not already have a Nashorn global. This is of course also reflected by the tests you added for JDK-8138616 still passing. > > I hope we can find some common ground here. > > Hannes > > >> Am 14.06.2016 um 04:32 schrieb Sundararajan Athijegannathan : >> >> Sorry, I'm not sure I'm comfortable with this fix :( >> >> Global.setScriptContext sets the ScriptContext for the *current thread* >> [because that Global class methods set thread local]. This means that >> this ReferenceError goes away only for the thread in a new Global is >> created and associated with that ScriptContext. For other threads, >> you'll continue to get ReferenceError. >> >> The root of the issue is the Invocable's methods are expected to use the >> default ScriptContext. That means that if you eval code or put globals >> in another ScriptContext, you can't do Invocable calls on it! That is >> the limitation of javax.script. While eval's have ScriptContext, >> Bindings accepting variants, there are no similar methods exists for >> Invocable and Compilable. These two use script engine's default >> ScriptContext! >> >> BTW, there is clear Nashorn alternative - which is to use >> jdk.scripting.api.scripting.ScriptObjectMirror's call or eval method. >> These take care of using the right global in which the function was >> defined - lexical 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?fer wrote: >>>> >>>> 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 with a Nashorn Global, but only in the very specific case where a script is evaluated with a non-default ScriptContext that does not have a Nashorn Global yet, and the Global is created for that specific ScriptContext. Also, we use the existing setScriptContext method and ThreadLocal field in Global instead of introducing an extra field as we had it before. >>>> >>>> The purpose is to make functions obtained from such globals use the ScriptContext they were evaluated with. >>>> >>>> Thanks, >>>> Hannes >>>> >> > From marcus at lagergren.net Thu Jun 16 07:42:37 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Thu, 16 Jun 2016 09:42:37 +0200 Subject: RFR:8158817 In-Reply-To: <3D2E1C05-FC6D-4F91-A295-32D5C6A0759F@oracle.com> References: <8d50b8be-212c-42db-892a-93d936881246@default> <05600B62-467C-4787-976E-CFBE0EA2CF2E@oracle.com> <3D2E1C05-FC6D-4F91-A295-32D5C6A0759F@oracle.com> Message-ID: <3A302F32-F677-4AD1-9D6C-828AC3373E6D@lagergren.net> +1 with Michael?s and Hannes?s comments. Who extracts and prints this documentation, though? /M > On 15 Jun 2016, at 13:47, Hannes Walln?fer wrote: > > n From hannes.wallnoefer at oracle.com Thu Jun 16 08:00:30 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Thu, 16 Jun 2016 10:00:30 +0200 Subject: RFR:8158817 In-Reply-To: <3A302F32-F677-4AD1-9D6C-828AC3373E6D@lagergren.net> References: <8d50b8be-212c-42db-892a-93d936881246@default> <05600B62-467C-4787-976E-CFBE0EA2CF2E@oracle.com> <3D2E1C05-FC6D-4F91-A295-32D5C6A0759F@oracle.com> <3A302F32-F677-4AD1-9D6C-828AC3373E6D@lagergren.net> Message-ID: You can display it in jjs shell by typing the function name and pressing . Hannes > Am 16.06.2016 um 09:42 schrieb Marcus Lagergren : > > +1 with Michael?s and Hannes?s comments. > > Who extracts and prints this documentation, though? > > /M > >> On 15 Jun 2016, at 13:47, Hannes Walln?fer wrote: >> >> n > From tonyzakula at gmail.com Thu Jun 16 19:11:50 2016 From: tonyzakula at gmail.com (Tony Zakula) Date: Thu, 16 Jun 2016 14:11:50 -0500 Subject: Share context/JS bindings In-Reply-To: References: <8d64c559-092d-34c6-67ab-b4dc08684119@pinc-software.de> <04A1114A-DBC6-4ECA-B71F-91D15FEBFA6B@oracle.com> <9b2ca05e-bec7-7cc7-5845-97463292d6ff@pinc-software.de> <0804fd0b-f7e6-7a09-066c-5ee7a25d7a27@pinc-software.de> Message-ID: Thank you Hannes. That would be great. We have tried using clear before too. @Axel - Thank you for the 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.wallnoefer at oracle.com> wrote: > 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 15.06.2016 um 11:24 schrieb Axel D?rfler : > > > > Am 14.06.2016 um 22:09 schrieb Tony Zakula: > >> Interesting. We use on global context and create a new engine context > >> with each run. The initial compile of several scripts is over 100ms, > >> but then we see that drop to under 10ms. The context creation seems to > >> have very little overhead. We have not timed that specifically though, > >> just total process time. > > > > In my special use case which was a very short JavaScript that was used > as Comparator, actual execution time was very short, so the impact of the > optimizations were pretty obvious. > > Sorting about 15000 entries took way over 10 minutes before any > optimization. IIRC after using a single global engine this dropped to about > 2 minutes. After also reusing the JS context, it went down to 10 seconds. > > > > Bye, > > Axel. > > > > From hannes.wallnoefer at oracle.com Fri Jun 17 09:16:44 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Fri, 17 Jun 2016 11:16:44 +0200 Subject: RFR 8156614: Lazy parsing of ES6 shorthand method syntax is broken Message-ID: <3272727E-1D49-49A7-B40B-722CB7935F6C@oracle.com> 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 From michael.haupt at oracle.com Fri Jun 17 09:50:05 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 17 Jun 2016 11:50:05 +0200 Subject: RFR 8156614: Lazy parsing of ES6 shorthand method syntax is broken In-Reply-To: <3272727E-1D49-49A7-B40B-722CB7935F6C@oracle.com> References: <3272727E-1D49-49A7-B40B-722CB7935F6C@oracle.com> Message-ID: <0F9645B9-526E-42CD-8AD9-62AF41C52386@oracle.com> Hi Hannes, lower-case thumbs up. Best, Michael > Am 17.06.2016 um 11:16 schrieb Hannes Walln?fer : > > 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 -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From hannes.wallnoefer at oracle.com Fri Jun 17 13:54:43 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Fri, 17 Jun 2016 15:54:43 +0200 Subject: RFR: 8159589: ScriptObjectMirror.clear() should remove all enumerable properties Message-ID: <3A82DBCB-D58B-47E0-84F5-FF96BE3D6CAF@oracle.com> 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 not clearing properties that are non-configurable, and even throwing type error when invoking clear() on an object that contains such properties. IMO, there?s no need to follow JS semantics since we?re calling the method from outside of JS. With this change, clear() will remove all enumerable properties. This also makes the method consistent with size() and isEmpty(), which previously could return values > 0 and false after calling clear(). On a practical note, this is really convenient with global objects as it can be used to return globals to their initial state after an eval, removing all declared vars and functions but leaving the (non-enumerable) built-ins. Hannes From sundararajan.athijegannathan at oracle.com Mon Jun 20 04:02:51 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 20 Jun 2016 09:32:51 +0530 Subject: RFR: 8150219: ReferenceError in 1.8.0_72 In-Reply-To: <6F58235D-F8B2-4DBF-B33B-3A7239183219@oracle.com> References: <6F58235D-F8B2-4DBF-B33B-3A7239183219@oracle.com> Message-ID: <382f4067-0783-0911-e21b-fc4cd5f4ec08@oracle.com> Looks like a reasonable compromise! +1 -Sundar On 6/15/2016 8:50 PM, Hannes Walln?fer wrote: > I?ve uploaded a new webrev that reintroduces the Global.initscontext field instead of reusing the current context thread local so it will behave the same from all threads. Please review. > > http://cr.openjdk.java.net/~hannesw/8150219/webrev.01/ > > Thanks, > Hannes > > >> Am 14.06.2016 um 10:22 schrieb Hannes Walln?fer : >> >> 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 problem for the most predominant and reasonable use case. >> >> What I absolutely do not agree with is to have a method to evaluate a script with a non-default ScriptContext and then ignore that ScriptContext on invocation of a function obtained from that evaluation. This breaks about every assumption a somewhat experienced JavaScript developer would have, and it also is a regression against JDK up to u71. >> >> Note that my change does not go back to the behavior of pre-u72, so engine?s default ScriptContext is still used for all globals created the ?normal? way (e.g. using NashornScriptEngine.createBindings method, or the default global created in NashornScriptEngine constructor). The only case we set the engine this way is for evals with a non-default ScriptEngine which does not already have a Nashorn global. This is of course also reflected by the tests you added for JDK-8138616 still passing. >> >> I hope we can find some common ground here. >> >> Hannes >> >> >>> Am 14.06.2016 um 04:32 schrieb Sundararajan Athijegannathan : >>> >>> Sorry, I'm not sure I'm comfortable with this fix :( >>> >>> Global.setScriptContext sets the ScriptContext for the *current thread* >>> [because that Global class methods set thread local]. This means that >>> this ReferenceError goes away only for the thread in a new Global is >>> created and associated with that ScriptContext. For other threads, >>> you'll continue to get ReferenceError. >>> >>> The root of the issue is the Invocable's methods are expected to use the >>> default ScriptContext. That means that if you eval code or put globals >>> in another ScriptContext, you can't do Invocable calls on it! That is >>> the limitation of javax.script. While eval's have ScriptContext, >>> Bindings accepting variants, there are no similar methods exists for >>> Invocable and Compilable. These two use script engine's default >>> ScriptContext! >>> >>> BTW, there is clear Nashorn alternative - which is to use >>> jdk.scripting.api.scripting.ScriptObjectMirror's call or eval method. >>> These take care of using the right global in which the function was >>> defined - lexical 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?fer wrote: >>>>> >>>>> 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 with a Nashorn Global, but only in the very specific case where a script is evaluated with a non-default ScriptContext that does not have a Nashorn Global yet, and the Global is created for that specific ScriptContext. Also, we use the existing setScriptContext method and ThreadLocal field in Global instead of introducing an extra field as we had it before. >>>>> >>>>> The purpose is to make functions obtained from such globals use the ScriptContext they were evaluated with. >>>>> >>>>> Thanks, >>>>> Hannes >>>>> From sundararajan.athijegannathan at oracle.com Mon Jun 20 04:05:34 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 20 Jun 2016 09:35:34 +0530 Subject: RFR 8156614: Lazy parsing of ES6 shorthand method syntax is broken In-Reply-To: <3272727E-1D49-49A7-B40B-722CB7935F6C@oracle.com> References: <3272727E-1D49-49A7-B40B-722CB7935F6C@oracle.com> Message-ID: <4f007337-3a7f-fdae-dd30-c3b3961396d7@oracle.com> +1 -Sundar On 6/17/2016 2:46 PM, Hannes Walln?fer wrote: > 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 From sundararajan.athijegannathan at oracle.com Mon Jun 20 06:35:24 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 20 Jun 2016 12:05:24 +0530 Subject: RFR: 8159589: ScriptObjectMirror.clear() should remove all enumerable properties In-Reply-To: <3A82DBCB-D58B-47E0-84F5-FF96BE3D6CAF@oracle.com> References: <3A82DBCB-D58B-47E0-84F5-FF96BE3D6CAF@oracle.com> Message-ID: <7420c874-124a-d628-601d-03b63355bf97@oracle.com> Few questions: 1) So, we are allowing delete on non-configurable properties. Is this fine from optimization PoV? i.e., we can't assume that a non-configurable property can not be deleted. 2) ScriptObject.clear - it appears previously, it deleted inherited properties too. Now only immediate properties. Intended? do we have tests to cover these cases? 3) Global's clear method clears lexicalScope. Do we need a test for ES6 lexical scope clear? -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/browse/JDK-8159589 > Webrev: http://cr.openjdk.java.net/~hannesw/8159589/webrev.00/ > > In our current implementation, ScriptObjectMirror.clear() observes JS semantics by not clearing properties that are non-configurable, and even throwing type error when invoking clear() on an object that contains such properties. > > IMO, there?s no need to follow JS semantics since we?re calling the method from outside of JS. With this change, clear() will remove all enumerable properties. This also makes the method consistent with size() and isEmpty(), which previously could return values > 0 and false after calling clear(). > > On a practical note, this is really convenient with global objects as it can be used to return globals to their initial state after an eval, removing all declared vars and functions but leaving the (non-enumerable) built-ins. > > Hannes From pmlopes at gmail.com Mon Jun 20 12:13:55 2016 From: pmlopes at gmail.com (Paulo Lopes) Date: Mon, 20 Jun 2016 14:13:55 +0200 Subject: Register a custom type converter (is it possible)? Message-ID: Hi, I've been reading the documentation, wiki and the examples from Nashorn and have a question that I cannot find a yes/no answer to. Say for example that I've an application that leverages on Nashorn for JavaScript execution but its core is in Java. In my Java code I've a interface like: interface Foo { void doSomething(Bar bar); } Now from Nashorn I'd like to invoke the method "doSomething" like: foo.doSomethin({key: 'value'}); As expected this won't work since Nashorn does not know how to cast from "JSObject" to "Bar" however I'd like to register somewhere/somehow (this is what I don't know) a helper class/method/something where I could do this. I also do not want to bring Nashorn API/types to Java to I'm not looking for something like: class Bar implements JSObject { ... } Is this possible? and it is possible with JDK8? Thanks! Paulo From sundararajan.athijegannathan at oracle.com Mon Jun 20 12:58:34 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 20 Jun 2016 18:28:34 +0530 Subject: Register a custom type converter (is it possible)? In-Reply-To: References: Message-ID: <1e44d530-7e93-d8b2-ca6c-ade5b6d8b5a5@oracle.com> No, there are no such conversion hooks. But, if any of your Java methods accept java.util.Maps, you can pass script objects. Also, if any of your Java methods accept List or Java arrays, you can pass script arrays. var m = new java.util.HashMap(); m.putAll({ foo: 44 }); var l = new java.util.ArrayList(); l.addAll([44, 546, 676]); -Sundar On 6/20/2016 5:43 PM, Paulo Lopes wrote: > Hi, > > > I've been reading the documentation, wiki and the examples from Nashorn and > have a question that I cannot find a yes/no answer to. Say for example that > I've an application that leverages on Nashorn for JavaScript execution but > its core is in Java. In my Java code I've a interface like: > > interface Foo { > > void doSomething(Bar bar); > > } > > > Now from Nashorn I'd like to invoke the method "doSomething" like: > > > foo.doSomethin({key: 'value'}); > > > As expected this won't work since Nashorn does not know how to cast from > "JSObject" to "Bar" however I'd like to register somewhere/somehow (this is > what I don't know) a helper class/method/something where I could do this. I > also do not want to bring Nashorn API/types to Java to I'm not looking for > something like: > > > class Bar implements JSObject { ... } > > > Is this possible? and it is possible with JDK8? > > > Thanks! > Paulo From pmlopes at gmail.com Mon Jun 20 13:39:50 2016 From: pmlopes at gmail.com (Paulo Lopes) Date: Mon, 20 Jun 2016 15:39:50 +0200 Subject: Register a custom type converter (is it possible)? In-Reply-To: <1e44d530-7e93-d8b2-ca6c-ade5b6d8b5a5@oracle.com> References: <1e44d530-7e93-d8b2-ca6c-ade5b6d8b5a5@oracle.com> Message-ID: That is what I was trying to avoid. In the java side I'd like to have specific types `Bar` so i get type safety, compile time validation, etc... all the things you expect from a strongly typed language, and on Nashorn side I'd like to have the freedom of dynamic typed languages, also if my contract is already deployed I'd break the whole compatibility/contract by changing the method signatures to be Map. I was trying to get my head around the dynalink stuff but sadly it does not apply to this problem. On Mon, Jun 20, 2016 at 2:58 PM, Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > No, there are no such conversion hooks. > > But, if any of your Java methods accept java.util.Maps, you can pass > script objects. Also, if any of your Java methods accept List or Java > arrays, you can pass script arrays. > > var m = new java.util.HashMap(); > > m.putAll({ foo: 44 }); > > var l = new java.util.ArrayList(); > > l.addAll([44, 546, 676]); > > -Sundar > > On 6/20/2016 5:43 PM, Paulo Lopes wrote: > > Hi, > > > > > > I've been reading the documentation, wiki and the examples from Nashorn > and > > have a question that I cannot find a yes/no answer to. Say for example > that > > I've an application that leverages on Nashorn for JavaScript execution > but > > its core is in Java. In my Java code I've a interface like: > > > > interface Foo { > > > > void doSomething(Bar bar); > > > > } > > > > > > Now from Nashorn I'd like to invoke the method "doSomething" like: > > > > > > foo.doSomethin({key: 'value'}); > > > > > > As expected this won't work since Nashorn does not know how to cast from > > "JSObject" to "Bar" however I'd like to register somewhere/somehow (this > is > > what I don't know) a helper class/method/something where I could do > this. I > > also do not want to bring Nashorn API/types to Java to I'm not looking > for > > something like: > > > > > > class Bar implements JSObject { ... } > > > > > > Is this possible? and it is possible with JDK8? > > > > > > Thanks! > > Paulo > > -- Paulo Lopes www.jetdrone.com From sundararajan.athijegannathan at oracle.com Mon Jun 20 13:45:46 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 20 Jun 2016 19:15:46 +0530 Subject: Register a custom type converter (is it possible)? In-Reply-To: References: <1e44d530-7e93-d8b2-ca6c-ade5b6d8b5a5@oracle.com> Message-ID: <6dc84c23-b182-0cae-3609-fb5602658d14@oracle.com> It may be simpler to provider conversion functions to your users. Like "makeBar" functions - you could load those conversion script functions before evaluating other scripts. Keeps the java side typesafe and provide arbitrary mapping from script side... -Sundar On 6/20/2016 7:09 PM, Paulo Lopes wrote: > That is what I was trying to avoid. In the java side I'd like to have > specific types `Bar` so i get type safety, compile time validation, > etc... all the things you expect from a strongly typed language, and > on Nashorn side I'd like to have the freedom of dynamic typed > languages, also if my contract is already deployed I'd break the whole > compatibility/contract by changing the method signatures to be Map. > > I was trying to get my head around the dynalink stuff but sadly it > does not apply to this problem. > > > > On Mon, Jun 20, 2016 at 2:58 PM, Sundararajan Athijegannathan > > wrote: > > No, there are no such conversion hooks. > > But, if any of your Java methods accept java.util.Maps, you can pass > script objects. Also, if any of your Java methods accept List or Java > arrays, you can pass script arrays. > > var m = new java.util.HashMap(); > > m.putAll({ foo: 44 }); > > var l = new java.util.ArrayList(); > > l.addAll([44, 546, 676]); > > -Sundar > > On 6/20/2016 5:43 PM, Paulo Lopes wrote: > > Hi, > > > > > > I've been reading the documentation, wiki and the examples from > Nashorn and > > have a question that I cannot find a yes/no answer to. Say for > example that > > I've an application that leverages on Nashorn for JavaScript > execution but > > its core is in Java. In my Java code I've a interface like: > > > > interface Foo { > > > > void doSomething(Bar bar); > > > > } > > > > > > Now from Nashorn I'd like to invoke the method "doSomething" like: > > > > > > foo.doSomethin({key: 'value'}); > > > > > > As expected this won't work since Nashorn does not know how to > cast from > > "JSObject" to "Bar" however I'd like to register > somewhere/somehow (this is > > what I don't know) a helper class/method/something where I could > do this. I > > also do not want to bring Nashorn API/types to Java to I'm not > looking for > > something like: > > > > > > class Bar implements JSObject { ... } > > > > > > Is this possible? and it is possible with JDK8? > > > > > > Thanks! > > Paulo > > > > > -- > Paulo Lopes > www.jetdrone.com From sundararajan.athijegannathan at oracle.com Mon Jun 20 13:45:52 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 20 Jun 2016 19:15:52 +0530 Subject: Register a custom type converter (is it possible)? In-Reply-To: References: <1e44d530-7e93-d8b2-ca6c-ade5b6d8b5a5@oracle.com> Message-ID: It may be simpler to provider conversion functions to your users. Like "makeBar" functions - you could load those conversion script functions before evaluating other scripts. Keeps the java side typesafe and provide arbitrary mapping from script side... -Sundar On 6/20/2016 7:09 PM, Paulo Lopes wrote: > That is what I was trying to avoid. In the java side I'd like to have > specific types `Bar` so i get type safety, compile time validation, > etc... all the things you expect from a strongly typed language, and > on Nashorn side I'd like to have the freedom of dynamic typed > languages, also if my contract is already deployed I'd break the whole > compatibility/contract by changing the method signatures to be Map. > > I was trying to get my head around the dynalink stuff but sadly it > does not apply to this problem. > > > > On Mon, Jun 20, 2016 at 2:58 PM, Sundararajan Athijegannathan > > wrote: > > No, there are no such conversion hooks. > > But, if any of your Java methods accept java.util.Maps, you can pass > script objects. Also, if any of your Java methods accept List or Java > arrays, you can pass script arrays. > > var m = new java.util.HashMap(); > > m.putAll({ foo: 44 }); > > var l = new java.util.ArrayList(); > > l.addAll([44, 546, 676]); > > -Sundar > > On 6/20/2016 5:43 PM, Paulo Lopes wrote: > > Hi, > > > > > > I've been reading the documentation, wiki and the examples from > Nashorn and > > have a question that I cannot find a yes/no answer to. Say for > example that > > I've an application that leverages on Nashorn for JavaScript > execution but > > its core is in Java. In my Java code I've a interface like: > > > > interface Foo { > > > > void doSomething(Bar bar); > > > > } > > > > > > Now from Nashorn I'd like to invoke the method "doSomething" like: > > > > > > foo.doSomethin({key: 'value'}); > > > > > > As expected this won't work since Nashorn does not know how to > cast from > > "JSObject" to "Bar" however I'd like to register > somewhere/somehow (this is > > what I don't know) a helper class/method/something where I could > do this. I > > also do not want to bring Nashorn API/types to Java to I'm not > looking for > > something like: > > > > > > class Bar implements JSObject { ... } > > > > > > Is this possible? and it is possible with JDK8? > > > > > > Thanks! > > Paulo > > > > > -- > Paulo Lopes > www.jetdrone.com From marcus at lagergren.net Mon Jun 20 18:11:30 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Mon, 20 Jun 2016 20:11:30 +0200 Subject: RFR 8156614: Lazy parsing of ES6 shorthand method syntax is broken In-Reply-To: <3272727E-1D49-49A7-B40B-722CB7935F6C@oracle.com> References: <3272727E-1D49-49A7-B40B-722CB7935F6C@oracle.com> Message-ID: +1 > On 17 Jun 2016, at 11:16, Hannes Walln?fer wrote: > > 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 From hannes.wallnoefer at oracle.com Tue Jun 21 12:49:01 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 21 Jun 2016 14:49:01 +0200 Subject: RFR: 8159589: ScriptObjectMirror.clear() should remove all enumerable properties In-Reply-To: <7420c874-124a-d628-601d-03b63355bf97@oracle.com> References: <3A82DBCB-D58B-47E0-84F5-FF96BE3D6CAF@oracle.com> <7420c874-124a-d628-601d-03b63355bf97@oracle.com> Message-ID: <5A879601-DBC9-4E4C-AB2C-55E056B75B29@oracle.com> Thanks for the review, Sundar. Replies inline below. > Am 20.06.2016 um 08:35 schrieb Sundararajan Athijegannathan : > > Few questions: > > 1) So, we are allowing delete on non-configurable properties. Is this > fine from optimization PoV? i.e., we can't assume that a > non-configurable property can not be deleted. This is indeed a problem. I wrote a test where clear is invoked on the global object between evaluation of the same script, and callsites are not invalidated properly. I don?t think it is worth to change the way global variable callsites are guarded for this change, so I?m withdrawing this RFR and closing the issue. Thanks for spotting this, Sundar. > 2) ScriptObject.clear - it appears previously, it deleted inherited > properties too. Now only immediate properties. Intended? do we have > tests to cover these cases? > No, we previously/currently also only delete properties on the object itself. Even though we use a property iterator that includes inherited properties, the deletion will only take place for properties on the object itself. I originally thought this was just an inefficiency, but now that I think of it actually is a bug as it could result in removal of non-enumerable properties. I?ll file an Jira issue for it. > 3) Global's clear method clears lexicalScope. Do we need a test for ES6 > lexical scope clear? True, but not a problem anymore 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/browse/JDK-8159589 >> Webrev: http://cr.openjdk.java.net/~hannesw/8159589/webrev.00/ >> >> In our current implementation, ScriptObjectMirror.clear() observes JS semantics by not clearing properties that are non-configurable, and even throwing type error when invoking clear() on an object that contains such properties. >> >> IMO, there?s no need to follow JS semantics since we?re calling the method from outside of JS. With this change, clear() will remove all enumerable properties. This also makes the method consistent with size() and isEmpty(), which previously could return values > 0 and false after calling clear(). >> >> On a practical note, this is really convenient with global objects as it can be used to return globals to their initial state after an eval, removing all declared vars and functions but leaving the (non-enumerable) built-ins. >> >> Hannes > From hannes.wallnoefer at oracle.com Tue Jun 21 13:33:42 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 21 Jun 2016 15:33:42 +0200 Subject: Share context/JS bindings In-Reply-To: References: <8d64c559-092d-34c6-67ab-b4dc08684119@pinc-software.de> <04A1114A-DBC6-4ECA-B71F-91D15FEBFA6B@oracle.com> <9b2ca05e-bec7-7cc7-5845-97463292d6ff@pinc-software.de> <0804fd0b-f7e6-7a09-066c-5ee7a25d7a27@pinc-software.de> Message-ID: <1AA92707-4CA5-44B6-97AA-8375E4EE8D5A@oracle.com> Unfortunately, there is a problem with invalidation of callsites that Sundar brought up in the review thread for the issue I filed. I?ve thought about it, but there isn?t any easy way to do this without giving up significant benefits on the other side. I?m closing the issue as ?won?t fix?, but I?ll continue thinking about a solution for quicker creation of global objects. Hannes > Am 16.06.2016 um 21:11 schrieb Tony Zakula : > > Thank you Hannes. That would be great. We have tried using clear before too. > > @Axel - Thank you for the 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 wrote: > 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 15.06.2016 um 11:24 schrieb Axel D?rfler : > > > > Am 14.06.2016 um 22:09 schrieb Tony Zakula: > >> Interesting. We use on global context and create a new engine context > >> with each run. The initial compile of several scripts is over 100ms, > >> but then we see that drop to under 10ms. The context creation seems to > >> have very little overhead. We have not timed that specifically though, > >> just total process time. > > > > In my special use case which was a very short JavaScript that was used as Comparator, actual execution time was very short, so the impact of the optimizations were pretty obvious. > > Sorting about 15000 entries took way over 10 minutes before any optimization. IIRC after using a single global engine this dropped to about 2 minutes. After also reusing the JS context, it went down to 10 seconds. > > > > Bye, > > Axel. > > > > From tonyzakula at gmail.com Wed Jun 22 02:41:33 2016 From: tonyzakula at gmail.com (Tony Zakula) Date: Tue, 21 Jun 2016 21:41:33 -0500 Subject: Share context/JS bindings In-Reply-To: <1AA92707-4CA5-44B6-97AA-8375E4EE8D5A@oracle.com> References: <8d64c559-092d-34c6-67ab-b4dc08684119@pinc-software.de> <04A1114A-DBC6-4ECA-B71F-91D15FEBFA6B@oracle.com> <9b2ca05e-bec7-7cc7-5845-97463292d6ff@pinc-software.de> <0804fd0b-f7e6-7a09-066c-5ee7a25d7a27@pinc-software.de> <1AA92707-4CA5-44B6-97AA-8375E4EE8D5A@oracle.com> Message-ID: Thank you for looking into this. Much appreciated. We are working on a large Nashorn project we hope to share soon. On Jun 21, 2016 8:33 AM, "Hannes Walln?fer" wrote: > Unfortunately, there is a problem with invalidation of callsites that > Sundar brought up in the review thread for the issue I filed. > > I?ve thought about it, but there isn?t any easy way to do this without > giving up significant benefits on the other side. I?m closing the issue as > ?won?t fix?, but I?ll continue thinking about a solution for quicker > creation of global objects. > > Hannes > > > > Am 16.06.2016 um 21:11 schrieb Tony Zakula : > > > > Thank you Hannes. That would be great. We have tried using clear > before too. > > > > @Axel - Thank you for the 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.wallnoefer at oracle.com> wrote: > > 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 15.06.2016 um 11:24 schrieb Axel D?rfler : > > > > > > Am 14.06.2016 um 22:09 schrieb Tony Zakula: > > >> Interesting. We use on global context and create a new engine context > > >> with each run. The initial compile of several scripts is over 100ms, > > >> but then we see that drop to under 10ms. The context creation seems > to > > >> have very little overhead. We have not timed that specifically > though, > > >> just total process time. > > > > > > In my special use case which was a very short JavaScript that was used > as Comparator, actual execution time was very short, so the impact of the > optimizations were pretty obvious. > > > Sorting about 15000 entries took way over 10 minutes before any > optimization. IIRC after using a single global engine this dropped to about > 2 minutes. After also reusing the JS context, it went down to 10 seconds. > > > > > > Bye, > > > Axel. > > > > > > > > > From hannes.wallnoefer at oracle.com Wed Jun 22 12:10:51 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 22 Jun 2016 14:10:51 +0200 Subject: RFR: 8159977: typeof operator does not see lexical bindings declared in other scripts Message-ID: <01F3F3C9-7EB2-4D33-9259-8584E2FB8D32@oracle.com> 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 From sundararajan.athijegannathan at oracle.com Wed Jun 22 13:41:24 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 22 Jun 2016 19:11:24 +0530 Subject: RFR: 8159977: typeof operator does not see lexical bindings declared in other scripts In-Reply-To: <01F3F3C9-7EB2-4D33-9259-8584E2FB8D32@oracle.com> References: <01F3F3C9-7EB2-4D33-9259-8584E2FB8D32@oracle.com> Message-ID: <2e7e3f3b-4d0a-6874-2c2d-348ef66a68cb@oracle.com> +1 On 6/22/2016 5:40 PM, Hannes Walln?fer wrote: > 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 From james.laskey at oracle.com Wed Jun 22 18:25:25 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 22 Jun 2016 15:25:25 -0300 Subject: Share context/JS bindings In-Reply-To: References: <8d64c559-092d-34c6-67ab-b4dc08684119@pinc-software.de> <04A1114A-DBC6-4ECA-B71F-91D15FEBFA6B@oracle.com> <9b2ca05e-bec7-7cc7-5845-97463292d6ff@pinc-software.de> <0804fd0b-f7e6-7a09-066c-5ee7a25d7a27@pinc-software.de> <1AA92707-4CA5-44B6-97AA-8375E4EE8D5A@oracle.com> Message-ID: Tony, We will keep this general issue open as https://bugs.openjdk.java.net/browse/JDK-8160103 and revisit later on. ? Jim > On Jun 21, 2016, at 11:41 PM, Tony Zakula wrote: > > Thank you for looking into this. Much appreciated. We are working on a > large Nashorn project we hope to share soon. > On Jun 21, 2016 8:33 AM, "Hannes Walln?fer" > wrote: > >> Unfortunately, there is a problem with invalidation of callsites that >> Sundar brought up in the review thread for the issue I filed. >> >> I?ve thought about it, but there isn?t any easy way to do this without >> giving up significant benefits on the other side. I?m closing the issue as >> ?won?t fix?, but I?ll continue thinking about a solution for quicker >> creation of global objects. >> >> Hannes >> >> >>> Am 16.06.2016 um 21:11 schrieb Tony Zakula : >>> >>> Thank you Hannes. That would be great. We have tried using clear >> before too. >>> >>> @Axel - Thank you for the 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.wallnoefer at oracle.com> wrote: >>> 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 15.06.2016 um 11:24 schrieb Axel D?rfler : >>>> >>>> Am 14.06.2016 um 22:09 schrieb Tony Zakula: >>>>> Interesting. We use on global context and create a new engine context >>>>> with each run. The initial compile of several scripts is over 100ms, >>>>> but then we see that drop to under 10ms. The context creation seems >> to >>>>> have very little overhead. We have not timed that specifically >> though, >>>>> just total process time. >>>> >>>> In my special use case which was a very short JavaScript that was used >> as Comparator, actual execution time was very short, so the impact of the >> optimizations were pretty obvious. >>>> Sorting about 15000 entries took way over 10 minutes before any >> optimization. IIRC after using a single global engine this dropped to about >> 2 minutes. After also reusing the JS context, it went down to 10 seconds. >>>> >>>> Bye, >>>> Axel. >>>> >>> >>> >> >> From sundararajan.athijegannathan at oracle.com Thu Jun 23 04:28:10 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 23 Jun 2016 09:58:10 +0530 Subject: RFR 8160141: removed deprecated method calls in nashorn code Message-ID: Please review http://cr.openjdk.java.net/~sundar/8160141/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8160141 Thanks, Sundar From michael.haupt at oracle.com Thu Jun 23 06:11:35 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 23 Jun 2016 08:11:35 +0200 Subject: RFR 8160141: removed deprecated method calls in nashorn code In-Reply-To: References: Message-ID: <379BE829-94FA-4234-9082-69214B289B51@oracle.com> Hi Sundar, thumbs up. Best, Michael > Am 23.06.2016 um 06:28 schrieb Sundararajan Athijegannathan : > > Please review http://cr.openjdk.java.net/~sundar/8160141/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8160141 > > Thanks, > > Sundar > -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From hannes.wallnoefer at oracle.com Thu Jun 23 07:01:35 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Thu, 23 Jun 2016 09:01:35 +0200 Subject: RFR 8160141: removed deprecated method calls in nashorn code In-Reply-To: <379BE829-94FA-4234-9082-69214B289B51@oracle.com> References: <379BE829-94FA-4234-9082-69214B289B51@oracle.com> Message-ID: <97CDA2D9-9076-4959-B3FE-8D73738566A7@oracle.com> 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 http://cr.openjdk.java.net/~sundar/8160141/webrev.00/ for >> https://bugs.openjdk.java.net/browse/JDK-8160141 >> >> Thanks, >> >> Sundar >> > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | LangTools Team | Nashorn > Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany > > ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > Oracle is committed to developing practices and products that help protect the environment > From szegedia at gmail.com Thu Jun 23 07:19:05 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Thu, 23 Jun 2016 09:19:05 +0200 Subject: RFR 8160141: removed deprecated method calls in nashorn code In-Reply-To: References: Message-ID: A minor point: the usual idiom we use for rethrowing RuntimeException is } catch(final RuntimeException e) { throw e; } catch(final Exception e) { throw new RuntimeException(e); } instead of what you did in Global.java with an "if" in the "catch" +1 other than that. Attila. On Thu, Jun 23, 2016 at 6:28 AM, Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > Please review http://cr.openjdk.java.net/~sundar/8160141/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8160141 > > Thanks, > > Sundar > > From sundararajan.athijegannathan at oracle.com Thu Jun 23 08:45:10 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 23 Jun 2016 14:15:10 +0530 Subject: RFR 8160141: removed deprecated method calls in nashorn code In-Reply-To: References: Message-ID: Hi, Sorry I pushed with 2 reviews from Hannes and Michael. I'll take care of this cleanup in a later fix. Thanks, -Sundar On 6/23/2016 12:49 PM, Attila Szegedi wrote: > A minor point: the usual idiom we use for rethrowing RuntimeException is > > } catch(final RuntimeException e) { > throw e; > } catch(final Exception e) { > throw new RuntimeException(e); > } > > instead of what you did in Global.java with an "if" in the "catch" > > +1 other than that. > > Attila. > > > On Thu, Jun 23, 2016 at 6:28 AM, Sundararajan Athijegannathan > > wrote: > > Please review > http://cr.openjdk.java.net/~sundar/8160141/webrev.00/ > for > https://bugs.openjdk.java.net/browse/JDK-8160141 > > Thanks, > > Sundar > > From hannes.wallnoefer at oracle.com Thu Jun 23 11:42:43 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Thu, 23 Jun 2016 13:42:43 +0200 Subject: RFR: 8137240: Negative lookahead in RegEx breaks backreference Message-ID: <6E2841BF-18D5-4D2A-B220-1EA1898A4CF4@oracle.com> Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8137240 Webrev: http://cr.openjdk.java.net/~hannesw/8137240/webrev/ Thanks, Hannes From michael.haupt at oracle.com Thu Jun 23 14:48:53 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 23 Jun 2016 16:48:53 +0200 Subject: RFR: 8137240: Negative lookahead in RegEx breaks backreference In-Reply-To: <6E2841BF-18D5-4D2A-B220-1EA1898A4CF4@oracle.com> References: <6E2841BF-18D5-4D2A-B220-1EA1898A4CF4@oracle.com> Message-ID: <73B6098F-7AC8-4AF4-AA48-6A9BDABF8F14@oracle.com> Hi Hannes, thumbs up. Best, Michael > Am 23.06.2016 um 13:42 schrieb Hannes Walln?fer : > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8137240 > Webrev: http://cr.openjdk.java.net/~hannesw/8137240/webrev/ > > Thanks, > Hannes -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From hannes.wallnoefer at oracle.com Fri Jun 24 11:23:35 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Fri, 24 Jun 2016 13:23:35 +0200 Subject: RFR: 8073653: Secondary heredoc eating wrong lines. Message-ID: <5A4537FE-41DB-48C0-8E20-E52CED1BC6ED@oracle.com> 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 From michael.haupt at oracle.com Fri Jun 24 12:02:15 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 24 Jun 2016 14:02:15 +0200 Subject: RFR: 8073653: Secondary heredoc eating wrong lines. In-Reply-To: <5A4537FE-41DB-48C0-8E20-E52CED1BC6ED@oracle.com> References: <5A4537FE-41DB-48C0-8E20-E52CED1BC6ED@oracle.com> Message-ID: <462FDCC8-65D9-4728-B98E-A5B790E9C5CB@oracle.com> Hi Hannes, thumbs up. I love the test in all its nestedness. :-) Best, Michael > Am 24.06.2016 um 13:23 schrieb Hannes Walln?fer : > > 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 -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From james.laskey at oracle.com Fri Jun 24 12:06:08 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 24 Jun 2016 09:06:08 -0300 Subject: RFR: 8073653: Secondary heredoc eating wrong lines. In-Reply-To: <5A4537FE-41DB-48C0-8E20-E52CED1BC6ED@oracle.com> References: <5A4537FE-41DB-48C0-8E20-E52CED1BC6ED@oracle.com> Message-ID: <29469D9F-0E3B-4061-90BA-7FFDF2EBB0AB@oracle.com> +1 > On Jun 24, 2016, at 8:23 AM, Hannes Walln?fer wrote: > > 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 From ttarrant at redhat.com Mon Jun 27 15:26:31 2016 From: ttarrant at redhat.com (Tristan Tarrant) Date: Mon, 27 Jun 2016 17:26:31 +0200 Subject: Serialization of javascript lambdas Message-ID: <577145A7.8080700@redhat.com> Hi all, I've been playing with Nashorn in combination with the Streams API in the context of being able to run functions in a distributed environment (i.e. Infinispan's server-side scripting). In plain Java, a lambda has a SerializedLambda form which basically encapsulates all of the coordinates that allow the recreation of a MethodHandle on the remote side. This obviously assumes that the remote classloader has access to the exact same bytecode. Nashorn lambdas however do not (or cannot?) have a SerializedLambda representation, so I'm looking for an alternative way to identify them. Consider the following snippet which is a (dumb) example: map.entrySet().stream().map(function(e) e.getValue()) On the Java side, the map method takes a Function parameter. Inspecting the parameter I see that Nashorn has created an adapter class at runtime (jdk.nashorn.javaadapters.java.util.function.Function) and that the apply() method of that class is a BoundMethodHandle$Species_LL. Unfortunately there is no reference to the original ScriptFunction, which would otherwise allow me to invoke toSource() on it, simply serialize that string, send it to the remote node, compile it and invoke it. Inspecting further I've understood that anonymous javascript functions get bound to method handles identified by a name in the form of L:x where "x" looks like a counter. Compiling the same script on multiple nodes, the identifier is consistent, however I've found no way to invoke those methodhandles on the remote nodes. I've noticed that it's possible to get the ScriptFunction passed as a parameter (needsCallee), but I haven't understood how to do that. So my question is: given a Nashorn Java adapter generated from a ScriptFunction, is there a way for me to identify the ScriptFunction it originates from and to invoke that same function "by name" on a remote node which has the same script ? Thanks Tristan From axel.faust.g at googlemail.com Mon Jun 27 21:53:31 2016 From: axel.faust.g at googlemail.com (Axel Faust) Date: Mon, 27 Jun 2016 23:53:31 +0200 Subject: Source.baseURL() overhead when using custom URL protocol scheme / stream handler Message-ID: Hello, TL;DR : I use custom URL protocol schemes and stream handlers that are not globally registered. This causes excessive handler resolution overhead in URL.getURLStreamHandler() called implicitly in Source.baseURL(). I can't find a way to avoid this overhead (in JDK 1.8.0_71) without two impossible choices: complete refactoring or registering a JVM global URLStreamHandlerFactory. A test case for sampling the overhead is provided in https://gist.github.com/AFaust/04ec0c65a560e306b6b547dcaf38fd21 This is a follow-up to my tweet of mine from yesterday: https://twitter.com/ReluctantBird83/status/747145726703075328 In this tweet I was commenting on an obversvation I made from CPU sampling the current state of my Nashorn-based script engine for the open source ECM platform Alfresco (https://github.com/AFaust/alfresco-nashorn-script-engine ). What prompted the comment where the following hot spot methods from my jvisualvm sampling session, when I was testing a trivial ReST endpoint backed by a Nashorn-executed script: "Hot Spots - Method","Self Time [%]","Self Time","Self Time (CPU)","Total Time","Total Time (CPU)","Samples" "java.lang.invoke.LambdaForm$MH.771977685.linkToCallSite()","15.152575","793.365 ms","793.365 ms","1126.483 ms","1126.483 ms","63" "java.net.URL.()","11.350913","594.316 ms","594.316 ms","594.316 ms","594.316 ms","33" "java.lang.Throwable.()","7.248728","379.532 ms","379.532 ms","379.532 ms","379.532 ms","21" [...] "jdk.nashorn.internal.runtime.Source.baseURL()","0.0","0.0 ms","0.0 ms","594.316 ms","594.316 ms","33" [...] The 1st and 3rd hot spot are directly related to frequently called code in my scripts / my utilities and somewhat expected, but I was not expecting the URL constructor to be up there. The backtraces view of the snapshot showed Source.baseURL() as the immediate and only caller of the URL constructor, even though I have other calls in my code which apparently don't trigger the sampling threshold. The total time per execution of the script is around 50-60ms with few outliers up to 90-100ms (sampling started only after reasonably stable state was reached). Sampling was limited specifically on the jdk.nashorn.*, jdk.internal.* and de.* packages. A bit of background on my Alfresco Nashorn engine: - embedded into a web application that may potentially run in Tomcat or JEE servers (JBoss, WebSphere...) - JavaScript in Alfresco is extensively used for embedded rules, policies (event handling), ReST API endpoints and server-side UI pre-composition - use of an AMD-like module system allowing flexible extension of script API by 3rd party developers of Alfresco "addons" - one file per module, lazily loaded when required by other module or executed script - frequently used "core" modules will be pre-loaded and cached on startup - scripts are referenced via "logical" URLs using custom protocol schemes to denote different script resolution and load scopes/mechanisms (example: "webscript:///my/module/id" for a module in the lookup scope for ReST endpoint scripts; some scripts may be user-managed within the content repository / database itself) - custom protocol schemes are handled by custom URL stream handlers *NOT* globally registered (to avoid interfering with other web applications or other URL-related functionality in the same JVM) It turns out that the last two points are essential. I created a generalised test case in a GitHub gist: https://gist.github.com/AFaust/04ec0c65a560e306b6b547dcaf38fd21 Essentially it is URL.getURLStreamHandler() which is responsible for the overhead. The Source.baseURL() creates a "base" name from the source URL and if the protocol is not "file://" then a new URL will be created. Since I use custom URL stream handlers and have not registered a global stream handler factory (and won't ever do so), the new URL will try to resolve the handler via URL.getURLStreamHandler(), go through all the hoops and always fail in the end. A failed resolution is never cached, so every time Source.baseURL() is called this whole process / overhead is repeated. I am currently trying to reduce all global overheads of my script engine setup, but can't find a way to avoid this overhead without registering a global URL stream factory, which is out of the question for various reasons (web application; 3rd party loaders; engine-specific semantics) or completely refactoring the engine so all scripts are copied to simple "file://" before execution (requiring constant sync-checking with original script in source storage location). Ideally, I would like the see options to provide both a base URL myself as pre-resolved information via URLReader/Global.load() and register a custom stream handler factory with my Nashorn engine instance. This would allow "simple" loaders to use simple URL-Strings instead of real URL instances to load script files via Global.load(), as well as "complex" loaders to continue using state-ful custom URL stream handlers where necessary. And it would allow Nashorn to resolve a potential custom URL stream handler before relegating to default JVM global handling if no handler is found. I am sure I am not aware of all the implications - and certainly I am aware that such a change in a core class might be impossible - but URL.getURLStreamHandler() should really cache failed stream handler resolutions and avoid repeating the entire lookup routine... Kind regards, and sorry for this overly long "summary" Axel Faust From sundararajan.athijegannathan at oracle.com Tue Jun 28 04:31:31 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 28 Jun 2016 10:01:31 +0530 Subject: Serialization of javascript lambdas In-Reply-To: <577145A7.8080700@redhat.com> References: <577145A7.8080700@redhat.com> Message-ID: <8b707d9d-c89e-67f5-04b5-9153930cf50c@oracle.com> No, none of the nashorn objects are Serializable and that is by design! As you've found out, Nashorn objects are too 'tied' to the current execution state - in which most of the objects are not Serializable. -Sundar On 6/27/2016 8:56 PM, Tristan Tarrant wrote: > Hi all, > > I've been playing with Nashorn in combination with the Streams API in > the context of being able to run functions in a distributed > environment (i.e. Infinispan's server-side scripting). > > In plain Java, a lambda has a SerializedLambda form which basically > encapsulates all of the coordinates that allow the recreation of a > MethodHandle on the remote side. This obviously assumes that the > remote classloader has access to the exact same bytecode. > > Nashorn lambdas however do not (or cannot?) have a SerializedLambda > representation, so I'm looking for an alternative way to identify them. > > Consider the following snippet which is a (dumb) example: > > map.entrySet().stream().map(function(e) e.getValue()) > > On the Java side, the map method takes a Function parameter. > Inspecting the parameter I see that Nashorn has created an adapter > class at runtime > (jdk.nashorn.javaadapters.java.util.function.Function) and that the > apply() method of that class is a BoundMethodHandle$Species_LL. > Unfortunately there is no reference to the original ScriptFunction, > which would otherwise allow me to invoke toSource() on it, simply > serialize that string, send it to the remote node, compile it and > invoke it. > > Inspecting further I've understood that anonymous javascript functions > get bound to method handles identified by a name in the form of L:x > where "x" looks like a counter. Compiling the same script on multiple > nodes, the identifier is consistent, however I've found no way to > invoke those methodhandles on the remote nodes. > I've noticed that it's possible to get the ScriptFunction passed as a > parameter (needsCallee), but I haven't understood how to do that. > > So my question is: given a Nashorn Java adapter generated from a > ScriptFunction, is there a way for me to identify the ScriptFunction > it originates from and to invoke that same function "by name" on a > remote node which has the same script ? > > Thanks > > Tristan > From hannes.wallnoefer at oracle.com Tue Jun 28 07:02:39 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 28 Jun 2016 09:02:39 +0200 Subject: Source.baseURL() overhead when using custom URL protocol scheme / stream handler In-Reply-To: References: Message-ID: 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 registered. This causes excessive handler resolution overhead in > URL.getURLStreamHandler() called implicitly in Source.baseURL(). I can't > find a way to avoid this overhead (in JDK 1.8.0_71) without two impossible > choices: complete refactoring or registering a JVM global > URLStreamHandlerFactory. > A test case for sampling the overhead is provided in > https://gist.github.com/AFaust/04ec0c65a560e306b6b547dcaf38fd21 > > > > This is a follow-up to my tweet of mine from yesterday: > https://twitter.com/ReluctantBird83/status/747145726703075328 > In this tweet I was commenting on an obversvation I made from CPU sampling > the current state of my Nashorn-based script engine for the open source ECM > platform Alfresco (https://github.com/AFaust/alfresco-nashorn-script-engine > ). > > What prompted the comment where the following hot spot methods from my > jvisualvm sampling session, when I was testing a trivial ReST endpoint > backed by a Nashorn-executed script: > > "Hot Spots - Method","Self Time [%]","Self Time","Self Time (CPU)","Total > Time","Total Time (CPU)","Samples" > "java.lang.invoke.LambdaForm$MH.771977685.linkToCallSite()","15.152575","793.365 > ms","793.365 ms","1126.483 ms","1126.483 ms","63" > "java.net.URL.()","11.350913","594.316 ms","594.316 ms","594.316 > ms","594.316 ms","33" > "java.lang.Throwable.()","7.248728","379.532 ms","379.532 > ms","379.532 ms","379.532 ms","21" > [...] > "jdk.nashorn.internal.runtime.Source.baseURL()","0.0","0.0 ms","0.0 > ms","594.316 ms","594.316 ms","33" > [...] > > The 1st and 3rd hot spot are directly related to frequently called code in > my scripts / my utilities and somewhat expected, but I was not expecting > the URL constructor to be up there. > The backtraces view of the snapshot showed Source.baseURL() as the > immediate and only caller of the URL constructor, even though I have other > calls in my code which apparently don't trigger the sampling threshold. > The total time per execution of the script is around 50-60ms with few > outliers up to 90-100ms (sampling started only after reasonably stable > state was reached). Sampling was limited specifically on the jdk.nashorn.*, > jdk.internal.* and de.* packages. > > A bit of background on my Alfresco Nashorn engine: > - embedded into a web application that may potentially run in Tomcat or JEE > servers (JBoss, WebSphere...) > - JavaScript in Alfresco is extensively used for embedded rules, policies > (event handling), ReST API endpoints and server-side UI pre-composition > - use of an AMD-like module system allowing flexible extension of script > API by 3rd party developers of Alfresco "addons" > - one file per module, lazily loaded when required by other module or > executed script > - frequently used "core" modules will be pre-loaded and cached on startup > - scripts are referenced via "logical" URLs using custom protocol schemes > to denote different script resolution and load scopes/mechanisms (example: > "webscript:///my/module/id" for a module in the lookup scope for ReST > endpoint scripts; some scripts may be user-managed within the content > repository / database itself) > - custom protocol schemes are handled by custom URL stream handlers *NOT* > globally registered (to avoid interfering with other web applications or > other URL-related functionality in the same JVM) > > > It turns out that the last two points are essential. I created a > generalised test case in a GitHub gist: > https://gist.github.com/AFaust/04ec0c65a560e306b6b547dcaf38fd21 > Essentially it is URL.getURLStreamHandler() which is responsible for the > overhead. The Source.baseURL() creates a "base" name from the source URL > and if the protocol is not "file://" then a new URL will be created. Since > I use custom URL stream handlers and have not registered a global stream > handler factory (and won't ever do so), the new URL will try to resolve the > handler via URL.getURLStreamHandler(), go through all the hoops and always > fail in the end. A failed resolution is never cached, so every time > Source.baseURL() is called this whole process / overhead is repeated. > > > I am currently trying to reduce all global overheads of my script engine > setup, but can't find a way to avoid this overhead without registering a > global URL stream factory, which is out of the question for various reasons > (web application; 3rd party loaders; engine-specific semantics) or > completely refactoring the engine so all scripts are copied to simple > "file://" before execution (requiring constant sync-checking with original > script in source storage location). > > Ideally, I would like the see options to provide both a base URL myself as > pre-resolved information via URLReader/Global.load() and register a custom > stream handler factory with my Nashorn engine instance. This would allow > "simple" loaders to use simple URL-Strings instead of real URL instances to > load script files via Global.load(), as well as "complex" loaders to > continue using state-ful custom URL stream handlers where necessary. And it > would allow Nashorn to resolve a potential custom URL stream handler before > relegating to default JVM global handling if no handler is found. > > I am sure I am not aware of all the implications - and certainly I am aware > that such a change in a core class might be impossible - but > URL.getURLStreamHandler() should really cache failed stream handler > resolutions and avoid repeating the entire lookup routine... > > > Kind regards, and sorry for this overly long "summary" > Axel Faust From ttarrant at redhat.com Tue Jun 28 08:29:21 2016 From: ttarrant at redhat.com (Tristan Tarrant) Date: Tue, 28 Jun 2016 10:29:21 +0200 Subject: Serialization of javascript lambdas In-Reply-To: <8b707d9d-c89e-67f5-04b5-9153930cf50c@oracle.com> References: <577145A7.8080700@redhat.com> <8b707d9d-c89e-67f5-04b5-9153930cf50c@oracle.com> Message-ID: <57723561.8010207@redhat.com> Yes, I don't expect them to be serializable, but just allow me to identify them. Is there a way to intercept the generation of the MethodHandle so that it can be "decorated" with the original ScriptFunction ? Under what circumstances would the ScriptFunctionData.needsCallee() be triggered ? Tristan On 28/06/16 06:31, Sundararajan Athijegannathan wrote: > No, none of the nashorn objects are Serializable and that is by design! > As you've found out, Nashorn objects are too 'tied' to the current > execution state - in which most of the objects are not Serializable. > > -Sundar > > > On 6/27/2016 8:56 PM, Tristan Tarrant wrote: >> Hi all, >> >> I've been playing with Nashorn in combination with the Streams API in >> the context of being able to run functions in a distributed >> environment (i.e. Infinispan's server-side scripting). >> >> In plain Java, a lambda has a SerializedLambda form which basically >> encapsulates all of the coordinates that allow the recreation of a >> MethodHandle on the remote side. This obviously assumes that the >> remote classloader has access to the exact same bytecode. >> >> Nashorn lambdas however do not (or cannot?) have a SerializedLambda >> representation, so I'm looking for an alternative way to identify them. >> >> Consider the following snippet which is a (dumb) example: >> >> map.entrySet().stream().map(function(e) e.getValue()) >> >> On the Java side, the map method takes a Function parameter. >> Inspecting the parameter I see that Nashorn has created an adapter >> class at runtime >> (jdk.nashorn.javaadapters.java.util.function.Function) and that the >> apply() method of that class is a BoundMethodHandle$Species_LL. >> Unfortunately there is no reference to the original ScriptFunction, >> which would otherwise allow me to invoke toSource() on it, simply >> serialize that string, send it to the remote node, compile it and >> invoke it. >> >> Inspecting further I've understood that anonymous javascript functions >> get bound to method handles identified by a name in the form of L:x >> where "x" looks like a counter. Compiling the same script on multiple >> nodes, the identifier is consistent, however I've found no way to >> invoke those methodhandles on the remote nodes. >> I've noticed that it's possible to get the ScriptFunction passed as a >> parameter (needsCallee), but I haven't understood how to do that. >> >> So my question is: given a Nashorn Java adapter generated from a >> ScriptFunction, is there a way for me to identify the ScriptFunction >> it originates from and to invoke that same function "by name" on a >> remote node which has the same script ? >> >> Thanks >> >> Tristan >> > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From ttarrant at redhat.com Tue Jun 28 08:29:48 2016 From: ttarrant at redhat.com (Tristan Tarrant) Date: Tue, 28 Jun 2016 10:29:48 +0200 Subject: Serialization of javascript lambdas In-Reply-To: <8b707d9d-c89e-67f5-04b5-9153930cf50c@oracle.com> References: <577145A7.8080700@redhat.com> <8b707d9d-c89e-67f5-04b5-9153930cf50c@oracle.com> Message-ID: <5772357C.9050207@redhat.com> Yes, I don't expect them to be serializable, but just allow me to identify them. Is there a way to intercept the generation of the MethodHandle so that it can be "decorated" with the original ScriptFunction ? Under what circumstances would the ScriptFunctionData.needsCallee() be triggered ? Tristan On 28/06/16 06:31, Sundararajan Athijegannathan wrote: > No, none of the nashorn objects are Serializable and that is by design! > As you've found out, Nashorn objects are too 'tied' to the current > execution state - in which most of the objects are not Serializable. > > -Sundar > > > On 6/27/2016 8:56 PM, Tristan Tarrant wrote: >> Hi all, >> >> I've been playing with Nashorn in combination with the Streams API in >> the context of being able to run functions in a distributed >> environment (i.e. Infinispan's server-side scripting). >> >> In plain Java, a lambda has a SerializedLambda form which basically >> encapsulates all of the coordinates that allow the recreation of a >> MethodHandle on the remote side. This obviously assumes that the >> remote classloader has access to the exact same bytecode. >> >> Nashorn lambdas however do not (or cannot?) have a SerializedLambda >> representation, so I'm looking for an alternative way to identify them. >> >> Consider the following snippet which is a (dumb) example: >> >> map.entrySet().stream().map(function(e) e.getValue()) >> >> On the Java side, the map method takes a Function parameter. >> Inspecting the parameter I see that Nashorn has created an adapter >> class at runtime >> (jdk.nashorn.javaadapters.java.util.function.Function) and that the >> apply() method of that class is a BoundMethodHandle$Species_LL. >> Unfortunately there is no reference to the original ScriptFunction, >> which would otherwise allow me to invoke toSource() on it, simply >> serialize that string, send it to the remote node, compile it and >> invoke it. >> >> Inspecting further I've understood that anonymous javascript functions >> get bound to method handles identified by a name in the form of L:x >> where "x" looks like a counter. Compiling the same script on multiple >> nodes, the identifier is consistent, however I've found no way to >> invoke those methodhandles on the remote nodes. >> I've noticed that it's possible to get the ScriptFunction passed as a >> parameter (needsCallee), but I haven't understood how to do that. >> >> So my question is: given a Nashorn Java adapter generated from a >> ScriptFunction, is there a way for me to identify the ScriptFunction >> it originates from and to invoke that same function "by name" on a >> remote node which has the same script ? >> >> Thanks >> >> Tristan >> > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From sundararajan.athijegannathan at oracle.com Tue Jun 28 08:53:25 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 28 Jun 2016 14:23:25 +0530 Subject: Serialization of javascript lambdas In-Reply-To: <5772357C.9050207@redhat.com> References: <577145A7.8080700@redhat.com> <8b707d9d-c89e-67f5-04b5-9153930cf50c@oracle.com> <5772357C.9050207@redhat.com> Message-ID: No, that is treated as an implementation detail. There is no way to intercept method handle creation in java adapters. With jdk9, all jdk.nashorn.internal.* packages are concealed packages of nashorn module (=> jdk.nashorn.internal.runtime.ScriptFunction is not an exposed type - only accessible inside nashorn module). -Sundar On 6/28/2016 1:59 PM, Tristan Tarrant wrote: > Yes, I don't expect them to be serializable, but just allow me to > identify them. > Is there a way to intercept the generation of the MethodHandle so that > it can be "decorated" with the original ScriptFunction ? > > Under what circumstances would the ScriptFunctionData.needsCallee() be > triggered ? > > Tristan > > On 28/06/16 06:31, Sundararajan Athijegannathan wrote: >> No, none of the nashorn objects are Serializable and that is by design! >> As you've found out, Nashorn objects are too 'tied' to the current >> execution state - in which most of the objects are not Serializable. >> >> -Sundar >> >> >> On 6/27/2016 8:56 PM, Tristan Tarrant wrote: >>> Hi all, >>> >>> I've been playing with Nashorn in combination with the Streams API in >>> the context of being able to run functions in a distributed >>> environment (i.e. Infinispan's server-side scripting). >>> >>> In plain Java, a lambda has a SerializedLambda form which basically >>> encapsulates all of the coordinates that allow the recreation of a >>> MethodHandle on the remote side. This obviously assumes that the >>> remote classloader has access to the exact same bytecode. >>> >>> Nashorn lambdas however do not (or cannot?) have a SerializedLambda >>> representation, so I'm looking for an alternative way to identify them. >>> >>> Consider the following snippet which is a (dumb) example: >>> >>> map.entrySet().stream().map(function(e) e.getValue()) >>> >>> On the Java side, the map method takes a Function parameter. >>> Inspecting the parameter I see that Nashorn has created an adapter >>> class at runtime >>> (jdk.nashorn.javaadapters.java.util.function.Function) and that the >>> apply() method of that class is a BoundMethodHandle$Species_LL. >>> Unfortunately there is no reference to the original ScriptFunction, >>> which would otherwise allow me to invoke toSource() on it, simply >>> serialize that string, send it to the remote node, compile it and >>> invoke it. >>> >>> Inspecting further I've understood that anonymous javascript functions >>> get bound to method handles identified by a name in the form of L:x >>> where "x" looks like a counter. Compiling the same script on multiple >>> nodes, the identifier is consistent, however I've found no way to >>> invoke those methodhandles on the remote nodes. >>> I've noticed that it's possible to get the ScriptFunction passed as a >>> parameter (needsCallee), but I haven't understood how to do that. >>> >>> So my question is: given a Nashorn Java adapter generated from a >>> ScriptFunction, is there a way for me to identify the ScriptFunction >>> it originates from and to invoke that same function "by name" on a >>> remote node which has the same script ? >>> >>> Thanks >>> >>> Tristan >>> >> > From hannes.wallnoefer at oracle.com Tue Jun 28 09:21:41 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 28 Jun 2016 11:21:41 +0200 Subject: Source.baseURL() overhead when using custom URL protocol scheme / stream handler In-Reply-To: References: Message-ID: <7E67E8D6-8FFD-4BC1-82E0-13346FBD9760@oracle.com> Axel, I?ve filed this bug and looked at various options for fixing it: https://bugs.openjdk.java.net/browse/JDK-8160435 The simplest solution seems to be to use java.net.URI instead of java.net.URL. It provides a isOpaque() method which will properly recognize your URIs as non-hierarchical. It also provides a resolve() method to get the base URI and is not tied to I/O handlers. I?ll be posting a request for review soon. Hannes > Am 28.06.2016 um 09:02 schrieb Hannes Walln?fer : > > 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 registered. This causes excessive handler resolution overhead in >> URL.getURLStreamHandler() called implicitly in Source.baseURL(). I can't >> find a way to avoid this overhead (in JDK 1.8.0_71) without two impossible >> choices: complete refactoring or registering a JVM global >> URLStreamHandlerFactory. >> A test case for sampling the overhead is provided in >> https://gist.github.com/AFaust/04ec0c65a560e306b6b547dcaf38fd21 >> >> >> >> This is a follow-up to my tweet of mine from yesterday: >> https://twitter.com/ReluctantBird83/status/747145726703075328 >> In this tweet I was commenting on an obversvation I made from CPU sampling >> the current state of my Nashorn-based script engine for the open source ECM >> platform Alfresco (https://github.com/AFaust/alfresco-nashorn-script-engine >> ). >> >> What prompted the comment where the following hot spot methods from my >> jvisualvm sampling session, when I was testing a trivial ReST endpoint >> backed by a Nashorn-executed script: >> >> "Hot Spots - Method","Self Time [%]","Self Time","Self Time (CPU)","Total >> Time","Total Time (CPU)","Samples" >> "java.lang.invoke.LambdaForm$MH.771977685.linkToCallSite()","15.152575","793.365 >> ms","793.365 ms","1126.483 ms","1126.483 ms","63" >> "java.net.URL.()","11.350913","594.316 ms","594.316 ms","594.316 >> ms","594.316 ms","33" >> "java.lang.Throwable.()","7.248728","379.532 ms","379.532 >> ms","379.532 ms","379.532 ms","21" >> [...] >> "jdk.nashorn.internal.runtime.Source.baseURL()","0.0","0.0 ms","0.0 >> ms","594.316 ms","594.316 ms","33" >> [...] >> >> The 1st and 3rd hot spot are directly related to frequently called code in >> my scripts / my utilities and somewhat expected, but I was not expecting >> the URL constructor to be up there. >> The backtraces view of the snapshot showed Source.baseURL() as the >> immediate and only caller of the URL constructor, even though I have other >> calls in my code which apparently don't trigger the sampling threshold. >> The total time per execution of the script is around 50-60ms with few >> outliers up to 90-100ms (sampling started only after reasonably stable >> state was reached). Sampling was limited specifically on the jdk.nashorn.*, >> jdk.internal.* and de.* packages. >> >> A bit of background on my Alfresco Nashorn engine: >> - embedded into a web application that may potentially run in Tomcat or JEE >> servers (JBoss, WebSphere...) >> - JavaScript in Alfresco is extensively used for embedded rules, policies >> (event handling), ReST API endpoints and server-side UI pre-composition >> - use of an AMD-like module system allowing flexible extension of script >> API by 3rd party developers of Alfresco "addons" >> - one file per module, lazily loaded when required by other module or >> executed script >> - frequently used "core" modules will be pre-loaded and cached on startup >> - scripts are referenced via "logical" URLs using custom protocol schemes >> to denote different script resolution and load scopes/mechanisms (example: >> "webscript:///my/module/id" for a module in the lookup scope for ReST >> endpoint scripts; some scripts may be user-managed within the content >> repository / database itself) >> - custom protocol schemes are handled by custom URL stream handlers *NOT* >> globally registered (to avoid interfering with other web applications or >> other URL-related functionality in the same JVM) >> >> >> It turns out that the last two points are essential. I created a >> generalised test case in a GitHub gist: >> https://gist.github.com/AFaust/04ec0c65a560e306b6b547dcaf38fd21 >> Essentially it is URL.getURLStreamHandler() which is responsible for the >> overhead. The Source.baseURL() creates a "base" name from the source URL >> and if the protocol is not "file://" then a new URL will be created. Since >> I use custom URL stream handlers and have not registered a global stream >> handler factory (and won't ever do so), the new URL will try to resolve the >> handler via URL.getURLStreamHandler(), go through all the hoops and always >> fail in the end. A failed resolution is never cached, so every time >> Source.baseURL() is called this whole process / overhead is repeated. >> >> >> I am currently trying to reduce all global overheads of my script engine >> setup, but can't find a way to avoid this overhead without registering a >> global URL stream factory, which is out of the question for various reasons >> (web application; 3rd party loaders; engine-specific semantics) or >> completely refactoring the engine so all scripts are copied to simple >> "file://" before execution (requiring constant sync-checking with original >> script in source storage location). >> >> Ideally, I would like the see options to provide both a base URL myself as >> pre-resolved information via URLReader/Global.load() and register a custom >> stream handler factory with my Nashorn engine instance. This would allow >> "simple" loaders to use simple URL-Strings instead of real URL instances to >> load script files via Global.load(), as well as "complex" loaders to >> continue using state-ful custom URL stream handlers where necessary. And it >> would allow Nashorn to resolve a potential custom URL stream handler before >> relegating to default JVM global handling if no handler is found. >> >> I am sure I am not aware of all the implications - and certainly I am aware >> that such a change in a core class might be impossible - but >> URL.getURLStreamHandler() should really cache failed stream handler >> resolutions and avoid repeating the entire lookup routine... >> >> >> Kind regards, and sorry for this overly long "summary" >> Axel Faust > From hannes.wallnoefer at oracle.com Tue Jun 28 09:46:44 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 28 Jun 2016 11:46:44 +0200 Subject: RFR: 8160435: Source.baseURL is slow for URLs with unregistered protocol Message-ID: <9D38FF67-1827-4C93-A01E-C8DF402D02C6@oracle.com> 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 From sundararajan.athijegannathan at oracle.com Tue Jun 28 11:26:06 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 28 Jun 2016 16:56:06 +0530 Subject: RFR: 8160435: Source.baseURL is slow for URLs with unregistered protocol In-Reply-To: <9D38FF67-1827-4C93-A01E-C8DF402D02C6@oracle.com> References: <9D38FF67-1827-4C93-A01E-C8DF402D02C6@oracle.com> Message-ID: <52bbe85e-b32b-ae37-485f-f4be7edc0185@oracle.com> +1 -Sundar On 6/28/2016 3:16 PM, Hannes Walln?fer wrote: > 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 > > From tim.bell at oracle.com Wed Jun 29 01:39:07 2016 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 28 Jun 2016 18:39:07 -0700 Subject: RFR: 8160505, Automated test runs fail in nashorn because TEST_IMAGE_DIR is set by jib Message-ID: <577326BB.1030202@oracle.com> All- When using jib to run jtreg tests in an automated setting, TEST_IMAGE_DIR is set for those test suites having native code. Refer to jdk/test/Makefile or hotspot/test/Makefile for two examples. The nashorn repo does not have any native tests, so nashorn/test/Makefile should not consider TEST_IMAGE_DIR. Bug report: https://bugs.openjdk.java.net/browse/JDK-8160505 Webrev: http://cr.openjdk.java.net/~tbell/8160505/nashorn/webrev/ Tested by hand before and after applying the suggested fix. Thanks in advance- Tim From erik.joelsson at oracle.com Wed Jun 29 10:55:12 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 29 Jun 2016 12:55:12 +0200 Subject: RFR: 8160505, Automated test runs fail in nashorn because TEST_IMAGE_DIR is set by jib In-Reply-To: <577326BB.1030202@oracle.com> References: <577326BB.1030202@oracle.com> Message-ID: <5773A910.9050307@oracle.com> Looks ok to me. It's unlikely that nashorn will ever get native tests so just removing this functionality is a good solution. If we expected nashorn to need native tests anytime soon, it would likely be better to just create a placeholder directory in the test image instead. /Erik On 2016-06-29 03:39, Tim Bell wrote: > All- > > When using jib to run jtreg tests in an automated setting, > TEST_IMAGE_DIR is set for those test suites having native code. Refer > to jdk/test/Makefile or hotspot/test/Makefile for two examples. > > The nashorn repo does not have any native tests, so > nashorn/test/Makefile should not consider TEST_IMAGE_DIR. > > Bug report: > https://bugs.openjdk.java.net/browse/JDK-8160505 > > Webrev: > http://cr.openjdk.java.net/~tbell/8160505/nashorn/webrev/ > > Tested by hand before and after applying the suggested fix. > > Thanks in advance- > > Tim > From sundararajan.athijegannathan at oracle.com Wed Jun 29 11:08:57 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 29 Jun 2016 16:38:57 +0530 Subject: RFR: 8160505, Automated test runs fail in nashorn because TEST_IMAGE_DIR is set by jib In-Reply-To: <5773A910.9050307@oracle.com> References: <577326BB.1030202@oracle.com> <5773A910.9050307@oracle.com> Message-ID: <66e6e42c-1aa6-5346-3769-5b9fd6963c25@oracle.com> Looks good Yes, nashorn will not get any native tests. -Sundar On 6/29/2016 4:25 PM, Erik Joelsson wrote: > Looks ok to me. > > It's unlikely that nashorn will ever get native tests so just removing > this functionality is a good solution. If we expected nashorn to need > native tests anytime soon, it would likely be better to just create a > placeholder directory in the test image instead. > > /Erik > > On 2016-06-29 03:39, Tim Bell wrote: >> All- >> >> When using jib to run jtreg tests in an automated setting, >> TEST_IMAGE_DIR is set for those test suites having native code. Refer >> to jdk/test/Makefile or hotspot/test/Makefile for two examples. >> >> The nashorn repo does not have any native tests, so >> nashorn/test/Makefile should not consider TEST_IMAGE_DIR. >> >> Bug report: >> https://bugs.openjdk.java.net/browse/JDK-8160505 >> >> Webrev: >> http://cr.openjdk.java.net/~tbell/8160505/nashorn/webrev/ >> >> Tested by hand before and after applying the suggested fix. >> >> Thanks in advance- >> >> Tim >> > From tim.bell at oracle.com Wed Jun 29 14:27:19 2016 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 29 Jun 2016 07:27:19 -0700 Subject: RFR: 8160505, Automated test runs fail in nashorn because TEST_IMAGE_DIR is set by jib In-Reply-To: <66e6e42c-1aa6-5346-3769-5b9fd6963c25@oracle.com> References: <577326BB.1030202@oracle.com> <5773A910.9050307@oracle.com> <66e6e42c-1aa6-5346-3769-5b9fd6963c25@oracle.com> Message-ID: <5773DAC7.3070502@oracle.com> Sundar, Erik: > Looks good > > Yes, nashorn will not get any native tests. > > -Sundar > > On 6/29/2016 4:25 PM, Erik Joelsson wrote: >> Looks ok to me. Thank you for the reviews. >> It's unlikely that nashorn will ever get native tests so just removing >> this functionality is a good solution. If we expected nashorn to need >> native tests anytime soon, it would likely be better to just create a >> placeholder directory in the test image instead. Rather than do that (create a placeholder), I took the path established in other directories of 100% Java code, like langtools and jaxp. Tim >> /Erik >> >> On 2016-06-29 03:39, Tim Bell wrote: >>> All- >>> >>> When using jib to run jtreg tests in an automated setting, >>> TEST_IMAGE_DIR is set for those test suites having native code. Refer >>> to jdk/test/Makefile or hotspot/test/Makefile for two examples. >>> >>> The nashorn repo does not have any native tests, so >>> nashorn/test/Makefile should not consider TEST_IMAGE_DIR. >>> >>> Bug report: >>> https://bugs.openjdk.java.net/browse/JDK-8160505 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~tbell/8160505/nashorn/webrev/ >>> >>> Tested by hand before and after applying the suggested fix. >>> >>> Thanks in advance- >>> >>> Tim >>>