From sundararajan.athijegannathan at oracle.com Tue May 3 15:24:16 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 3 May 2016 20:54:16 +0530 Subject: RFR 8155944: ant build/test of nashorn is broken with the latest jdk9-dev build Message-ID: <1a305724-762a-f5b5-d665-742cb900e6a5@oracle.com> Hi, Please review http://cr.openjdk.java.net/~sundar/8155944/webrev/ for https://bugs.openjdk.java.net/browse/JDK-8155944 Thanks, -Sundar From james.laskey at oracle.com Tue May 3 15:26:43 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 3 May 2016 12:26:43 -0300 Subject: RFR 8155944: ant build/test of nashorn is broken with the latest jdk9-dev build In-Reply-To: <1a305724-762a-f5b5-d665-742cb900e6a5@oracle.com> References: <1a305724-762a-f5b5-d665-742cb900e6a5@oracle.com> Message-ID: <1F16E55D-172E-4FBB-849B-1587DB523003@oracle.com> +1 > On May 3, 2016, at 12:24 PM, Sundararajan Athijegannathan wrote: > > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8155944/webrev/ for > https://bugs.openjdk.java.net/browse/JDK-8155944 > > Thanks, > > -Sundar > From michael.haupt at oracle.com Wed May 4 07:58:23 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 4 May 2016 09:58:23 +0200 Subject: RFR 8155944: ant build/test of nashorn is broken with the latest jdk9-dev build In-Reply-To: <1a305724-762a-f5b5-d665-742cb900e6a5@oracle.com> References: <1a305724-762a-f5b5-d665-742cb900e6a5@oracle.com> Message-ID: Hi Sundar, lower-case thumbs up! Best, Michael > Am 03.05.2016 um 17:24 schrieb Sundararajan Athijegannathan : > > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8155944/webrev/ for > https://bugs.openjdk.java.net/browse/JDK-8155944 > > 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 Wed May 4 08:49:08 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 4 May 2016 10:49:08 +0200 Subject: Review request for JDK-8144711: (x) => x + 1 causes Assertion failure instead of SyntaxError Message-ID: <5729B784.4060609@oracle.com> Please review JDK-8144711: (x) => x + 1 causes Assertion failure instead of SyntaxError: http://cr.openjdk.java.net/~hannesw/8144711/ Thanks, Hannes From michael.haupt at oracle.com Wed May 4 09:05:19 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 4 May 2016 11:05:19 +0200 Subject: Review request for JDK-8144711: (x) => x + 1 causes Assertion failure instead of SyntaxError In-Reply-To: <5729B784.4060609@oracle.com> References: <5729B784.4060609@oracle.com> Message-ID: Hi Hannes, lower-case thumbs up! Best, Michael > Am 04.05.2016 um 10:49 schrieb Hannes Wallnoefer : > > Please review JDK-8144711: (x) => x + 1 causes Assertion failure instead of SyntaxError: > > http://cr.openjdk.java.net/~hannesw/8144711/ > > 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 michael.haupt at oracle.com Wed May 4 09:08:02 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 4 May 2016 11:08:02 +0200 Subject: Review request for JDK-8144711: (x) => x + 1 causes Assertion failure instead of SyntaxError In-Reply-To: References: <5729B784.4060609@oracle.com> Message-ID: <1119CFA0-A084-4C97-B841-AEECE6AF536B@oracle.com> Hi Hannes, hang on; one note: the test will "succeed" if the parser throws no exception. It should probably verify that there is an exception in the first place: caught = false try { ... } catch (e) { assert ... caught = true } Assert.assertTrue(caught) Best, Michael > Am 04.05.2016 um 11:05 schrieb Michael Haupt : > > Hi Hannes, > > lower-case thumbs up! > > Best, > > Michael > >> Am 04.05.2016 um 10:49 schrieb Hannes Wallnoefer >: >> >> Please review JDK-8144711: (x) => x + 1 causes Assertion failure instead of SyntaxError: >> >> http://cr.openjdk.java.net/~hannesw/8144711/ >> >> 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 Wed May 4 10:36:08 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 4 May 2016 12:36:08 +0200 Subject: Review request for JDK-8144711: (x) => x + 1 causes Assertion failure instead of SyntaxError In-Reply-To: <1119CFA0-A084-4C97-B841-AEECE6AF536B@oracle.com> References: <5729B784.4060609@oracle.com> <1119CFA0-A084-4C97-B841-AEECE6AF536B@oracle.com> Message-ID: <5729D098.1070906@oracle.com> Thanks Michael, I uploaded a new webrev that makes sure code does not pass. http://cr.openjdk.java.net/~hannesw/8144711/webrev.01/ Hannes Am 2016-05-04 um 11:08 schrieb Michael Haupt: > Hi Hannes, > > hang on; one note: the test will "succeed" if the parser throws no exception. It should probably verify that there is an exception in the first place: > > caught = false > try { > ... > } catch (e) { > assert ... > caught = true > } > Assert.assertTrue(caught) > > Best, > > Michael > >> Am 04.05.2016 um 11:05 schrieb Michael Haupt : >> >> Hi Hannes, >> >> lower-case thumbs up! >> >> Best, >> >> Michael >> >>> Am 04.05.2016 um 10:49 schrieb Hannes Wallnoefer >: >>> >>> Please review JDK-8144711: (x) => x + 1 causes Assertion failure instead of SyntaxError: >>> >>> http://cr.openjdk.java.net/~hannesw/8144711/ >>> >>> Thanks, >>> Hannes > From sundararajan.athijegannathan at oracle.com Wed May 4 10:47:55 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 4 May 2016 16:17:55 +0530 Subject: Review request for JDK-8144711: (x) => x + 1 causes Assertion failure instead of SyntaxError In-Reply-To: <5729D098.1070906@oracle.com> References: <5729B784.4060609@oracle.com> <1119CFA0-A084-4C97-B841-AEECE6AF536B@oracle.com> <5729D098.1070906@oracle.com> Message-ID: <309cd9f3-7854-9e07-27f6-167ea2c5e8b2@oracle.com> +1 On 5/4/2016 4:06 PM, Hannes Wallnoefer wrote: > Thanks Michael, > > I uploaded a new webrev that makes sure code does not pass. > > http://cr.openjdk.java.net/~hannesw/8144711/webrev.01/ > > Hannes > > > Am 2016-05-04 um 11:08 schrieb Michael Haupt: >> Hi Hannes, >> >> hang on; one note: the test will "succeed" if the parser throws no >> exception. It should probably verify that there is an exception in >> the first place: >> >> caught = false >> try { >> ... >> } catch (e) { >> assert ... >> caught = true >> } >> Assert.assertTrue(caught) >> >> Best, >> >> Michael >> >>> Am 04.05.2016 um 11:05 schrieb Michael Haupt >>> : >>> >>> Hi Hannes, >>> >>> lower-case thumbs up! >>> >>> Best, >>> >>> Michael >>> >>>> Am 04.05.2016 um 10:49 schrieb Hannes Wallnoefer >>>> >: >>>> >>>> Please review JDK-8144711: (x) => x + 1 causes Assertion failure >>>> instead of SyntaxError: >>>> >>>> http://cr.openjdk.java.net/~hannesw/8144711/ >>>> >>>> >>>> Thanks, >>>> Hannes >> > From sundararajan.athijegannathan at oracle.com Thu May 5 04:39:59 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 5 May 2016 10:09:59 +0530 Subject: RFR 8150731: Nashorn JSObject linker should be exposed as a service provider Message-ID: <325d3597-4566-8b0e-d7de-909ff59a0563@oracle.com> http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-March/006026.html Please review http://cr.openjdk.java.net/~sundar/8150731/webrev.02/ I've update the webrev to use provider clause in module-info.java instead of the older META-INF/services way of exposing a service. Also, I've split the test as suggested by Michael Haupt suggested earlier. Thanks, -Sundar From erandacr at gmail.com Thu May 5 06:43:04 2016 From: erandacr at gmail.com (eranda rajapaksha) Date: Thu, 5 May 2016 12:13:04 +0530 Subject: Using Nashorn as an external library Message-ID: Hi, I have a problem on the $subject, and I would be really grateful if anyone can help me out on this. I am using Nashorn engine with Java 8. But due to non-availability of Nashorn in earlier java versions, I have a difficulty in achieving the required level of performance with those. Is there an alternative for that, such as using the Nashorn as an external Jar library with my java application, so that it would be independent from the running Java version? Thanks, -- *Eranda Rajapakshe* Computer Science and Engineering Undergraduate, University of Moratuwa. Tel : +94784822608 Email : erandacr at gmail.com From james.laskey at oracle.com Thu May 5 11:39:57 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 5 May 2016 08:39:57 -0300 Subject: RFR 8150731: Nashorn JSObject linker should be exposed as a service provider In-Reply-To: <325d3597-4566-8b0e-d7de-909ff59a0563@oracle.com> References: <325d3597-4566-8b0e-d7de-909ff59a0563@oracle.com> Message-ID: +1 > On May 5, 2016, at 1:39 AM, Sundararajan Athijegannathan wrote: > > http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-March/006026.html > > Please review http://cr.openjdk.java.net/~sundar/8150731/webrev.02/ > > I've update the webrev to use provider clause in module-info.java > instead of the older META-INF/services way of exposing a service. > > Also, I've split the test as suggested by Michael Haupt suggested earlier. > > Thanks, > > -Sundar > From tomas at tzima.cz Thu May 5 16:32:57 2016 From: tomas at tzima.cz (=?UTF-8?B?VG9tw6HFoSBaw61tYQ==?=) Date: Thu, 5 May 2016 18:32:57 +0200 Subject: Using Nashorn as an external library In-Reply-To: References: Message-ID: <572B75B9.1030501@tzima.cz> Hi, take a look at https://bitbucket.org/ramonza/nashorn-backport. - tzima On 5.5.2016 08:43, eranda rajapaksha wrote: > Hi, > > I have a problem on the $subject, and I would be really grateful if anyone > can help me out on this. > > I am using Nashorn engine with Java 8. But due to non-availability of > Nashorn in earlier java versions, I have a difficulty in achieving the > required level of performance with those. Is there an alternative for that, > such as using the Nashorn as an external Jar library with my java > application, so that it would be independent from the running Java version? > > Thanks, > From sundararajan.athijegannathan at oracle.com Fri May 6 03:39:36 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 6 May 2016 09:09:36 +0530 Subject: Using Nashorn as an external library In-Reply-To: <572B75B9.1030501@tzima.cz> References: <572B75B9.1030501@tzima.cz> Message-ID: <2e6b82f8-9fb9-5595-f059-0614b75b11f6@oracle.com> While such a backport *may* work, nashorn developers are not conscious of jdk7 or below compatibility in nashorn source code. Besides as external library, you still need to provide all-permission to nashorn code [to run under security manager]. There may be assumptions about being loaded by extension loader. Summary: I'd recommend migrating to 8u to be safe. -Sundar On 5/5/2016 10:02 PM, Tom?? Z?ma wrote: > Hi, > > take a look at https://bitbucket.org/ramonza/nashorn-backport. > > - tzima > > On 5.5.2016 08:43, eranda rajapaksha wrote: >> Hi, >> >> I have a problem on the $subject, and I would be really grateful if >> anyone >> can help me out on this. >> >> I am using Nashorn engine with Java 8. But due to non-availability of >> Nashorn in earlier java versions, I have a difficulty in achieving the >> required level of performance with those. Is there an alternative for >> that, >> such as using the Nashorn as an external Jar library with my java >> application, so that it would be independent from the running Java >> version? >> >> Thanks, >> > > From erandacr at gmail.com Fri May 6 06:29:38 2016 From: erandacr at gmail.com (eranda rajapaksha) Date: Fri, 6 May 2016 11:59:38 +0530 Subject: Using Nashorn as an external library In-Reply-To: <2e6b82f8-9fb9-5595-f059-0614b75b11f6@oracle.com> References: <572B75B9.1030501@tzima.cz> <2e6b82f8-9fb9-5595-f059-0614b75b11f6@oracle.com> Message-ID: hi, Thanks for both. Yeah I saw the backport thing I had the same concern. And it seems like going for an external library is not as straightforward as I thought. The problem I am having is, I need to support Java6,7 and 8 with my application. It looks like using nashorn in 8u and rhino in older JDK versions is the only reliable option I have for now. Thanks, On Fri, May 6, 2016 at 9:09 AM, Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > While such a backport *may* work, nashorn developers are not conscious > of jdk7 or below compatibility in nashorn source code. Besides as > external library, you still need to provide all-permission to nashorn > code [to run under security manager]. There may be assumptions about > being loaded by extension loader. > > Summary: I'd recommend migrating to 8u to be safe. > > -Sundar > > On 5/5/2016 10:02 PM, Tom?? Z?ma wrote: > > Hi, > > > > take a look at https://bitbucket.org/ramonza/nashorn-backport. > > > > - tzima > > > > On 5.5.2016 08:43, eranda rajapaksha wrote: > >> Hi, > >> > >> I have a problem on the $subject, and I would be really grateful if > >> anyone > >> can help me out on this. > >> > >> I am using Nashorn engine with Java 8. But due to non-availability of > >> Nashorn in earlier java versions, I have a difficulty in achieving the > >> required level of performance with those. Is there an alternative for > >> that, > >> such as using the Nashorn as an external Jar library with my java > >> application, so that it would be independent from the running Java > >> version? > >> > >> Thanks, > >> > > > > > > -- *Eranda Rajapakshe* Computer Science and Engineering Undergraduate, University of Moratuwa. Tel : +94784822608 Email : erandacr at gmail.com From hannes.wallnoefer at oracle.com Fri May 6 12:52:13 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 6 May 2016 14:52:13 +0200 Subject: RFR 8150731: Nashorn JSObject linker should be exposed as a service provider In-Reply-To: <325d3597-4566-8b0e-d7de-909ff59a0563@oracle.com> References: <325d3597-4566-8b0e-d7de-909ff59a0563@oracle.com> Message-ID: <572C937D.9080005@oracle.com> +1 Minor issue: there's an unused import of java.util.ArrayList in Bootstrap.java Hannes Am 2016-05-05 um 06:39 schrieb Sundararajan Athijegannathan: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-March/006026.html > > Please review http://cr.openjdk.java.net/~sundar/8150731/webrev.02/ > > I've update the webrev to use provider clause in module-info.java > instead of the older META-INF/services way of exposing a service. > > Also, I've split the test as suggested by Michael Haupt suggested earlier. > > Thanks, > > -Sundar > From sundararajan.athijegannathan at oracle.com Fri May 6 15:10:17 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 6 May 2016 20:40:17 +0530 Subject: RFR 8150731: Nashorn JSObject linker should be exposed as a service provider In-Reply-To: <572C937D.9080005@oracle.com> References: <325d3597-4566-8b0e-d7de-909ff59a0563@oracle.com> <572C937D.9080005@oracle.com> Message-ID: Thanks. Removed that unused import and pushed the changes. -Sundar On 5/6/2016 6:22 PM, Hannes Wallnoefer wrote: > +1 > > Minor issue: there's an unused import of java.util.ArrayList in > Bootstrap.java > > Hannes > > Am 2016-05-05 um 06:39 schrieb Sundararajan Athijegannathan: >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-March/006026.html >> >> >> Please review http://cr.openjdk.java.net/~sundar/8150731/webrev.02/ >> >> I've update the webrev to use provider clause in module-info.java >> instead of the older META-INF/services way of exposing a service. >> >> Also, I've split the test as suggested by Michael Haupt suggested >> earlier. >> >> Thanks, >> >> -Sundar >> > From vivin.paliath at gmail.com Fri May 6 22:39:57 2016 From: vivin.paliath at gmail.com (Vivin Suresh Paliath) Date: Fri, 6 May 2016 15:39:57 -0700 Subject: Stacktraces from dynamically-constructed functions not as expected Message-ID: I have the following code: *var f = (function() {* * return function foo() {* * try {* * throw new Error();* * } catch(e) {* * print(e.stack);* * }* * }* *})();* When I call the function, I get the following stacktrace as expected (mostly; I was expecting *foo* instead of *f$foo*). *Error* * at f$foo (:1)* * at (:1)* However, if I dynamically construct the function as follows: *var f = new Function([], "return function foo() { try { throw new Error(); } catch(e) { print(e.stack); } }")()* I get: *Error* * at (:2)* * at (:1)* Is there a reason for this discrepancy? Isn't the second version effectively the same as the first? Also, why is it *f$foo* instead of *foo* in the first case? I am running jdk8u92. Thanks! -- Ruin untold; And thine own sadness, Sing in the grass, When eve has forgot, that no more hear common things that gleam and pass; But seek alone to lip, sad Rose of love and ruin untold; And thine own mother Can know it as I know More than another What makes your own sadness, Set in her eyes. map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". ":13:02:11:01:02:11:01:12:02";map{print chr unpack" i",pack"B32",$_}$j=~m/.{8}/g From sundararajan.athijegannathan at oracle.com Sat May 7 13:57:39 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Sat, 7 May 2016 19:27:39 +0530 Subject: RFR 8156489: jjs tab-completion crashes with stack overflow error Message-ID: Please review http://cr.openjdk.java.net/~sundar/8156489/ for https://bugs.openjdk.java.net/browse/JDK-8156489 Thanks, -Sundar From james.laskey at oracle.com Sat May 7 14:15:12 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Sat, 7 May 2016 11:15:12 -0300 Subject: RFR 8156489: jjs tab-completion crashes with stack overflow error In-Reply-To: References: Message-ID: <928E4182-C395-4363-A6D5-E6ACFC2622A1@oracle.com> +1 > On May 7, 2016, at 10:57 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8156489/ for > https://bugs.openjdk.java.net/browse/JDK-8156489 > > Thanks, > > -Sundar > From sundararajan.athijegannathan at oracle.com Sat May 7 16:54:03 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Sat, 7 May 2016 22:24:03 +0530 Subject: RFR 8156492: ClassFormatError thrown when arrow function is used Message-ID: <163d1bf3-fb75-87d0-6daf-6742011448f1@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8156492/ for https://bugs.openjdk.java.net/browse/JDK-8156492 Thanks, -Sundar From james.laskey at oracle.com Sun May 8 12:27:32 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Sun, 8 May 2016 09:27:32 -0300 Subject: RFR 8156492: ClassFormatError thrown when arrow function is used In-Reply-To: <163d1bf3-fb75-87d0-6daf-6742011448f1@oracle.com> References: <163d1bf3-fb75-87d0-6daf-6742011448f1@oracle.com> Message-ID: <335FC115-E39A-43E7-B853-E31A3D32FEC2@oracle.com> +1 > On May 7, 2016, at 1:54 PM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8156492/ for > https://bugs.openjdk.java.net/browse/JDK-8156492 > > Thanks, > > -Sundar > From marcus at lagergren.net Tue May 10 10:08:39 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Tue, 10 May 2016 12:08:39 +0200 Subject: RFR 8155944: ant build/test of nashorn is broken with the latest jdk9-dev build In-Reply-To: References: <1a305724-762a-f5b5-d665-742cb900e6a5@oracle.com> Message-ID: <161D6C27-8A14-4898-8A02-553985FA638F@lagergren.net> +1 > On 04 May 2016, at 09:58, Michael Haupt wrote: > > Hi Sundar, > > lower-case thumbs up! > > Best, > > Michael > >> Am 03.05.2016 um 17:24 schrieb Sundararajan Athijegannathan : >> >> Hi, >> >> Please review http://cr.openjdk.java.net/~sundar/8155944/webrev/ for >> https://bugs.openjdk.java.net/browse/JDK-8155944 >> >> 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 Tue May 10 10:10:06 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Tue, 10 May 2016 12:10:06 +0200 Subject: RFR 8156489: jjs tab-completion crashes with stack overflow error In-Reply-To: References: Message-ID: <5D04EEBB-F053-48A3-B327-C47F76306B1B@lagergren.net> +1 > On 07 May 2016, at 15:57, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8156489/ for > https://bugs.openjdk.java.net/browse/JDK-8156489 > > Thanks, > > -Sundar > From marcus at lagergren.net Tue May 10 10:10:29 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Tue, 10 May 2016 12:10:29 +0200 Subject: RFR 8156492: ClassFormatError thrown when arrow function is used In-Reply-To: <163d1bf3-fb75-87d0-6daf-6742011448f1@oracle.com> References: <163d1bf3-fb75-87d0-6daf-6742011448f1@oracle.com> Message-ID: <3928C435-7092-466A-BCF1-2585C9D663D5@lagergren.net> +1 > On 07 May 2016, at 18:54, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8156492/ for > https://bugs.openjdk.java.net/browse/JDK-8156492 > > Thanks, > > -Sundar > From james.laskey at oracle.com Tue May 10 13:48:37 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 10 May 2016 10:48:37 -0300 Subject: RFR: JDK-8149665 - $EXEC changes clean up Message-ID: http://cr.openjdk.java.net/~jlaskey/8149665/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8149665 From sundararajan.athijegannathan at oracle.com Tue May 10 14:56:57 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 10 May 2016 20:26:57 +0530 Subject: RFR 8156665: ES6 for..of should work on Java Iterables and Java arrays Message-ID: <2c0cc229-5e45-93d0-3b9f-d0f67dd1b70d@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8156665/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8156665 Thanks, -Sundar From szegedia at gmail.com Tue May 10 15:28:12 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 10 May 2016 17:28:12 +0200 Subject: RFR 8156665: ES6 for..of should work on Java Iterables and Java arrays In-Reply-To: <2c0cc229-5e45-93d0-3b9f-d0f67dd1b70d@oracle.com> References: <2c0cc229-5e45-93d0-3b9f-d0f67dd1b70d@oracle.com> Message-ID: +1 > On 10 May 2016, at 16:56, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8156665/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8156665 > > Thanks, > > -Sundar > From hannes.wallnoefer at oracle.com Tue May 10 16:58:05 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 10 May 2016 18:58:05 +0200 Subject: RFR 8156665: ES6 for..of should work on Java Iterables and Java arrays In-Reply-To: <2c0cc229-5e45-93d0-3b9f-d0f67dd1b70d@oracle.com> References: <2c0cc229-5e45-93d0-3b9f-d0f67dd1b70d@oracle.com> Message-ID: <5732131D.5050309@oracle.com> +1 This is nice because it treats Java arrays (and lists) as JavaScript arrays in for..of. Another nice addition would be to treat java.util.Map and java.util.Set like ES6 Map and Set, respectively. Hannes Am 2016-05-10 um 16:56 schrieb Sundararajan Athijegannathan: > Please review http://cr.openjdk.java.net/~sundar/8156665/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8156665 > > Thanks, > > -Sundar > From silas.baronda at gmail.com Tue May 10 17:00:23 2016 From: silas.baronda at gmail.com (Silas Baronda) Date: Tue, 10 May 2016 13:00:23 -0400 Subject: Eval error with comments Message-ID: I have a small test file that has issues evaling in Nashorn. https://gist.github.com/silasb/f05dc6acf3e7958da618387c45860906 Two different ways I can get it to eval: remove the /*******/ comments or add a comma after line 31. I'm running JDK 1.8.0_91 on Mac. ?Silas From sundararajan.athijegannathan at oracle.com Wed May 11 03:15:52 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 11 May 2016 08:45:52 +0530 Subject: Eval error with comments In-Reply-To: References: Message-ID: <88ff7ab2-b373-e1fc-e764-649394bd2fd7@oracle.com> Hi, Thanks for reporting this issue. I filed https://bugs.openjdk.java.net/browse/JDK-8156714 to track this. Simplified test case is as follows: v = function() { } /**/ function f() { } -Sundar On 5/10/2016 10:30 PM, Silas Baronda wrote: > I have a small test file that has issues evaling in Nashorn. > https://gist.github.com/silasb/f05dc6acf3e7958da618387c45860906 > > Two different ways I can get it to eval: remove the /*******/ comments or > add a comma after line 31. > > I'm running JDK 1.8.0_91 on Mac. > > ?Silas From szegedia at gmail.com Wed May 11 11:48:59 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 11 May 2016 13:48:59 +0200 Subject: Review request for JDK-8156738: Use StackWalker for DynamicLinker.getLinkedCallSiteLocation Message-ID: <87F08A33-A9D6-4DD4-84F5-489F9E927F97@gmail.com> Please review JDK-8156738 "Use StackWalker for DynamicLinker.getLinkedCallSiteLocation" at for Thanks, Attila. From hannes.wallnoefer at oracle.com Wed May 11 12:51:53 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 11 May 2016 14:51:53 +0200 Subject: Review request for JDK-8156738: Use StackWalker for DynamicLinker.getLinkedCallSiteLocation In-Reply-To: <87F08A33-A9D6-4DD4-84F5-489F9E927F97@gmail.com> References: <87F08A33-A9D6-4DD4-84F5-489F9E927F97@gmail.com> Message-ID: <57332AE9.6000904@oracle.com> +1 Thanks, Attila! Am 2016-05-11 um 13:48 schrieb Attila Szegedi: > Please review JDK-8156738 "Use StackWalker for DynamicLinker.getLinkedCallSiteLocation" at for > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Wed May 11 14:44:33 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 11 May 2016 20:14:33 +0530 Subject: Review request for JDK-8156738: Use StackWalker for DynamicLinker.getLinkedCallSiteLocation In-Reply-To: <87F08A33-A9D6-4DD4-84F5-489F9E927F97@gmail.com> References: <87F08A33-A9D6-4DD4-84F5-489F9E927F97@gmail.com> Message-ID: <13bcc50a-c6f9-375b-78bb-045755e8aa2c@oracle.com> +1 Nice! On 5/11/2016 5:18 PM, Attila Szegedi wrote: > Please review JDK-8156738 "Use StackWalker for DynamicLinker.getLinkedCallSiteLocation" at for > > Thanks, > Attila. From ericacm at gmail.com Wed May 11 19:26:18 2016 From: ericacm at gmail.com (Eric Pederson) Date: Wed, 11 May 2016 15:26:18 -0400 Subject: JDK9 features Message-ID: I've been noticing the Java 9 ES6 features tweeted by @sundararajan_a . Looks awesome! Will there be full ES6 support in Java 9? There are a couple of other things we would love to see in the updated Nashorn: 1. We've been using the same hack that you recommended to Tim Fox for loading functions without changing the global namespace - the Avatar/js CommonJS/require hack. It would be great if this was supported natively in Nashorn via a new loadXXX(). 2. It would be also be great to have the inverse of asJSONCompatible for a) JSObjects returned by Java code and b) objects from other scopes. Our name for ScriptObjectMirrors in Javascript code is "mutant objects": they look like regular JS objects but they are missing most of their DNA, and you don't realize until you get an exception or silent failure somewhere down the call chain where it's difficult to figure out why :) Anyway, the upcoming stuff looks great! Thanks, -- Eric From sundararajan.athijegannathan at oracle.com Thu May 12 04:36:37 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 12 May 2016 10:06:37 +0530 Subject: JDK9 features In-Reply-To: References: Message-ID: <0af361e3-0ad9-4671-33af-049682b52780@oracle.com> Hi, Thanks for your comments! Making comments on forthcoming JDK releases is hard :) Whatever I'm saying now, may not happen - the usual disclaimer applies. No, we expect that only a subset of ES6 features will be implemented for Java 9. 1. On loading definitions without changing global namespace: you meant current global namespace? loadWithNewGlobal creates a new global and loads definitions into that. Would that be useful for you? or anything else? Which hack you're referring to? Please file an enhancement with your requirements. 2. on JSON: Again, will you please provide a simple test case and/or file an enhancement with requirements? Thanks, -Sundar On 5/12/2016 12:56 AM, Eric Pederson wrote: > I've been noticing the Java 9 ES6 features tweeted by @sundararajan_a > . Looks awesome! Will there be full > ES6 support in Java 9? > > There are a couple of other things we would love to see in the updated > Nashorn: > > 1. We've been using the same hack that you recommended to Tim Fox for > loading functions without changing the global namespace - the Avatar/js > CommonJS/require hack. It would be great if this was supported natively in > Nashorn via a new loadXXX(). > > 2. It would be also be great to have the inverse of asJSONCompatible for a) > JSObjects returned by Java code and b) objects from other scopes. Our name > for ScriptObjectMirrors in Javascript code is "mutant objects": they look > like regular JS objects but they are missing most of their DNA, and you > don't realize until you get an exception or silent failure somewhere down > the call chain where it's difficult to figure out why :) > > Anyway, the upcoming stuff looks great! > > Thanks, > > -- Eric From sundararajan.athijegannathan at oracle.com Thu May 12 06:09:15 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 12 May 2016 11:39:15 +0530 Subject: RFR 8156820: Nashorn nightly test failure after fix for 8156738 Message-ID: <0e687bef-666e-0c4a-165f-bca4dbc60a64@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8156820/ for https://bugs.openjdk.java.net/browse/JDK-8156820 Thanks, -Sundar From michael.haupt at oracle.com Thu May 12 06:55:53 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 12 May 2016 08:55:53 +0200 Subject: RFR 8156820: Nashorn nightly test failure after fix for 8156738 In-Reply-To: <0e687bef-666e-0c4a-165f-bca4dbc60a64@oracle.com> References: <0e687bef-666e-0c4a-165f-bca4dbc60a64@oracle.com> Message-ID: Hi Sundar, lower-case thumbs up. Best, Michael > Am 12.05.2016 um 08:09 schrieb Sundararajan Athijegannathan : > > Please review http://cr.openjdk.java.net/~sundar/8156820/ for > https://bugs.openjdk.java.net/browse/JDK-8156820 > > Thanks, > > -Sundar > -- 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 May 12 07:30:31 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 12 May 2016 09:30:31 +0200 Subject: RFR 8156820: Nashorn nightly test failure after fix for 8156738 In-Reply-To: <0e687bef-666e-0c4a-165f-bca4dbc60a64@oracle.com> References: <0e687bef-666e-0c4a-165f-bca4dbc60a64@oracle.com> Message-ID: <57343117.1030002@oracle.com> +1 Am 2016-05-12 um 08:09 schrieb Sundararajan Athijegannathan: > Please review http://cr.openjdk.java.net/~sundar/8156820/ for > https://bugs.openjdk.java.net/browse/JDK-8156820 > > Thanks, > > -Sundar > From szegedia at gmail.com Thu May 12 07:52:42 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Thu, 12 May 2016 09:52:42 +0200 Subject: RFR 8156820: Nashorn nightly test failure after fix for 8156738 In-Reply-To: <0e687bef-666e-0c4a-165f-bca4dbc60a64@oracle.com> References: <0e687bef-666e-0c4a-165f-bca4dbc60a64@oracle.com> Message-ID: Thanks. The StackWalker API seems to still be in a bit of a flux? I wrote it against b116. > On 12 May 2016, at 08:09, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8156820/ for > https://bugs.openjdk.java.net/browse/JDK-8156820 > > Thanks, > > -Sundar > From sundararajan.athijegannathan at oracle.com Thu May 12 08:11:42 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 12 May 2016 13:41:42 +0530 Subject: RFR 8156820: Nashorn nightly test failure after fix for 8156738 In-Reply-To: References: <0e687bef-666e-0c4a-165f-bca4dbc60a64@oracle.com> Message-ID: No issues. Yes, StackWalker change is a recent one. -Sundar On 5/12/2016 1:22 PM, Attila Szegedi wrote: > Thanks. The StackWalker API seems to still be in a bit of a flux? I wrote it against b116. > >> On 12 May 2016, at 08:09, Sundararajan Athijegannathan wrote: >> >> Please review http://cr.openjdk.java.net/~sundar/8156820/ for >> https://bugs.openjdk.java.net/browse/JDK-8156820 >> >> Thanks, >> >> -Sundar >> From jan.lahoda at oracle.com Thu May 12 10:25:09 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 12 May 2016 12:25:09 +0200 Subject: RFR: 8133549: Generalize jshell's EditingHistory Message-ID: <57345A05.2060504@oracle.com> Hello, In jshell, there's a special history mode that is intended to aid with editing/re-entering multi-line snippets (EditingHistory). It works like this: when the user goes back through the history to the first line of a multi-line snippet, and enters/confirms that line, the history view is limited only to the given snippet. I.e. up and down arrows won't go through the whole history, but only the few lines of the given snippet. When the multi-line snippet is finished, the history is restored to the original full state. The proposal here is to generalize this history mode so that it can be used in jjs as well. For this, a new support class is added into jdk.internal.le, that implements this history. Also, ConsoleReader is extended to also accept actions as a Runnable instead of only ActionListener, so that the EditingHistory can add extra actions to jump by the whole snippets when going back in history. Bug: https://bugs.openjdk.java.net/browse/JDK-8133549 Webrev: jdk repository: http://cr.openjdk.java.net/~jlahoda/8133549/jdk/webrev.00/ langtools repository: http://cr.openjdk.java.net/~jlahoda/8133549/langtools/webrev.00/ nashorn repository: http://cr.openjdk.java.net/~jlahoda/8133549/nashorn/webrev.00/ Any comments are welcome! Thanks, Jan From sundararajan.athijegannathan at oracle.com Thu May 12 11:44:41 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 12 May 2016 17:14:41 +0530 Subject: RFR: 8133549: Generalize jshell's EditingHistory In-Reply-To: <57345A05.2060504@oracle.com> References: <57345A05.2060504@oracle.com> Message-ID: <5bc12b5b-f705-d840-832a-1511ef92fdcd@oracle.com> The nashorn and jdk repo changes look good to me. Thanks, -Sundar On 5/12/2016 3:55 PM, Jan Lahoda wrote: > Hello, > > In jshell, there's a special history mode that is intended to aid with > editing/re-entering multi-line snippets (EditingHistory). It works > like this: when the user goes back through the history to the first > line of a multi-line snippet, and enters/confirms that line, the > history view is limited only to the given snippet. I.e. up and down > arrows won't go through the whole history, but only the few lines of > the given snippet. When the multi-line snippet is finished, the > history is restored to the original full state. > > The proposal here is to generalize this history mode so that it can be > used in jjs as well. For this, a new support class is added into > jdk.internal.le, that implements this history. Also, ConsoleReader is > extended to also accept actions as a Runnable instead of only > ActionListener, so that the EditingHistory can add extra actions to > jump by the whole snippets when going back in history. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8133549 > > Webrev: > jdk repository: > http://cr.openjdk.java.net/~jlahoda/8133549/jdk/webrev.00/ > > langtools repository: > http://cr.openjdk.java.net/~jlahoda/8133549/langtools/webrev.00/ > > nashorn repository: > http://cr.openjdk.java.net/~jlahoda/8133549/nashorn/webrev.00/ > > Any comments are welcome! > > Thanks, > Jan From vivin.paliath at gmail.com Thu May 12 13:59:40 2016 From: vivin.paliath at gmail.com (Vivin Suresh Paliath) Date: Thu, 12 May 2016 06:59:40 -0700 Subject: Stacktraces from dynamically-constructed functions not as expected In-Reply-To: References: Message-ID: I tried this out on in chrome and I get the expected stack trace there. Is this a bug? On May 6, 2016 3:39 PM, "Vivin Suresh Paliath" wrote: > I have the following code: > > *var f = (function() {* > * return function foo() {* > * try {* > * throw new Error();* > * } catch(e) {* > * print(e.stack);* > * }* > * }* > *})();* > > > When I call the function, I get the following stacktrace as expected > (mostly; I was expecting *foo* instead of *f$foo*). > > *Error* > * at f$foo (:1)* > * at (:1)* > > > However, if I dynamically construct the function as follows: > > *var f = new Function([], "return function foo() { try { throw new > Error(); } catch(e) { print(e.stack); } }")()* > > > I get: > > > *Error* > * at (:2)* > * at (:1)* > > > Is there a reason for this discrepancy? Isn't the second version > effectively the same as the first? Also, why is it *f$foo* instead of > *foo* in the first case? > > I am running jdk8u92. > > Thanks! > > -- > Ruin untold; > And thine own sadness, > Sing in the grass, > When eve has forgot, that no more hear common things that gleam and pass; > But seek alone to lip, sad Rose of love and ruin untold; > And thine own mother > Can know it as I know > More than another > What makes your own sadness, > Set in her eyes. > > map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". > ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". > ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". > ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". > ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". > ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". > ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". > ":13:02:11:01:02:11:01:12:02";map{print chr unpack" > i",pack"B32",$_}$j=~m/.{8}/g > From emilian.bold at gmail.com Thu May 12 14:44:30 2016 From: emilian.bold at gmail.com (Emilian Bold) Date: Thu, 12 May 2016 17:44:30 +0300 Subject: Tree API Javadoc down? Message-ID: Hello, Google gives me this URL (which I used before) http://download.java.net/jdk9/docs/jdk/api/nashorn/jdk/nashorn/api/tree/IfTree.html but it seems to be down (404). Has the Javadoc moved to some other place? Google Cache URL: http://webcache.googleusercontent.com/search?q=cache:ud0OiFY0S6wJ:download.java.net/jdk9/docs/jdk/api/nashorn/jdk/nashorn/api/tree/IfTree.html+&cd=1&hl=en&ct=clnk&gl=ro --emi From claes.redestad at oracle.com Thu May 12 14:45:55 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 12 May 2016 16:45:55 +0200 Subject: Tree API Javadoc down? In-Reply-To: References: Message-ID: <57349723.7070801@oracle.com> Hi, I saw elsewhere that docs have moved into /java (sigh): http://download.java.net/java/jdk9/docs/jdk/api/nashorn/jdk/nashorn/api/tree/IfTree.html /Claes On 2016-05-12 16:44, Emilian Bold wrote: > Hello, > > Google gives me this URL (which I used before) > http://download.java.net/jdk9/docs/jdk/api/nashorn/jdk/nashorn/api/tree/IfTree.html > but > it seems to be down (404). > > Has the Javadoc moved to some other place? > > Google Cache URL: > http://webcache.googleusercontent.com/search?q=cache:ud0OiFY0S6wJ:download.java.net/jdk9/docs/jdk/api/nashorn/jdk/nashorn/api/tree/IfTree.html+&cd=1&hl=en&ct=clnk&gl=ro > > --emi From emilian.bold at gmail.com Thu May 12 15:40:40 2016 From: emilian.bold at gmail.com (Emilian Bold) Date: Thu, 12 May 2016 18:40:40 +0300 Subject: Tree API: offsets for String fields Message-ID: Hello, It's really important for a Javascript editor to know the offsets of each syntax tree node and of whatever the node contains (I'm not really saying tokens but... constituent parts and keywords are the minimum). So it would be great to provide or document how offsets are to be computed for the String fields from the Nashorn Tree API. (Ideally the API could also be changed to use an IdentifierTree or some other Tree subclass which provides the start/endPosition.) A few examples: * MemberSelectTree has a String getIdentifier. Since I *assume* that the MemberSelectTree.getEndPosition is right after the identifier, I have to subtract the identifier length to get the identifier start offset. * VariableTree has a String getName(). It seems to me that VariableTree.getStartPosition is the 'name' startPosition. This also means you cannot really know where 'var' actually is -- it could be on another line altogether; it's also odd to me that 'var' is outside the [start, end] range for the VariableTree. * ContinueTree and BreakTree both have a String getLabel * LabeledStatementTree has a String getLabel * FunctionExpressionTree and FunctionDeclarationTree both have a String getName but I'm not sure how the offset for that is computed. Also not sure how the offset of the 'function' keyword would be computed. Could somebody explain this to me? I'll make a nice list for future reference. --emi From sundararajan.athijegannathan at oracle.com Thu May 12 16:19:08 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 12 May 2016 21:49:08 +0530 Subject: Tree API: offsets for String fields In-Reply-To: References: Message-ID: Hi, Thanks for your comments. Nashorn Parser API was modeled after similar API provided by javac - for consistency sake and to leverage developer familiarity. For example, ContinueTree, MemberSelectTree of javac Tree API: https://docs.oracle.com/javase/8/docs/jdk/api/javac/tree/com/sun/source/tree/ContinueTree.html https://docs.oracle.com/javase/8/docs/jdk/api/javac/tree/com/sun/source/tree/MemberSelectTree.html I agree that consistency should not result in API 'mistakes/gaps' being propagated here. BTW, labels are maintained as strings even internally. Member select property, Variable name , Function name etc. are all identifiers and so it is possible to make API return IdentifierTree objects. Will you please collect whatever you found and file a bug/enhancement for Nashorn parser API? Thanks, -Sundar On 5/12/2016 9:10 PM, Emilian Bold wrote: > Hello, > > It's really important for a Javascript editor to know the offsets of each > syntax tree node and of whatever the node contains (I'm not really saying > tokens but... constituent parts and keywords are the minimum). > > So it would be great to provide or document how offsets are to be computed > for the String fields from the Nashorn Tree API. > > (Ideally the API could also be changed to use an IdentifierTree or some > other Tree subclass which provides the start/endPosition.) > > A few examples: > > * MemberSelectTree has a String getIdentifier. Since I *assume* that the > MemberSelectTree.getEndPosition is right after the identifier, I have to > subtract the identifier length to get the identifier start offset. > > * VariableTree has a String getName(). It seems to me that > VariableTree.getStartPosition is the 'name' startPosition. This also means > you cannot really know where 'var' actually is -- it could be on another > line altogether; it's also odd to me that 'var' is outside the [start, end] > range for the VariableTree. > > * ContinueTree and BreakTree both have a String getLabel > > * LabeledStatementTree has a String getLabel > > * FunctionExpressionTree and FunctionDeclarationTree both have a String > getName but I'm not sure how the offset for that is computed. Also not sure > how the offset of the 'function' keyword would be computed. > > Could somebody explain this to me? I'll make a nice list for future > reference. > > --emi From emilian.bold at gmail.com Thu May 12 16:50:45 2016 From: emilian.bold at gmail.com (Emilian Bold) Date: Thu, 12 May 2016 19:50:45 +0300 Subject: Tree API: offsets for String fields In-Reply-To: References: Message-ID: Assuming I don't need some special permissions to do that (do I?) I could expand the previous email and post it as an enhancement on https://bugs.openjdk.java.net But I'm also trying to understand the logic behind what you have. The way I see it any AST node has some underlying tokens so its offsets should be based on that. Take VariableTree. The Javadoc mentions: var name initializer ; but I assume the offset ranges are something like var [name = [initializer]] ; So, 'var' and whatever whitespace there is in between is ignored. The 'name' offsets are not explicit but may be inferred. (A similar problem with FunctionDeclarationTree.) What I would do with Variable Tree would be to have the offset ranges like: [var [name] = [initializer]] with the VariableTree covering everything ('var' too) and 'name' having a separate IdentifierTree. Continue/BreakTree/LabeledStatementTree are not really that important/used so if there is no internal info it's no big loss. --emi On Thu, May 12, 2016 at 7:19 PM, Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > Hi, > > Thanks for your comments. Nashorn Parser API was modeled after similar > API provided by javac - for consistency sake and to leverage developer > familiarity. For example, ContinueTree, MemberSelectTree of javac Tree > API: > > > https://docs.oracle.com/javase/8/docs/jdk/api/javac/tree/com/sun/source/tree/ContinueTree.html > > > https://docs.oracle.com/javase/8/docs/jdk/api/javac/tree/com/sun/source/tree/MemberSelectTree.html > > I agree that consistency should not result in API 'mistakes/gaps' being > propagated here. BTW, labels are maintained as strings even > internally. Member select property, Variable name , Function name etc. > are all identifiers and so it is possible to make API return > IdentifierTree objects. Will you please collect whatever you found and > file a bug/enhancement for Nashorn parser API? > > Thanks, > > -Sundar > > > On 5/12/2016 9:10 PM, Emilian Bold wrote: > > Hello, > > > > It's really important for a Javascript editor to know the offsets of each > > syntax tree node and of whatever the node contains (I'm not really saying > > tokens but... constituent parts and keywords are the minimum). > > > > So it would be great to provide or document how offsets are to be > computed > > for the String fields from the Nashorn Tree API. > > > > (Ideally the API could also be changed to use an IdentifierTree or some > > other Tree subclass which provides the start/endPosition.) > > > > A few examples: > > > > * MemberSelectTree has a String getIdentifier. Since I *assume* that the > > MemberSelectTree.getEndPosition is right after the identifier, I have to > > subtract the identifier length to get the identifier start offset. > > > > * VariableTree has a String getName(). It seems to me that > > VariableTree.getStartPosition is the 'name' startPosition. This also > means > > you cannot really know where 'var' actually is -- it could be on another > > line altogether; it's also odd to me that 'var' is outside the [start, > end] > > range for the VariableTree. > > > > * ContinueTree and BreakTree both have a String getLabel > > > > * LabeledStatementTree has a String getLabel > > > > * FunctionExpressionTree and FunctionDeclarationTree both have a String > > getName but I'm not sure how the offset for that is computed. Also not > sure > > how the offset of the 'function' keyword would be computed. > > > > Could somebody explain this to me? I'll make a nice list for future > > reference. > > > > --emi > > From sundararajan.athijegannathan at oracle.com Thu May 12 17:10:21 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 12 May 2016 22:40:21 +0530 Subject: Tree API: offsets for String fields In-Reply-To: References: Message-ID: <4d92acf8-d3b3-2280-c0d6-063e6b453d45@oracle.com> Filed: https://bugs.openjdk.java.net/browse/JDK-8156866 PS. Actually, I was wrong about MemberSelectTree - even internally nashorn IR node "AccessNode" maintains 'property' as a String. But, variables, functions have identifier nodes for names. Thanks, -Sundar On 5/12/2016 10:20 PM, Emilian Bold wrote: > Assuming I don't need some special permissions to do that (do I?) I > could expand the previous email and post it as an enhancement > on https://bugs.openjdk.java.net > > But I'm also trying to understand the logic behind what you have. > > The way I see it any AST node has some underlying tokens so its > offsets should be based on that. > > Take VariableTree. The Javadoc mentions: > > var name initializer ; > > but I assume the offset ranges are something like > > var [name = [initializer]] ; > > So, 'var' and whatever whitespace there is in between is ignored. The > 'name' offsets are not explicit but may be inferred. > > (A similar problem with FunctionDeclarationTree.) > > What I would do with Variable Tree would be to have the offset ranges > like: > > [var [name] = [initializer]] > > with the VariableTree covering everything ('var' too) and 'name' > having a separate IdentifierTree. > > Continue/BreakTree/LabeledStatementTree are not really that > important/used so if there is no internal info it's no big loss. > > --emi > > > On Thu, May 12, 2016 at 7:19 PM, Sundararajan Athijegannathan > > wrote: > > Hi, > > Thanks for your comments. Nashorn Parser API was modeled after similar > API provided by javac - for consistency sake and to leverage developer > familiarity. For example, ContinueTree, MemberSelectTree of javac > Tree API: > > https://docs.oracle.com/javase/8/docs/jdk/api/javac/tree/com/sun/source/tree/ContinueTree.html > > https://docs.oracle.com/javase/8/docs/jdk/api/javac/tree/com/sun/source/tree/MemberSelectTree.html > > I agree that consistency should not result in API 'mistakes/gaps' > being > propagated here. BTW, labels are maintained as strings even > internally. Member select property, Variable name , Function name > etc. > are all identifiers and so it is possible to make API return > IdentifierTree objects. Will you please collect whatever you found and > file a bug/enhancement for Nashorn parser API? > > Thanks, > > -Sundar > > > On 5/12/2016 9:10 PM, Emilian Bold wrote: > > Hello, > > > > It's really important for a Javascript editor to know the > offsets of each > > syntax tree node and of whatever the node contains (I'm not > really saying > > tokens but... constituent parts and keywords are the minimum). > > > > So it would be great to provide or document how offsets are to > be computed > > for the String fields from the Nashorn Tree API. > > > > (Ideally the API could also be changed to use an IdentifierTree > or some > > other Tree subclass which provides the start/endPosition.) > > > > A few examples: > > > > * MemberSelectTree has a String getIdentifier. Since I *assume* > that the > > MemberSelectTree.getEndPosition is right after the identifier, I > have to > > subtract the identifier length to get the identifier start offset. > > > > * VariableTree has a String getName(). It seems to me that > > VariableTree.getStartPosition is the 'name' startPosition. This > also means > > you cannot really know where 'var' actually is -- it could be on > another > > line altogether; it's also odd to me that 'var' is outside the > [start, end] > > range for the VariableTree. > > > > * ContinueTree and BreakTree both have a String getLabel > > > > * LabeledStatementTree has a String getLabel > > > > * FunctionExpressionTree and FunctionDeclarationTree both have a > String > > getName but I'm not sure how the offset for that is computed. > Also not sure > > how the offset of the 'function' keyword would be computed. > > > > Could somebody explain this to me? I'll make a nice list for future > > reference. > > > > --emi > > From vivin.paliath at gmail.com Thu May 12 17:18:35 2016 From: vivin.paliath at gmail.com (Vivin Suresh Paliath) Date: Thu, 12 May 2016 10:18:35 -0700 Subject: Stacktraces from dynamically-constructed functions Message-ID: Sorry to be sending this again, but I think there were some issues with my subscription to nashorn-dev. I have unsubscribed and so hopefully this should show up. I have the following code: *var f = (function() {* * return function foo() {* * try {* * throw new Error();* * } catch(e) {* * print(e.stack);* * }* * }* *})();* When I call the function, I get the following stacktrace as expected (mostly; I was expecting *foo* instead of *f$foo*). *Error* * at f$foo (:1)* * at (:1)* However, if I dynamically construct the function as follows: *var f = new Function([], "return function foo() { try { throw new Error(); } catch(e) { print(e.stack); } }")()* I get: *Error* * at (:2)* * at (:1)* Is there a reason for this discrepancy? Isn't the second version effectively the same as the first? Also, why is it *f$foo* instead of *foo* in the first case? I am running jdk8u92. Thanks! -- Ruin untold; And thine own sadness, Sing in the grass, When eve has forgot, that no more hear common things that gleam and pass; But seek alone to lip, sad Rose of love and ruin untold; And thine own mother Can know it as I know More than another What makes your own sadness, Set in her eyes. map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". ":13:02:11:01:02:11:01:12:02";map{print chr unpack" i",pack"B32",$_}$j=~m/.{8}/g From ericacm at gmail.com Thu May 12 17:40:53 2016 From: ericacm at gmail.com (Eric Pederson) Date: Thu, 12 May 2016 13:40:53 -0400 Subject: JDK9 features In-Reply-To: <0af361e3-0ad9-4671-33af-049682b52780@oracle.com> References: <0af361e3-0ad9-4671-33af-049682b52780@oracle.com> Message-ID: Hi Sundar: 1. I investigated loadWithNewGlobal because it looked promising for this use case. Say you use loadWithNewGlobal to load a function. If you call the loaded function and it returns an object or array the caller gets a ScriptObjectMirror. The problems with a ScriptObjectMirror "object" are: - Cannot call Object methods like keys or getOwnPropertyNames. You get an exception: TypeError: cannot call undefined. To iterate over the properties you must use a for in loop. - Cannot convert ScriptObjectMirror to JSON using JSON.stringify. It returns undefined. If the function loaded with loadWithNewGlobal returns an array then things are better. Interestingly you can call most Array methods (like forEach and map) on a ScriptObjectMirror "array". But JSON.stringify also returns undefined. I did find one issue with an array returned by a loadWithNewGlobal loaded function - calling sort with a comparator. For example, if the loaded function returned testArray, a ScriptObjectMirror "array": *var **sorted *= *testArray*.sort(*function*(a, b) { *return *a - b; }); throws an exception*: *TypeError: function(a, b) { return a - b; } is not a function. These were the same "mutant" issues that we also saw with JSObjects returned by Java methods. The hack that we are using now to load code without effecting the global namespace is the same one discussed in this thread: http://thread.gmane.org/gmane.comp.java.openjdk.nashorn.devel/1722. The code that we are using is copied/adapted from Vertx (thanks, Tim!): function loadEval(path) { *var *dir = *new **File*(path).getParent(); *var *body = *readFile*(path); *var *moduleFunc = *"function(exports, module, require, __filename, __dirname){" *+ body + *"**\n**}**\n**//# sourceURL=" *+ path; *try {* *var *func = eval(moduleFunc); } *catch *(ex) { *if *(ex *instanceof **SyntaxError*) { *// WARNING! Large pile of Yak hair ahead!* *var *ne = ex.nashornException; *var *cause = ne.cause; *var *msg = cause.message.replace(*""*, file); *var *lineNumber = cause.*lineNumber;* console.log(*"ERROR: " *+ msg + *" in file " *+ file + *" at line " *+ lineNumber); } *throw *ex; } *var *module = { *exports*: {} }; func(module.*exports*, module, require, path, dir); *return *module.*exports*; } This seems like a hack to me - but I'm coming from the Java world so this may be par for the course in Javascript-land :) Hack or no, it is the best of both worlds: it does not change the global namespace, yet the code that it returns lives in the global context, so if you call a loaded function it will return a native object, not a ScriptObjectMirror. We'd like to have a built-in equivalent of this loadEval function. It doesn't need to use those specific arguments (export, module, etc), but you must be able to pass arguments in to provide a context to the loaded code. Alternatively if you could make ScriptObjectMirrors 100% compatible with native objects that would work too. Then we could use loadWithNewGlobal. 2. The problem that we are having with objects returned by Java methods is the same as what I described above because the returned JSObjects are seen as ScriptObjectMirrors by the calling Javascript code. What we are doing now is wrapping each Java object with a Javascript proxy. When you call the proxy it calls the corresponding Java method, then converts the returned ScriptObjectMirror into a native JS object using a custom conversion function. What would be nice for this use case is a standard function to convert ScriptObjectMirrors to native JS objects (what I was calling asJSONCompatible below). Or if ScriptObjectMirrors were 100% compatible that would be even better - we could get rid of our JS proxy objects. I'm happy to file some enhancement requests. Though it seems like the bug trackers are read-only to the general public though, how would I get access? Thanks, -- Eric On Thu, May 12, 2016 at 12:36 AM, Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > Hi, > > Thanks for your comments! > > Making comments on forthcoming JDK releases is hard :) Whatever I'm > saying now, may not happen - the usual disclaimer applies. > > No, we expect that only a subset of ES6 features will be implemented for > Java 9. > > 1. On loading definitions without changing global namespace: you meant > current global namespace? loadWithNewGlobal creates a new global and > loads definitions into that. > > Would that be useful for you? or anything else? Which hack you're > referring to? Please file an enhancement with your requirements. > > 2. on JSON: Again, will you please provide a simple test case and/or > file an enhancement with requirements? > > Thanks, > -Sundar > > On 5/12/2016 12:56 AM, Eric Pederson wrote: > > I've been noticing the Java 9 ES6 features tweeted by @sundararajan_a > > . Looks awesome! Will there be > full > > ES6 support in Java 9? > > > > There are a couple of other things we would love to see in the updated > > Nashorn: > > > > 1. We've been using the same hack that you recommended to Tim Fox for > > loading functions without changing the global namespace - the Avatar/js > > CommonJS/require hack. It would be great if this was supported natively > in > > Nashorn via a new loadXXX(). > > > > 2. It would be also be great to have the inverse of asJSONCompatible for > a) > > JSObjects returned by Java code and b) objects from other scopes. Our > name > > for ScriptObjectMirrors in Javascript code is "mutant objects": they look > > like regular JS objects but they are missing most of their DNA, and you > > don't realize until you get an exception or silent failure somewhere down > > the call chain where it's difficult to figure out why :) > > > > Anyway, the upcoming stuff looks great! > > > > Thanks, > > > > -- Eric > > From vivin.paliath at gmail.com Thu May 12 20:49:58 2016 From: vivin.paliath at gmail.com (Vivin Suresh Paliath) Date: Thu, 12 May 2016 13:49:58 -0700 Subject: Stacktraces from dynamically-constructed functions Message-ID: I have the following code: *var f = (function() {* * return function foo() {* * try {* * throw new Error();* * } catch(e) {* * print(e.stack);* * }* * }* *})();* When I call the function, I get the following stacktrace as expected (mostly; I was expecting *foo* instead of *f$foo*). *Error* * at f$foo (:1)* * at (:1)* However, if I dynamically construct the function as follows: *var f = new Function([], "return function foo() { try { throw new Error(); } catch(e) { print(e.stack); } }")()* I get: *Error* * at (:2)* * at (:1)* In this particular situation, isn't the second version effectively the same as the first? Also, shouldn't it just be *foo* instead of *f$foo*? I am running jdk8u92. Thanks! -- *[vivin.net :: github :: linkedin ]* From hannes.wallnoefer at oracle.com Thu May 12 21:12:15 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 12 May 2016 23:12:15 +0200 Subject: Stacktraces from dynamically-constructed functions not as expected In-Reply-To: References: Message-ID: <5734F1AF.9030600@oracle.com> Hi Vivin, What you see is some fuzziness in the translation from JS functions to Java methods and from there to the stack traces you see. When we compile a JS function, we create a Java method with the name of the function concatenated to the names of its parent functions, using '$' as separator. For anonymous functions we use something like L:123 as name where 123 is the line of code where the function begins. This method naming scheme helps a lot in making bytecode easier to debug, and to create unique method names within a compilation unit. However, it also leads to the stack traces you see, getting f$foo in the first case and something like L1:foo in the second case, which is rendered as in the stack trace. Ideally we should reverse this when printing stack traces, displaying only the name of the function itself, e.g. "bar" for "foo$bar" and "" for "foo$L:3". Unfortunately, "$" is a valid character in a JS identifier, so it's not that easy, "foo$bar" may also be the name of the original function. I'm thinking about how to solve this and will probably file an issue for it. Hannes Am 2016-05-12 um 15:59 schrieb Vivin Suresh Paliath: > I tried this out on in chrome and I get the expected stack trace there. Is > this a bug? > On May 6, 2016 3:39 PM, "Vivin Suresh Paliath" > wrote: > >> I have the following code: >> >> *var f = (function() {* >> * return function foo() {* >> * try {* >> * throw new Error();* >> * } catch(e) {* >> * print(e.stack);* >> * }* >> * }* >> *})();* >> >> >> When I call the function, I get the following stacktrace as expected >> (mostly; I was expecting *foo* instead of *f$foo*). >> >> *Error* >> * at f$foo (:1)* >> * at (:1)* >> >> >> However, if I dynamically construct the function as follows: >> >> *var f = new Function([], "return function foo() { try { throw new >> Error(); } catch(e) { print(e.stack); } }")()* >> >> >> I get: >> >> >> *Error* >> * at (:2)* >> * at (:1)* >> >> >> Is there a reason for this discrepancy? Isn't the second version >> effectively the same as the first? Also, why is it *f$foo* instead of >> *foo* in the first case? >> >> I am running jdk8u92. >> >> Thanks! >> >> -- >> Ruin untold; >> And thine own sadness, >> Sing in the grass, >> When eve has forgot, that no more hear common things that gleam and pass; >> But seek alone to lip, sad Rose of love and ruin untold; >> And thine own mother >> Can know it as I know >> More than another >> What makes your own sadness, >> Set in her eyes. >> >> map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". >> ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". >> ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". >> ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". >> ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". >> ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". >> ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". >> ":13:02:11:01:02:11:01:12:02";map{print chr unpack" >> i",pack"B32",$_}$j=~m/.{8}/g >> From vivin.paliath at gmail.com Thu May 12 21:42:22 2016 From: vivin.paliath at gmail.com (Vivin Suresh Paliath) Date: Thu, 12 May 2016 14:42:22 -0700 Subject: Stacktraces from dynamically-constructed functions not as expected In-Reply-To: <5734F1AF.9030600@oracle.com> References: <5734F1AF.9030600@oracle.com> Message-ID: Thanks for the explanation Hannes! The issue with $ makes sense; I ran into that some time ago - I can't remember the exact situation, but it was exactly as you described: the $ introduces ambiguity because it is a valid character and so could be part of the name of the original function, and not a separator. Would you be able to point me to the location in the nashorn source where this mapping/translation is done? It would help me learn more about the internals of nashorn. On Thu, May 12, 2016 at 2:12 PM, Hannes Wallnoefer < hannes.wallnoefer at oracle.com> wrote: > Hi Vivin, > > What you see is some fuzziness in the translation from JS functions to > Java methods and from there to the stack traces you see. > > When we compile a JS function, we create a Java method with the name of > the function concatenated to the names of its parent functions, using '$' > as separator. For anonymous functions we use something like L:123 as name > where 123 is the line of code where the function begins. > > This method naming scheme helps a lot in making bytecode easier to debug, > and to create unique method names within a compilation unit. However, it > also leads to the stack traces you see, getting f$foo in the first case and > something like L1:foo in the second case, which is rendered as > in the stack trace. > > Ideally we should reverse this when printing stack traces, displaying only > the name of the function itself, e.g. "bar" for "foo$bar" and "" > for "foo$L:3". Unfortunately, "$" is a valid character in a JS identifier, > so it's not that easy, "foo$bar" may also be the name of the original > function. > > I'm thinking about how to solve this and will probably file an issue for > it. > > Hannes > > Am 2016-05-12 um 15:59 schrieb Vivin Suresh Paliath: > >> I tried this out on in chrome and I get the expected stack trace there. Is >> this a bug? >> On May 6, 2016 3:39 PM, "Vivin Suresh Paliath" >> wrote: >> >> I have the following code: >>> >>> *var f = (function() {* >>> * return function foo() {* >>> * try {* >>> * throw new Error();* >>> * } catch(e) {* >>> * print(e.stack);* >>> * }* >>> * }* >>> *})();* >>> >>> >>> When I call the function, I get the following stacktrace as expected >>> (mostly; I was expecting *foo* instead of *f$foo*). >>> >>> *Error* >>> * at f$foo (:1)* >>> * at (:1)* >>> >>> >>> However, if I dynamically construct the function as follows: >>> >>> *var f = new Function([], "return function foo() { try { throw new >>> Error(); } catch(e) { print(e.stack); } }")()* >>> >>> >>> I get: >>> >>> >>> *Error* >>> * at (:2)* >>> * at (:1)* >>> >>> >>> Is there a reason for this discrepancy? Isn't the second version >>> effectively the same as the first? Also, why is it *f$foo* instead of >>> *foo* in the first case? >>> >>> I am running jdk8u92. >>> >>> Thanks! >>> >>> -- >>> Ruin untold; >>> And thine own sadness, >>> Sing in the grass, >>> When eve has forgot, that no more hear common things that gleam and pass; >>> But seek alone to lip, sad Rose of love and ruin untold; >>> And thine own mother >>> Can know it as I know >>> More than another >>> What makes your own sadness, >>> Set in her eyes. >>> >>> map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". >>> ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". >>> ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". >>> ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". >>> ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". >>> ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". >>> ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". >>> ":13:02:11:01:02:11:01:12:02";map{print chr unpack" >>> i",pack"B32",$_}$j=~m/.{8}/g >>> >>> > -- *[vivin.net :: github :: linkedin ]* From hannes.wallnoefer at oracle.com Thu May 12 22:08:37 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 13 May 2016 00:08:37 +0200 Subject: Stacktraces from dynamically-constructed functions not as expected In-Reply-To: References: <5734F1AF.9030600@oracle.com> Message-ID: <5734FEE5.6020705@oracle.com> Am 2016-05-12 um 23:42 schrieb Vivin Suresh Paliath: > Thanks for the explanation Hannes! The issue with $ makes sense; I ran > into that some time ago - I can't remember the exact situation, but it > was exactly as you described: the $ introduces ambiguity because it is > a valid character and so could be part of the name of the original > function, and not a separator. Would you be able to point me to the > location in the nashorn source where this mapping/translation is done? > It would help me learn more about the internals of nashorn. The method name is created in Parser#createParserContextFunctionNode: http://hg.openjdk.java.net/jdk9/dev/nashorn/file/4b118e012ac4/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java#l532 The method name for the stack trace is computed in NashornException#getScriptFrames: http://hg.openjdk.java.net/jdk9/dev/nashorn/file/4b118e012ac4/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/NashornException.java#l174 I've filed a bug for this: https://bugs.openjdk.java.net/browse/JDK-8156896 Hannes > > On Thu, May 12, 2016 at 2:12 PM, Hannes Wallnoefer > > > wrote: > > Hi Vivin, > > What you see is some fuzziness in the translation from JS > functions to Java methods and from there to the stack traces you see. > > When we compile a JS function, we create a Java method with the > name of the function concatenated to the names of its parent > functions, using '$' as separator. For anonymous functions we use > something like L:123 as name where 123 is the line of code where > the function begins. > > This method naming scheme helps a lot in making bytecode easier to > debug, and to create unique method names within a compilation > unit. However, it also leads to the stack traces you see, getting > f$foo in the first case and something like L1:foo in the second > case, which is rendered as in the stack trace. > > Ideally we should reverse this when printing stack traces, > displaying only the name of the function itself, e.g. "bar" for > "foo$bar" and "" for "foo$L:3". Unfortunately, "$" is a > valid character in a JS identifier, so it's not that easy, > "foo$bar" may also be the name of the original function. > > I'm thinking about how to solve this and will probably file an > issue for it. > > Hannes > > Am 2016-05-12 um 15:59 schrieb Vivin Suresh Paliath: > > I tried this out on in chrome and I get the expected stack > trace there. Is > this a bug? > On May 6, 2016 3:39 PM, "Vivin Suresh Paliath" > > > wrote: > > I have the following code: > > *var f = (function() {* > * return function foo() {* > * try {* > * throw new Error();* > * } catch(e) {* > * print(e.stack);* > * }* > * }* > *})();* > > > When I call the function, I get the following stacktrace > as expected > (mostly; I was expecting *foo* instead of *f$foo*). > > *Error* > * at f$foo (:1)* > * at (:1)* > > > However, if I dynamically construct the function as follows: > > *var f = new Function([], "return function foo() { try { > throw new > Error(); } catch(e) { print(e.stack); } }")()* > > > I get: > > > *Error* > * at (:2)* > * at (:1)* > > > Is there a reason for this discrepancy? Isn't the second > version > effectively the same as the first? Also, why is it *f$foo* > instead of > *foo* in the first case? > > I am running jdk8u92. > > Thanks! > > -- > Ruin untold; > And thine own sadness, > Sing in the grass, > When eve has forgot, that no more hear common things that > gleam and pass; > But seek alone to lip, sad Rose of love and ruin untold; > And thine own mother > Can know it as I know > More than another > What makes your own sadness, > Set in her eyes. > > map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". > ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". > ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". > ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". > ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". > ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". > ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". > ":13:02:11:01:02:11:01:12:02";map{print chr unpack" > i",pack"B32",$_}$j=~m/.{8}/g > > > > > > -- > *[vivin.net :: github :: > linkedin ]* From vivin.paliath at gmail.com Thu May 12 22:59:31 2016 From: vivin.paliath at gmail.com (Vivin Suresh Paliath) Date: Thu, 12 May 2016 15:59:31 -0700 Subject: Stacktraces from dynamically-constructed functions not as expected In-Reply-To: <5734FEE5.6020705@oracle.com> References: <5734F1AF.9030600@oracle.com> <5734FEE5.6020705@oracle.com> Message-ID: Thanks Hannes. I looked at the issue and it answered another question I had as well; I was wondering about the possibility of using a separator other than $ that is legal in Java, but not in JavaScript. On Thu, May 12, 2016 at 3:08 PM, Hannes Wallnoefer < hannes.wallnoefer at oracle.com> wrote: > Am 2016-05-12 um 23:42 schrieb Vivin Suresh Paliath: > >> Thanks for the explanation Hannes! The issue with $ makes sense; I ran >> into that some time ago - I can't remember the exact situation, but it was >> exactly as you described: the $ introduces ambiguity because it is a valid >> character and so could be part of the name of the original function, and >> not a separator. Would you be able to point me to the location in the >> nashorn source where this mapping/translation is done? It would help me >> learn more about the internals of nashorn. >> > > The method name is created in Parser#createParserContextFunctionNode: > > http://hg.openjdk.java.net/jdk9/dev/nashorn/file/4b118e012ac4/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java#l532 > > The method name for the stack trace is computed in > NashornException#getScriptFrames: > > http://hg.openjdk.java.net/jdk9/dev/nashorn/file/4b118e012ac4/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/NashornException.java#l174 > > I've filed a bug for this: > https://bugs.openjdk.java.net/browse/JDK-8156896 > > Hannes > > >> On Thu, May 12, 2016 at 2:12 PM, Hannes Wallnoefer < >> hannes.wallnoefer at oracle.com > >> wrote: >> >> Hi Vivin, >> >> What you see is some fuzziness in the translation from JS >> functions to Java methods and from there to the stack traces you see. >> >> When we compile a JS function, we create a Java method with the >> name of the function concatenated to the names of its parent >> functions, using '$' as separator. For anonymous functions we use >> something like L:123 as name where 123 is the line of code where >> the function begins. >> >> This method naming scheme helps a lot in making bytecode easier to >> debug, and to create unique method names within a compilation >> unit. However, it also leads to the stack traces you see, getting >> f$foo in the first case and something like L1:foo in the second >> case, which is rendered as in the stack trace. >> >> Ideally we should reverse this when printing stack traces, >> displaying only the name of the function itself, e.g. "bar" for >> "foo$bar" and "" for "foo$L:3". Unfortunately, "$" is a >> valid character in a JS identifier, so it's not that easy, >> "foo$bar" may also be the name of the original function. >> >> I'm thinking about how to solve this and will probably file an >> issue for it. >> >> Hannes >> >> Am 2016-05-12 um 15:59 schrieb Vivin Suresh Paliath: >> >> I tried this out on in chrome and I get the expected stack >> trace there. Is >> this a bug? >> On May 6, 2016 3:39 PM, "Vivin Suresh Paliath" >> > >> >> wrote: >> >> I have the following code: >> >> *var f = (function() {* >> * return function foo() {* >> * try {* >> * throw new Error();* >> * } catch(e) {* >> * print(e.stack);* >> * }* >> * }* >> *})();* >> >> >> When I call the function, I get the following stacktrace >> as expected >> (mostly; I was expecting *foo* instead of *f$foo*). >> >> *Error* >> * at f$foo (:1)* >> * at (:1)* >> >> >> However, if I dynamically construct the function as follows: >> >> *var f = new Function([], "return function foo() { try { >> throw new >> Error(); } catch(e) { print(e.stack); } }")()* >> >> >> I get: >> >> >> *Error* >> * at (:2)* >> * at (:1)* >> >> >> Is there a reason for this discrepancy? Isn't the second >> version >> effectively the same as the first? Also, why is it *f$foo* >> instead of >> *foo* in the first case? >> >> I am running jdk8u92. >> >> Thanks! >> >> -- >> Ruin untold; >> And thine own sadness, >> Sing in the grass, >> When eve has forgot, that no more hear common things that >> gleam and pass; >> But seek alone to lip, sad Rose of love and ruin untold; >> And thine own mother >> Can know it as I know >> More than another >> What makes your own sadness, >> Set in her eyes. >> >> map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". >> ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". >> ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". >> ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". >> ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". >> ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". >> ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". >> ":13:02:11:01:02:11:01:12:02";map{print chr unpack" >> i",pack"B32",$_}$j=~m/.{8}/g >> >> >> >> >> >> -- >> *[vivin.net :: github :: >> linkedin ]* >> > > -- *[vivin.net :: github :: linkedin ]* From sundararajan.athijegannathan at oracle.com Fri May 13 03:11:38 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 13 May 2016 08:41:38 +0530 Subject: Stacktraces from dynamically-constructed functions not as expected In-Reply-To: <5734F1AF.9030600@oracle.com> References: <5734F1AF.9030600@oracle.com> Message-ID: <1ea7acbb-af19-b95c-3ccf-94d49d1fd28a@oracle.com> Adding to what Hannes said: "stack" property and the format of stack trace are not part of ECMAScript standard. Implementations could differ in this. This is more of debugging aid as Hannes mentioned. I'd personally prefer names being shown in stack traces whenever possible - rather than being shown! The fact that user chose to name an "anonymous" function => s/he prefers to name the function expression in question. Purpose? Most likely debugging/code-search aid. So, I'd rather like that name be shown in some form. [whether to show source name "foo" for "f$foo" is another question. But "foo" being included in some form]. That said, if there is any ECMAScript standard specified API that is broken because of this choice by nashorn, we should attempt to fix that. Thanks, -Sundar On 5/13/2016 2:42 AM, Hannes Wallnoefer wrote: > Hi Vivin, > > What you see is some fuzziness in the translation from JS functions to > Java methods and from there to the stack traces you see. > > When we compile a JS function, we create a Java method with the name > of the function concatenated to the names of its parent functions, > using '$' as separator. For anonymous functions we use something like > L:123 as name where 123 is the line of code where the function begins. > > This method naming scheme helps a lot in making bytecode easier to > debug, and to create unique method names within a compilation unit. > However, it also leads to the stack traces you see, getting f$foo in > the first case and something like L1:foo in the second case, which is > rendered as in the stack trace. > > Ideally we should reverse this when printing stack traces, displaying > only the name of the function itself, e.g. "bar" for "foo$bar" and > "" for "foo$L:3". Unfortunately, "$" is a valid character > in a JS identifier, so it's not that easy, "foo$bar" may also be the > name of the original function. > > I'm thinking about how to solve this and will probably file an issue > for it. > > Hannes > > Am 2016-05-12 um 15:59 schrieb Vivin Suresh Paliath: >> I tried this out on in chrome and I get the expected stack trace >> there. Is >> this a bug? >> On May 6, 2016 3:39 PM, "Vivin Suresh Paliath" >> wrote: >> >>> I have the following code: >>> >>> *var f = (function() {* >>> * return function foo() {* >>> * try {* >>> * throw new Error();* >>> * } catch(e) {* >>> * print(e.stack);* >>> * }* >>> * }* >>> *})();* >>> >>> >>> When I call the function, I get the following stacktrace as expected >>> (mostly; I was expecting *foo* instead of *f$foo*). >>> >>> *Error* >>> * at f$foo (:1)* >>> * at (:1)* >>> >>> >>> However, if I dynamically construct the function as follows: >>> >>> *var f = new Function([], "return function foo() { try { throw new >>> Error(); } catch(e) { print(e.stack); } }")()* >>> >>> >>> I get: >>> >>> >>> *Error* >>> * at (:2)* >>> * at (:1)* >>> >>> >>> Is there a reason for this discrepancy? Isn't the second version >>> effectively the same as the first? Also, why is it *f$foo* instead of >>> *foo* in the first case? >>> >>> I am running jdk8u92. >>> >>> Thanks! >>> >>> -- >>> Ruin untold; >>> And thine own sadness, >>> Sing in the grass, >>> When eve has forgot, that no more hear common things that gleam and >>> pass; >>> But seek alone to lip, sad Rose of love and ruin untold; >>> And thine own mother >>> Can know it as I know >>> More than another >>> What makes your own sadness, >>> Set in her eyes. >>> >>> map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". >>> ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". >>> ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". >>> ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". >>> ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". >>> ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". >>> ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". >>> ":13:02:11:01:02:11:01:12:02";map{print chr unpack" >>> i",pack"B32",$_}$j=~m/.{8}/g >>> > From sundararajan.athijegannathan at oracle.com Fri May 13 04:30:42 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 13 May 2016 10:00:42 +0530 Subject: JDK9 features In-Reply-To: References: <0af361e3-0ad9-4671-33af-049682b52780@oracle.com> Message-ID: <3adf32e0-2690-1c52-e156-8341f9024d21@oracle.com> Hi Eric, That commonjs/require loading pattern is not bad [wrapping eval'ed code inside a function]. If your loaded scripts are (somewhat) well-behaved, it does solve the problem of global namespace pollution. Yes, ScriptObjectMirrors are not uniformly treated like ScriptObject everywhere. But, I'm not sure how far we can fix that :( Is JSON handling (w.r.t ScriptObjectMirror) your main pain point? We *may* be able to address that. Thanks, -Sundar On 5/12/2016 11:10 PM, Eric Pederson wrote: > Hi Sundar: > > 1. I investigated loadWithNewGlobal because it looked promising for > this use case. Say you use loadWithNewGlobal to load a function. If > you call the loaded function and it returns an object or array the > caller gets a ScriptObjectMirror. The problems with a > ScriptObjectMirror "object" are: > > * Cannot call Object methods like keys or getOwnPropertyNames. You > get an exception: TypeError: cannot call undefined. To iterate > over the properties you must use a for in loop. > * Cannot convert ScriptObjectMirror to JSON using JSON.stringify. > It returns undefined. > > If the function loaded with loadWithNewGlobal returns an array then > things are better. Interestingly you can call most Array methods > (like forEach and map) on a ScriptObjectMirror "array". > But JSON.stringify also returns undefined. > > I did find one issue with an array returned by a loadWithNewGlobal > loaded function - calling sort with a comparator. For example, if the > loaded function returned testArray, a ScriptObjectMirror "array": > > *var **/sorted /*= */testArray/*.sort(*function*(a, b) { > > *return *a - b; }); > > > > throws an exception_: _TypeError: function(a, b) { return a - b; } is > not a function. > > > These were the same "mutant" issues that we also saw with JSObjects > returned by Java methods. > > > The hack that we are using now to load code without effecting the > global namespace is the same one discussed in this thread: > > http://thread.gmane.org/gmane.comp.java.openjdk.nashorn.devel/1722. > > > The code that we are using is copied/adapted from Vertx (thanks, Tim!): > > > function loadEval(path) { > > *var *dir = *new **/File/*(path).getParent(); > > *var *body = /readFile/(path); > > *var *moduleFunc = > > *"function(exports, module, require, __filename, > __dirname){" *+ body + *"**\n**}**\n**//# sourceURL=" *+ path; > > > *try {* > > *var *func = eval(moduleFunc); > > } *catch *(ex) { > > *if *(ex *instanceof **SyntaxError*) { > > /// WARNING! Large pile of Yak hair ahead! > / > > / /*var *ne = ex.nashornException; > > *var *cause = ne.cause; > > *var *msg = cause.message.replace(*""*, file); > > *var *lineNumber = cause.*lineNumber;* > > console.log(*"ERROR: " *+ msg + *" in file " *+ file + *" > at line " *+ lineNumber); > } > > *throw *ex; > } > > *var *module = { *exports*: {} }; > > func(module.*exports*, module, require, path, dir); > > *return *module.*exports*; > > } > > > This seems like a hack to me - but I'm coming from the Java world so > this may be par for the course in Javascript-land :) Hack or no, it > is the best of both worlds: it does not change the global namespace, > yet the code that it returns lives in the global context, so if you > call a loaded function it will return a native object, not > a ScriptObjectMirror. > > > We'd like to have a built-in equivalent of this loadEvalfunction. It > doesn't need to use those specific arguments (export, module, etc), > but you must be able to pass arguments in to provide a context to the > loaded code. > > > Alternatively if you could make ScriptObjectMirrors 100% compatible > with native objects that would work too. Then we could use > loadWithNewGlobal. > > > 2. The problem that we are having with objects returned by Java > methods is the same as what I described above because the returned > JSObjects are seen as ScriptObjectMirrors by the calling Javascript > code. > > > What we are doing now is wrapping each Java object with a Javascript > proxy. When you call the proxy it calls the corresponding Java > method, then converts the returned ScriptObjectMirrorinto a native JS > object using a custom conversion function. > > > What would be nice for this use case is a standard function to convert > ScriptObjectMirrors to native JS objects (what I was > calling asJSONCompatible below). Or if ScriptObjectMirrors were 100% > compatible that would be even better - we could get rid of our JS > proxy objects. > > > I'm happy to file some enhancement requests. Though it seems like the > bug trackers are read-only to the general public though, how would I > get access? > > > Thanks, > > > > -- Eric > > On Thu, May 12, 2016 at 12:36 AM, Sundararajan Athijegannathan > > wrote: > > Hi, > > Thanks for your comments! > > Making comments on forthcoming JDK releases is hard :) Whatever I'm > saying now, may not happen - the usual disclaimer applies. > > No, we expect that only a subset of ES6 features will be > implemented for > Java 9. > > 1. On loading definitions without changing global namespace: you meant > current global namespace? loadWithNewGlobal creates a new global and > loads definitions into that. > > Would that be useful for you? or anything else? Which hack you're > referring to? Please file an enhancement with your requirements. > > 2. on JSON: Again, will you please provide a simple test case and/or > file an enhancement with requirements? > > Thanks, > -Sundar > > On 5/12/2016 12:56 AM, Eric Pederson wrote: > > I've been noticing the Java 9 ES6 features tweeted by > @sundararajan_a > > . Looks awesome! Will > there be full > > ES6 support in Java 9? > > > > There are a couple of other things we would love to see in the > updated > > Nashorn: > > > > 1. We've been using the same hack that you recommended to Tim > Fox for > > loading functions without changing the global namespace - the > Avatar/js > > CommonJS/require hack. It would be great if this was supported > natively in > > Nashorn via a new loadXXX(). > > > > 2. It would be also be great to have the inverse of > asJSONCompatible for a) > > JSObjects returned by Java code and b) objects from other > scopes. Our name > > for ScriptObjectMirrors in Javascript code is "mutant objects": > they look > > like regular JS objects but they are missing most of their DNA, > and you > > don't realize until you get an exception or silent failure > somewhere down > > the call chain where it's difficult to figure out why :) > > > > Anyway, the upcoming stuff looks great! > > > > Thanks, > > > > -- Eric > > From vivin.paliath at gmail.com Fri May 13 05:21:13 2016 From: vivin.paliath at gmail.com (Vivin Suresh Paliath) Date: Thu, 12 May 2016 22:21:13 -0700 Subject: Stacktraces from dynamically-constructed functions not as expected In-Reply-To: References: <5734F1AF.9030600@oracle.com> <1ea7acbb-af19-b95c-3ccf-94d49d1fd28a@oracle.com> Message-ID: I have the same preference! That is exactly why I name functions even when they are function expressions. I am developing an API where having the name of the function in the stack trace would be a useful debugging aid as well. Yes the f$foo vs. foo is a different issue, but I would also prefer that foo is shown regardless. I noticed that I was able to replicate the behavior of the second case if I removed the "var f =" and immediately invoked the result of the IIFE. Since I am on jdk8u92 I checked out the 8u-dev branch and stepped through the parser (by the way, is it possible to check out the Nashorn source for 8u92? I only saw a 8u92-b14 tag). I noticed that it does create an IdentNode with "foo", and then uses that to create a FunctionNode instance. I am not sure how the function still ends up as anonymous but I am planning to look at it in some more detail tomorrow. On May 12, 2016 8:12 PM, "Sundararajan Athijegannathan" < sundararajan.athijegannathan at oracle.com> wrote: Adding to what Hannes said: "stack" property and the format of stack trace are not part of ECMAScript standard. Implementations could differ in this. This is more of debugging aid as Hannes mentioned. I'd personally prefer names being shown in stack traces whenever possible - rather than being shown! The fact that user chose to name an "anonymous" function => s/he prefers to name the function expression in question. Purpose? Most likely debugging/code-search aid. So, I'd rather like that name be shown in some form. [whether to show source name "foo" for "f$foo" is another question. But "foo" being included in some form]. That said, if there is any ECMAScript standard specified API that is broken because of this choice by nashorn, we should attempt to fix that. Thanks, -Sundar On 5/13/2016 2:42 AM, Hannes Wallnoefer wrote: > Hi Vivin, > > What you see is some fuzziness in the translation from JS functions to > Java methods and from there to the stack traces you see. > > When we compile a JS function, we create a Java method with the name > of the function concatenated to the names of its parent functions, > using '$' as separator. For anonymous functions we use something like > L:123 as name where 123 is the line of code where the function begins. > > This method naming scheme helps a lot in making bytecode easier to > debug, and to create unique method names within a compilation unit. > However, it also leads to the stack traces you see, getting f$foo in > the first case and something like L1:foo in the second case, which is > rendered as in the stack trace. > > Ideally we should reverse this when printing stack traces, displaying > only the name of the function itself, e.g. "bar" for "foo$bar" and > "" for "foo$L:3". Unfortunately, "$" is a valid character > in a JS identifier, so it's not that easy, "foo$bar" may also be the > name of the original function. > > I'm thinking about how to solve this and will probably file an issue > for it. > > Hannes > > Am 2016-05-12 um 15:59 schrieb Vivin Suresh Paliath: >> I tried this out on in chrome and I get the expected stack trace >> there. Is >> this a bug? >> On May 6, 2016 3:39 PM, "Vivin Suresh Paliath" >> wrote: >> >>> I have the following code: >>> >>> *var f = (function() {* >>> * return function foo() {* >>> * try {* >>> * throw new Error();* >>> * } catch(e) {* >>> * print(e.stack);* >>> * }* >>> * }* >>> *})();* >>> >>> >>> When I call the function, I get the following stacktrace as expected >>> (mostly; I was expecting *foo* instead of *f$foo*). >>> >>> *Error* >>> * at f$foo (:1)* >>> * at (:1)* >>> >>> >>> However, if I dynamically construct the function as follows: >>> >>> *var f = new Function([], "return function foo() { try { throw new >>> Error(); } catch(e) { print(e.stack); } }")()* >>> >>> >>> I get: >>> >>> >>> *Error* >>> * at (:2)* >>> * at (:1)* >>> >>> >>> Is there a reason for this discrepancy? Isn't the second version >>> effectively the same as the first? Also, why is it *f$foo* instead of >>> *foo* in the first case? >>> >>> I am running jdk8u92. >>> >>> Thanks! >>> >>> -- >>> Ruin untold; >>> And thine own sadness, >>> Sing in the grass, >>> When eve has forgot, that no more hear common things that gleam and >>> pass; >>> But seek alone to lip, sad Rose of love and ruin untold; >>> And thine own mother >>> Can know it as I know >>> More than another >>> What makes your own sadness, >>> Set in her eyes. >>> >>> map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". >>> ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". >>> ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". >>> ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". >>> ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". >>> ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". >>> ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". >>> ":13:02:11:01:02:11:01:12:02";map{print chr unpack" >>> i",pack"B32",$_}$j=~m/.{8}/g >>> > From emilian.bold at gmail.com Fri May 13 08:09:16 2016 From: emilian.bold at gmail.com (Emilian Bold) Date: Fri, 13 May 2016 11:09:16 +0300 Subject: Tree API Javadoc down? In-Reply-To: <57349723.7070801@oracle.com> References: <57349723.7070801@oracle.com> Message-ID: Thanks! I guess it would have been too hard for them to add a 301 redirect? --emi On Thu, May 12, 2016 at 5:45 PM, Claes Redestad wrote: > Hi, > > I saw elsewhere that docs have moved into /java (sigh): > > > http://download.java.net/java/jdk9/docs/jdk/api/nashorn/jdk/nashorn/api/tree/IfTree.html > > /Claes > > > On 2016-05-12 16:44, Emilian Bold wrote: > >> Hello, >> >> Google gives me this URL (which I used before) >> >> http://download.java.net/jdk9/docs/jdk/api/nashorn/jdk/nashorn/api/tree/IfTree.html >> but >> it seems to be down (404). >> >> Has the Javadoc moved to some other place? >> >> Google Cache URL: >> >> http://webcache.googleusercontent.com/search?q=cache:ud0OiFY0S6wJ:download.java.net/jdk9/docs/jdk/api/nashorn/jdk/nashorn/api/tree/IfTree.html+&cd=1&hl=en&ct=clnk&gl=ro >> >> --emi >> > > From emilian.bold at gmail.com Fri May 13 08:17:46 2016 From: emilian.bold at gmail.com (Emilian Bold) Date: Fri, 13 May 2016 11:17:46 +0300 Subject: Tree API: offsets for String fields In-Reply-To: <4d92acf8-d3b3-2280-c0d6-063e6b453d45@oracle.com> References: <4d92acf8-d3b3-2280-c0d6-063e6b453d45@oracle.com> Message-ID: Thank you! PS: It would be great if JBS would allow me to register for email updates on issues I care about... --emi On Thu, May 12, 2016 at 8:10 PM, Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > Filed: https://bugs.openjdk.java.net/browse/JDK-8156866 > > PS. Actually, I was wrong about MemberSelectTree - even internally nashorn > IR node "AccessNode" maintains 'property' as a String. But, variables, > functions have identifier nodes for names. > > Thanks, > > -Sundar > > > On 5/12/2016 10:20 PM, Emilian Bold wrote: > > Assuming I don't need some special permissions to do that (do I?) I could > expand the previous email and post it as an enhancement on > https://bugs.openjdk.java.net > > But I'm also trying to understand the logic behind what you have. > > The way I see it any AST node has some underlying tokens so its offsets > should be based on that. > > Take VariableTree. The Javadoc mentions: > > var name initializer ; > > but I assume the offset ranges are something like > > var [name = [initializer]] ; > > So, 'var' and whatever whitespace there is in between is ignored. The > 'name' offsets are not explicit but may be inferred. > > (A similar problem with FunctionDeclarationTree.) > > What I would do with Variable Tree would be to have the offset ranges like: > > [var [name] = [initializer]] > > with the VariableTree covering everything ('var' too) and 'name' having a > separate IdentifierTree. > > Continue/BreakTree/LabeledStatementTree are not really that > important/used so if there is no internal info it's no big loss. > > --emi > > > On Thu, May 12, 2016 at 7:19 PM, Sundararajan Athijegannathan < > > sundararajan.athijegannathan at oracle.com> wrote: > >> Hi, >> >> Thanks for your comments. Nashorn Parser API was modeled after similar >> API provided by javac - for consistency sake and to leverage developer >> familiarity. For example, ContinueTree, MemberSelectTree of javac Tree >> API: >> >> >> https://docs.oracle.com/javase/8/docs/jdk/api/javac/tree/com/sun/source/tree/ContinueTree.html >> >> >> https://docs.oracle.com/javase/8/docs/jdk/api/javac/tree/com/sun/source/tree/MemberSelectTree.html >> >> I agree that consistency should not result in API 'mistakes/gaps' being >> propagated here. BTW, labels are maintained as strings even >> internally. Member select property, Variable name , Function name etc. >> are all identifiers and so it is possible to make API return >> IdentifierTree objects. Will you please collect whatever you found and >> file a bug/enhancement for Nashorn parser API? >> >> Thanks, >> >> -Sundar >> >> >> On 5/12/2016 9:10 PM, Emilian Bold wrote: >> > Hello, >> > >> > It's really important for a Javascript editor to know the offsets of >> each >> > syntax tree node and of whatever the node contains (I'm not really >> saying >> > tokens but... constituent parts and keywords are the minimum). >> > >> > So it would be great to provide or document how offsets are to be >> computed >> > for the String fields from the Nashorn Tree API. >> > >> > (Ideally the API could also be changed to use an IdentifierTree or some >> > other Tree subclass which provides the start/endPosition.) >> > >> > A few examples: >> > >> > * MemberSelectTree has a String getIdentifier. Since I *assume* that the >> > MemberSelectTree.getEndPosition is right after the identifier, I have to >> > subtract the identifier length to get the identifier start offset. >> > >> > * VariableTree has a String getName(). It seems to me that >> > VariableTree.getStartPosition is the 'name' startPosition. This also >> means >> > you cannot really know where 'var' actually is -- it could be on another >> > line altogether; it's also odd to me that 'var' is outside the [start, >> end] >> > range for the VariableTree. >> > >> > * ContinueTree and BreakTree both have a String getLabel >> > >> > * LabeledStatementTree has a String getLabel >> > >> > * FunctionExpressionTree and FunctionDeclarationTree both have a String >> > getName but I'm not sure how the offset for that is computed. Also not >> sure >> > how the offset of the 'function' keyword would be computed. >> > >> > Could somebody explain this to me? I'll make a nice list for future >> > reference. >> > >> > --emi >> >> > > From hannes.wallnoefer at oracle.com Fri May 13 09:44:18 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 13 May 2016 11:44:18 +0200 Subject: Review request for JDK-8156896: Script stack trace should display function names Message-ID: <5735A1F2.6080300@oracle.com> Review request for JDK-8156896: Script stack trace should display function names http://cr.openjdk.java.net/~hannesw/8156896/webrev/ This makes it possible to reliably get the original function name from Java method names for display in script stack traces. It replaces '$' with '#' as separator for nested function method names as '#' is not a valid JS identifier part, but allowed in JVM method names. Hannes From szegedia at gmail.com Fri May 13 09:59:19 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 13 May 2016 11:59:19 +0200 Subject: Review request for JDK-8156896: Script stack trace should display function names In-Reply-To: <5735A1F2.6080300@oracle.com> References: <5735A1F2.6080300@oracle.com> Message-ID: +1 > On 13 May 2016, at 11:44, Hannes Wallnoefer wrote: > > Review request for JDK-8156896: Script stack trace should display function names > > http://cr.openjdk.java.net/~hannesw/8156896/webrev/ > > This makes it possible to reliably get the original function name from Java method names for display in script stack traces. It replaces '$' with '#' as separator for nested function method names as '#' is not a valid JS identifier part, but allowed in JVM method names. > > Hannes From sundararajan.athijegannathan at oracle.com Fri May 13 09:59:47 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 13 May 2016 15:29:47 +0530 Subject: Review request for JDK-8156896: Script stack trace should display function names In-Reply-To: <5735A1F2.6080300@oracle.com> References: <5735A1F2.6080300@oracle.com> Message-ID: +1 On 5/13/2016 3:14 PM, Hannes Wallnoefer wrote: > Review request for JDK-8156896: Script stack trace should display > function names > > http://cr.openjdk.java.net/~hannesw/8156896/webrev/ > > This makes it possible to reliably get the original function name from > Java method names for display in script stack traces. It replaces '$' > with '#' as separator for nested function method names as '#' is not a > valid JS identifier part, but allowed in JVM method names. > > Hannes From vivin.paliath at gmail.com Fri May 13 14:16:25 2016 From: vivin.paliath at gmail.com (Vivin Suresh Paliath) Date: Fri, 13 May 2016 07:16:25 -0700 Subject: Review request for JDK-8156896: Script stack trace should display function names In-Reply-To: References: <5735A1F2.6080300@oracle.com> Message-ID: +1 Would it be possible to backport this to jdk8? On May 13, 2016 3:00 AM, "Sundararajan Athijegannathan" < sundararajan.athijegannathan at oracle.com> wrote: > +1 > > > On 5/13/2016 3:14 PM, Hannes Wallnoefer wrote: > > Review request for JDK-8156896: Script stack trace should display > > function names > > > > http://cr.openjdk.java.net/~hannesw/8156896/webrev/ > > > > This makes it possible to reliably get the original function name from > > Java method names for display in script stack traces. It replaces '$' > > with '#' as separator for nested function method names as '#' is not a > > valid JS identifier part, but allowed in JVM method names. > > > > Hannes > > From ericacm at gmail.com Fri May 13 14:46:21 2016 From: ericacm at gmail.com (Eric Pederson) Date: Fri, 13 May 2016 10:46:21 -0400 Subject: JDK9 features In-Reply-To: <3adf32e0-2690-1c52-e156-8341f9024d21@oracle.com> References: <0af361e3-0ad9-4671-33af-049682b52780@oracle.com> <3adf32e0-2690-1c52-e156-8341f9024d21@oracle.com> Message-ID: Hi Sundar - It would be helpful for sure. We use JSON for serialization and debugging a lot. Also if it worked it could simplify our custom ScriptObjectMirror -> native object conversion logic from 30 lines down to JSON.parse(JSON.stringify(scriptObjMirror)) :). Besides the JSON stuff our biggest problem has been ScriptObjectMirrors being treated like regular objects and passed down call chains and then either throwing exceptions or silently failing and it's hard to figure out why. Junior developers get completely baffled. We have solved the problem with the commonjs/require loading pattern on the script loading side and the proxy pattern on the Java calling side. It would be nice to have official solutions for these but it's not urgent. It might be something worth adding to the documentation. Thanks, -- Eric On Fri, May 13, 2016 at 12:30 AM, Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > Hi Eric, > > That commonjs/require loading pattern is not bad [wrapping eval'ed code > inside a function]. If your loaded scripts are (somewhat) well-behaved, it > does solve the problem of global namespace pollution. > > Yes, ScriptObjectMirrors are not uniformly treated like ScriptObject > everywhere. But, I'm not sure how far we can fix that :( Is JSON handling > (w.r.t ScriptObjectMirror) your main pain point? We *may* be able to > address that. > > Thanks, > > -Sundar > > On 5/12/2016 11:10 PM, Eric Pederson wrote: > > Hi Sundar: > > 1. I investigated loadWithNewGlobal because it looked promising for this > use case. Say you use loadWithNewGlobal to load a function. If you call > the loaded function and it returns an object or array the caller gets a > ScriptObjectMirror. The problems with a ScriptObjectMirror "object" are: > > - Cannot call Object methods like keys or getOwnPropertyNames. You > get an exception: TypeError: cannot call undefined. To iterate over > the properties you must use a for in loop. > - Cannot convert ScriptObjectMirror to JSON using JSON.stringify. It > returns undefined. > > If the function loaded with loadWithNewGlobal returns an array then > things are better. Interestingly you can call most Array methods (like > forEach and map) on a ScriptObjectMirror "array". But JSON.stringify also > returns undefined. > > I did find one issue with an array returned by a loadWithNewGlobal loaded > function - calling sort with a comparator. For example, if the loaded > function returned testArray, a ScriptObjectMirror "array": > > *var **sorted *= *testArray*.sort(*function*(a, b) { > > *return *a - b; > }); > > > > throws an exception*: *TypeError: function(a, b) { return a - b; } is not > a function. > > > These were the same "mutant" issues that we also saw with JSObjects > returned by Java methods. > > > The hack that we are using now to load code without effecting the global > namespace is the same one discussed in this thread: > > > http://thread.gmane.org/gmane.comp.java.openjdk.nashorn.devel/1722. > > > The code that we are using is copied/adapted from Vertx (thanks, Tim!): > > > function loadEval(path) { > > *var *dir = *new **File*(path).getParent(); > > *var *body = *readFile*(path); > > *var *moduleFunc = > > *"function(exports, module, require, __filename, __dirname){" *+ body > + *"**\n**}**\n**//# sourceURL=" *+ path; > > > *try {* > > *var *func = eval(moduleFunc); > > } *catch *(ex) { > > *if *(ex *instanceof **SyntaxError*) { > > > *// WARNING! Large pile of Yak hair ahead! * > > *var *ne = ex.nashornException; > > *var *cause = ne.cause; > > *var *msg = cause.message.replace(*""*, file); > > *var *lineNumber = cause.*lineNumber;* > > console.log(*"ERROR: " *+ msg + *" in file " *+ file + *" at line > " *+ lineNumber); > } > > *throw *ex; > } > > *var *module = { *exports*: {} }; > > func(module.*exports*, module, require, path, dir); > > *return *module.*exports*; > > } > > > This seems like a hack to me - but I'm coming from the Java world so this > may be par for the course in Javascript-land :) Hack or no, it is the > best of both worlds: it does not change the global namespace, yet the code > that it returns lives in the global context, so if you call a loaded > function it will return a native object, not a ScriptObjectMirror. > > > We'd like to have a built-in equivalent of this loadEval function. It > doesn't need to use those specific arguments (export, module, etc), but > you must be able to pass arguments in to provide a context to the loaded > code. > > > Alternatively if you could make ScriptObjectMirrors 100% compatible with > native objects that would work too. Then we could use loadWithNewGlobal. > > > 2. The problem that we are having with objects returned by Java methods > is the same as what I described above because the returned JSObjects are > seen as ScriptObjectMirrors by the calling Javascript code. > > > What we are doing now is wrapping each Java object with a Javascript > proxy. When you call the proxy it calls the corresponding Java method, > then converts the returned ScriptObjectMirror into a native JS object > using a custom conversion function. > > > What would be nice for this use case is a standard function to convert > ScriptObjectMirrors to native JS objects (what I was calling asJSONCompatible > below). Or if ScriptObjectMirrors were 100% compatible that would be > even better - we could get rid of our JS proxy objects. > > > I'm happy to file some enhancement requests. Though it seems like the bug > trackers are read-only to the general public though, how would I get access? > > > Thanks, > > > -- Eric > > On Thu, May 12, 2016 at 12:36 AM, Sundararajan Athijegannathan < > > sundararajan.athijegannathan at oracle.com> wrote: > >> Hi, >> >> Thanks for your comments! >> >> Making comments on forthcoming JDK releases is hard :) Whatever I'm >> saying now, may not happen - the usual disclaimer applies. >> >> No, we expect that only a subset of ES6 features will be implemented for >> Java 9. >> >> 1. On loading definitions without changing global namespace: you meant >> current global namespace? loadWithNewGlobal creates a new global and >> loads definitions into that. >> >> Would that be useful for you? or anything else? Which hack you're >> referring to? Please file an enhancement with your requirements. >> >> 2. on JSON: Again, will you please provide a simple test case and/or >> file an enhancement with requirements? >> >> Thanks, >> -Sundar >> >> On 5/12/2016 12:56 AM, Eric Pederson wrote: >> > I've been noticing the Java 9 ES6 features tweeted by @sundararajan_a >> > . Looks awesome! Will there be >> full >> > ES6 support in Java 9? >> > >> > There are a couple of other things we would love to see in the updated >> > Nashorn: >> > >> > 1. We've been using the same hack that you recommended to Tim Fox for >> > loading functions without changing the global namespace - the Avatar/js >> > CommonJS/require hack. It would be great if this was supported >> natively in >> > Nashorn via a new loadXXX(). >> > >> > 2. It would be also be great to have the inverse of asJSONCompatible >> for a) >> > JSObjects returned by Java code and b) objects from other scopes. Our >> name >> > for ScriptObjectMirrors in Javascript code is "mutant objects": they >> look >> > like regular JS objects but they are missing most of their DNA, and you >> > don't realize until you get an exception or silent failure somewhere >> down >> > the call chain where it's difficult to figure out why :) >> > >> > Anyway, the upcoming stuff looks great! >> > >> > Thanks, >> > >> > -- Eric >> >> > > From hannes.wallnoefer at oracle.com Fri May 13 15:52:31 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 13 May 2016 17:52:31 +0200 Subject: Review request for JDK-8156714: Parsing issue with automatic semicolon insertion Message-ID: <5735F83F.9080404@oracle.com> 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 james.laskey at oracle.com Fri May 13 15:57:12 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 13 May 2016 12:57:12 -0300 Subject: Review request for JDK-8156714: Parsing issue with automatic semicolon insertion In-Reply-To: <5735F83F.9080404@oracle.com> References: <5735F83F.9080404@oracle.com> Message-ID: <9EB831F5-0E09-4419-BCD1-2A484E4E6751@oracle.com> +1 > On May 13, 2016, at 12:52 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 Fri May 13 16:12:41 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 13 May 2016 21:42:41 +0530 Subject: Review request for JDK-8156714: Parsing issue with automatic semicolon insertion In-Reply-To: <5735F83F.9080404@oracle.com> References: <5735F83F.9080404@oracle.com> Message-ID: +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 vivin.paliath at gmail.com Fri May 13 17:22:27 2016 From: vivin.paliath at gmail.com (Vivin Suresh Paliath) Date: Fri, 13 May 2016 10:22:27 -0700 Subject: Review request for JDK-8156896: Script stack trace should display function names In-Reply-To: References: <5735A1F2.6080300@oracle.com> Message-ID: I was able to apply the same changes to jdk8u-dev and it looks like it properly reports the function name in the stacktrace now. I can submit a fix so that this behavior is also available on jdk8. On Fri, May 13, 2016 at 7:16 AM, Vivin Suresh Paliath < vivin.paliath at gmail.com> wrote: > +1 > > Would it be possible to backport this to jdk8? > On May 13, 2016 3:00 AM, "Sundararajan Athijegannathan" < > sundararajan.athijegannathan at oracle.com> wrote: > >> +1 >> >> >> On 5/13/2016 3:14 PM, Hannes Wallnoefer wrote: >> > Review request for JDK-8156896: Script stack trace should display >> > function names >> > >> > http://cr.openjdk.java.net/~hannesw/8156896/webrev/ >> > >> > This makes it possible to reliably get the original function name from >> > Java method names for display in script stack traces. It replaces '$' >> > with '#' as separator for nested function method names as '#' is not a >> > valid JS identifier part, but allowed in JVM method names. >> > >> > Hannes >> >> -- *[vivin.net :: github :: linkedin ]* From vivin.paliath at gmail.com Fri May 13 18:37:35 2016 From: vivin.paliath at gmail.com (Vivin Suresh Paliath) Date: Fri, 13 May 2016 11:37:35 -0700 Subject: [PATCH] 8156896: Script stack trace should display function names Message-ID: This is Hannes' fix backported to jdk8. I see that the original issue has been closed, so I am not sure if I should be using the same id or not. I did try running the tests, but JDK-814421.js fails because there seems to be some issue with arguments when they are passed along with the shebang (everything after 19 characters is chopped off). I have added a test for 8156896, but I wasn't able to run it because of the failing test. I had a quick look at the build.xml file but couldn't tell how the tests in script/basic get run. -- *[vivin.net :: github :: linkedin ]* -------------- next part -------------- diff --git a/src/jdk/nashorn/api/scripting/NashornException.java b/src/jdk/nashorn/api/scripting/NashornException.java --- a/src/jdk/nashorn/api/scripting/NashornException.java +++ b/src/jdk/nashorn/api/scripting/NashornException.java @@ -175,10 +175,8 @@ String methodName = st.getMethodName(); if (methodName.equals(CompilerConstants.PROGRAM.symbolName())) { methodName = ""; - } - - if (methodName.contains(CompilerConstants.ANON_FUNCTION_PREFIX.symbolName())) { - methodName = ""; + } else { + methodName = stripMethodName(methodName); } filtered.add(new StackTraceElement(className, methodName, @@ -188,6 +186,22 @@ return filtered.toArray(new StackTraceElement[filtered.size()]); } + private static String stripMethodName(final String methodName) { + String name = methodName; + + final int nestedSeparator = name.lastIndexOf(CompilerConstants.NESTED_FUNCTION_SEPARATOR.symbolName()); + if (nestedSeparator >= 0) { + name = name.substring(nestedSeparator + 1); + } + + final int idSeparator = name.indexOf(CompilerConstants.ID_FUNCTION_SEPARATOR.symbolName()); + if (idSeparator >= 0) { + name = name.substring(0, idSeparator); + } + + return name.contains(CompilerConstants.ANON_FUNCTION_PREFIX.symbolName()) ? "" : name; + } + /** * Return a formatted script stack trace string with frames information separated by '\n' * diff --git a/src/jdk/nashorn/internal/codegen/CompilerConstants.java b/src/jdk/nashorn/internal/codegen/CompilerConstants.java --- a/src/jdk/nashorn/internal/codegen/CompilerConstants.java +++ b/src/jdk/nashorn/internal/codegen/CompilerConstants.java @@ -78,6 +78,12 @@ /** function prefix for anonymous functions */ ANON_FUNCTION_PREFIX("L:"), + /** separator for method names of nested functions */ + NESTED_FUNCTION_SEPARATOR("#"), + + /** separator for making method names unique by appending numberic ids */ + ID_FUNCTION_SEPARATOR("-"), + /** method name for Java method that is the program entry point */ PROGRAM(":program"), diff --git a/src/jdk/nashorn/internal/codegen/Namespace.java b/src/jdk/nashorn/internal/codegen/Namespace.java --- a/src/jdk/nashorn/internal/codegen/Namespace.java +++ b/src/jdk/nashorn/internal/codegen/Namespace.java @@ -68,7 +68,7 @@ } /** - * Create a uniqueName name in the namespace in the form base$n where n varies. + * Create a uniqueName name in the namespace in the form base-n where n varies. * Also truncates very long names that would otherwise break ASM. * * @param base Base of name. Base will be returned if uniqueName. @@ -83,7 +83,7 @@ if (counter != null) { final int count = counter + 1; namespaceDirectory.put(truncatedBase, count); - return truncatedBase + '-' + count; + return truncatedBase + CompilerConstants.ID_FUNCTION_SEPARATOR.symbolName() + count; } } diff --git a/src/jdk/nashorn/internal/parser/Parser.java b/src/jdk/nashorn/internal/parser/Parser.java --- a/src/jdk/nashorn/internal/parser/Parser.java +++ b/src/jdk/nashorn/internal/parser/Parser.java @@ -459,7 +459,7 @@ final FunctionNode parentFunction = lc.getCurrentFunction(); if (parentFunction != null && !parentFunction.isProgram()) { - sb.append(parentFunction.getName()).append('$'); + sb.append(parentFunction.getName()).append(CompilerConstants.NESTED_FUNCTION_SEPARATOR.symbolName()); } assert ident.getName() != null; diff --git a/test/script/basic/JDK-8025515.js b/test/script/basic/JDK-8025515.js --- a/test/script/basic/JDK-8025515.js +++ b/test/script/basic/JDK-8025515.js @@ -61,8 +61,8 @@ var f = (function() { return function() { a.b.c; }; })(); -testMethodName(f, "f$L:62"); +testMethodName(f, "f#L:62"); testMethodName((function() { return function() { return a.b.c; }; -})(), "L:66$L:67"); +})(), "L:66#L:67"); diff --git a/test/script/basic/JDK-8156896.js b/test/script/basic/JDK-8156896.js new file mode 100644 --- /dev/null +++ b/test/script/basic/JDK-8156896.js @@ -0,0 +1,54 @@ +/* + * Copyright (c) 2010, 2013, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/** + * JDK-8156896: Script tack trace should display function names + * + * @test + * @run + */ + +(function() { + return function foo() { + try { + throw new Error(); + } catch(e) { + print(e.stack); + } + } +})()(); + +new Function([], "return function foo() { try { throw new Error(); } catch(e) { print(e.stack); } }")()(); + +var f = (function() { + return function foo() { + try { + throw new Error(); + } catch(e) { + print(e.stack); + } + } +})(); + +f(); + diff --git a/test/script/basic/JDK-8156896.js.EXPECTED b/test/script/basic/JDK-8156896.js.EXPECTED new file mode 100644 --- /dev/null +++ b/test/script/basic/JDK-8156896.js.EXPECTED @@ -0,0 +1,9 @@ +Error + at foo (test.js:4) + at (test.js:1) +Error + at foo (:2) + at (test.js:11) +Error + at foo (test.js:16) + at (test.js:23) From vivin.paliath at gmail.com Fri May 13 18:47:30 2016 From: vivin.paliath at gmail.com (Vivin Suresh Paliath) Date: Fri, 13 May 2016 11:47:30 -0700 Subject: [PATCH] 8156896: Script stack trace should display function names In-Reply-To: References: Message-ID: Looks like I missed the paragraph in the contribution guidelines that fixes will be backported from 9 to 8 only after 6 weeks. Also, since this isn't critical, I'm guessing that it won't be backported? On Fri, May 13, 2016 at 11:37 AM, Vivin Suresh Paliath < vivin.paliath at gmail.com> wrote: > This is Hannes' fix backported to jdk8. I see that the original issue has > been closed, so I am not sure if I should be using the same id or not. > > I did try running the tests, but JDK-814421.js fails because there seems > to be some issue with arguments when they are passed along with the shebang > (everything after 19 characters is chopped off). > > I have added a test for 8156896, but I wasn't able to run it because of > the failing test. I had a quick look at the build.xml file but couldn't > tell how the tests in script/basic get run. > > -- > *[vivin.net :: github :: > linkedin ]* > -- *[vivin.net :: github :: linkedin ]* From sundararajan.athijegannathan at oracle.com Mon May 16 15:08:17 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 16 May 2016 20:38:17 +0530 Subject: RFR 8156847: jdk.dynalink package is shown under "Other Packages" section Message-ID: <512b27e4-32b6-4fc7-f6e9-de206896bcd8@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8156847/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8156847 Thanks, -Sundar From james.laskey at oracle.com Mon May 16 15:10:06 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 16 May 2016 12:10:06 -0300 Subject: RFR 8156847: jdk.dynalink package is shown under "Other Packages" section In-Reply-To: <512b27e4-32b6-4fc7-f6e9-de206896bcd8@oracle.com> References: <512b27e4-32b6-4fc7-f6e9-de206896bcd8@oracle.com> Message-ID: +1 > On May 16, 2016, at 12:08 PM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8156847/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8156847 > > Thanks, > > -Sundar > From erik.joelsson at oracle.com Mon May 16 15:25:06 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 16 May 2016 17:25:06 +0200 Subject: RFR 8156847: jdk.dynalink package is shown under "Other Packages" section In-Reply-To: <512b27e4-32b6-4fc7-f6e9-de206896bcd8@oracle.com> References: <512b27e4-32b6-4fc7-f6e9-de206896bcd8@oracle.com> Message-ID: <5739E652.3010206@oracle.com> As a makefile change this looks fine, but I have no clue as to what that line actually means for javadoc. /Erik On 2016-05-16 17:08, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8156847/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8156847 > > Thanks, > > -Sundar > From sundararajan.athijegannathan at oracle.com Mon May 16 15:28:07 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 16 May 2016 20:58:07 +0530 Subject: RFR 8156847: jdk.dynalink package is shown under "Other Packages" section In-Reply-To: <5739E652.3010206@oracle.com> References: <512b27e4-32b6-4fc7-f6e9-de206896bcd8@oracle.com> <5739E652.3010206@oracle.com> Message-ID: <6694f951-89e5-7f3b-73bd-5b28798ede31@oracle.com> The main dynalink API package "jdk.dynalink" was shown in "Other Packages" section! After this fix, all packages are shown under single section. Please see: http://download.java.net/java/jdk9/docs/jdk/api/dynalink/ Thanks, -Sundar On 5/16/2016 8:55 PM, Erik Joelsson wrote: > As a makefile change this looks fine, but I have no clue as to what > that line actually means for javadoc. > > /Erik > > On 2016-05-16 17:08, Sundararajan Athijegannathan wrote: >> Please review http://cr.openjdk.java.net/~sundar/8156847/webrev.00/ for >> https://bugs.openjdk.java.net/browse/JDK-8156847 >> >> Thanks, >> >> -Sundar >> > From erik.joelsson at oracle.com Mon May 16 15:44:51 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 16 May 2016 17:44:51 +0200 Subject: RFR 8156847: jdk.dynalink package is shown under "Other Packages" section In-Reply-To: <6694f951-89e5-7f3b-73bd-5b28798ede31@oracle.com> References: <512b27e4-32b6-4fc7-f6e9-de206896bcd8@oracle.com> <5739E652.3010206@oracle.com> <6694f951-89e5-7f3b-73bd-5b28798ede31@oracle.com> Message-ID: <5739EAF3.90202@oracle.com> Thanks for the link. I'm happy with the change. /Erik On 2016-05-16 17:28, Sundararajan Athijegannathan wrote: > The main dynalink API package "jdk.dynalink" was shown in "Other > Packages" section! After this fix, all packages are shown under single > section. > > Please see: http://download.java.net/java/jdk9/docs/jdk/api/dynalink/ > > Thanks, > -Sundar > > On 5/16/2016 8:55 PM, Erik Joelsson wrote: >> As a makefile change this looks fine, but I have no clue as to what >> that line actually means for javadoc. >> >> /Erik >> >> On 2016-05-16 17:08, Sundararajan Athijegannathan wrote: >>> Please review http://cr.openjdk.java.net/~sundar/8156847/webrev.00/ for >>> https://bugs.openjdk.java.net/browse/JDK-8156847 >>> >>> Thanks, >>> >>> -Sundar >>> From sundararajan.athijegannathan at oracle.com Tue May 17 12:04:28 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 17 May 2016 17:34:28 +0530 Subject: RFR 8154192: Deprivilege java.scripting module Message-ID: <3e1bed67-ae64-00c2-2e99-21af225e2b30@oracle.com> Please review fix for https://bugs.openjdk.java.net/browse/JDK-8154192 java.scripting module is assigned to platform class loader (instead of boot loader). And java.scripting module is given AllPermission [previously it had AllPermission implicitly because of being boot loader code] jdk repo: http://cr.openjdk.java.net/~sundar/8154192/jdk/webrev.00/ top level repo: http://cr.openjdk.java.net/~sundar/8154192/top/webrev.00/ Tests: javax.script API tests, jrunscript, jjs tool tests and nashorn tests. Thanks, -Sundar From james.laskey at oracle.com Tue May 17 12:18:12 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 17 May 2016 09:18:12 -0300 Subject: RFR 8154192: Deprivilege java.scripting module In-Reply-To: <3e1bed67-ae64-00c2-2e99-21af225e2b30@oracle.com> References: <3e1bed67-ae64-00c2-2e99-21af225e2b30@oracle.com> Message-ID: <93DC831E-AC89-4059-82B5-4029A3840EF9@oracle.com> +1 > On May 17, 2016, at 9:04 AM, Sundararajan Athijegannathan wrote: > > Please review fix for https://bugs.openjdk.java.net/browse/JDK-8154192 > > java.scripting module is assigned to platform class loader (instead of > boot loader). And java.scripting module is given AllPermission > [previously it had AllPermission implicitly because of being boot loader > code] > > jdk repo: > > http://cr.openjdk.java.net/~sundar/8154192/jdk/webrev.00/ > > top level repo: > > http://cr.openjdk.java.net/~sundar/8154192/top/webrev.00/ > > Tests: javax.script API tests, jrunscript, jjs tool tests and nashorn tests. > > Thanks, > > -Sundar > From Alan.Bateman at oracle.com Tue May 17 12:24:31 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 17 May 2016 13:24:31 +0100 Subject: RFR 8154192: Deprivilege java.scripting module In-Reply-To: <3e1bed67-ae64-00c2-2e99-21af225e2b30@oracle.com> References: <3e1bed67-ae64-00c2-2e99-21af225e2b30@oracle.com> Message-ID: <573B0D7F.9080907@oracle.com> On 17/05/2016 13:04, Sundararajan Athijegannathan wrote: > Please review fix for https://bugs.openjdk.java.net/browse/JDK-8154192 > > java.scripting module is assigned to platform class loader (instead of > boot loader). And java.scripting module is given AllPermission > [previously it had AllPermission implicitly because of being boot loader > code] > > jdk repo: > > http://cr.openjdk.java.net/~sundar/8154192/jdk/webrev.00/ > > top level repo: > > http://cr.openjdk.java.net/~sundar/8154192/top/webrev.00/ > > Would it be possible to keep the PLATFORM_MODULES sorted? Otherwise it looks okay as a first patch. I think we also need to understand why this module needs AllPermission. From a quick look then it creates the SL with all permissions but the iteration will be restricted by whatever is on the stack so I just wonder if it works as intended. -Alan From sundararajan.athijegannathan at oracle.com Tue May 17 14:53:44 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 17 May 2016 20:23:44 +0530 Subject: JDK9 features In-Reply-To: References: <0af361e3-0ad9-4671-33af-049682b52780@oracle.com> <3adf32e0-2690-1c52-e156-8341f9024d21@oracle.com> Message-ID: Hi, Filed a bug: https://bugs.openjdk.java.net/browse/JDK-8157160 Thanks, -Sundar On 5/13/2016 8:16 PM, Eric Pederson wrote: > Hi Sundar - > > It would be helpful for sure. We use JSON for serialization and > debugging a lot. Also if it worked it could simplify our > custom ScriptObjectMirror -> native object conversion logic from 30 > lines down to JSON.parse(JSON.stringify(scriptObjMirror)) :). > > Besides the JSON stuff our biggest problem has been > ScriptObjectMirrors being treated like regular objects and passed down > call chains and then either throwing exceptions or silently failing > and it's hard to figure out why. Junior developers get completely > baffled. We have solved the problem with the commonjs/require loading > pattern on the script loading side and the proxy pattern on the Java > calling side. It would be nice to have official solutions for these > but it's not urgent. It might be something worth adding to the > documentation. > > Thanks, > > > > -- Eric > > On Fri, May 13, 2016 at 12:30 AM, Sundararajan Athijegannathan > > wrote: > > Hi Eric, > > That commonjs/require loading pattern is not bad [wrapping eval'ed > code inside a function]. If your loaded scripts are (somewhat) > well-behaved, it does solve the problem of global namespace pollution. > > Yes, ScriptObjectMirrors are not uniformly treated like > ScriptObject everywhere. But, I'm not sure how far we can fix > that :( Is JSON handling (w.r.t ScriptObjectMirror) your main pain > point? We *may* be able to address that. > > Thanks, > > -Sundar > > > On 5/12/2016 11:10 PM, Eric Pederson wrote: >> Hi Sundar: >> >> 1. I investigated loadWithNewGlobal because it looked promising >> for this use case. Say you use loadWithNewGlobal to load a >> function. If you call the loaded function and it returns an >> object or array the caller gets a ScriptObjectMirror. The >> problems with a ScriptObjectMirror "object" are: >> >> * Cannot call Object methods like keys or getOwnPropertyNames. >> You get an exception: TypeError: cannot call undefined. To >> iterate over the properties you must use a for in loop. >> * Cannot convert ScriptObjectMirror to JSON using >> JSON.stringify. It returns undefined. >> >> If the function loaded with loadWithNewGlobal returns an array >> then things are better. Interestingly you can call most Array >> methods (like forEach and map) on a ScriptObjectMirror "array". >> But JSON.stringify also returns undefined. >> >> I did find one issue with an array returned by a >> loadWithNewGlobal loaded function - calling sort with a >> comparator. For example, if the loaded function returned >> testArray, a ScriptObjectMirror "array": >> >> *var **/sorted /*= */testArray/*.sort(*function*(a, b) { >> >> *return *a - b; }); >> >> >> >> throws an exception_: _TypeError: function(a, b) { return a - >> b; } is not a function. >> >> >> These were the same "mutant" issues that we also saw with >> JSObjects returned by Java methods. >> >> >> The hack that we are using now to load code without effecting the >> global namespace is the same one discussed in this thread: >> >> http://thread.gmane.org/gmane.comp.java.openjdk.nashorn.devel/1722. >> >> >> The code that we are using is copied/adapted from Vertx (thanks, >> Tim!): >> >> >> function loadEval(path) { >> >> *var *dir = *new **/File/*(path).getParent(); >> >> *var *body = /readFile/(path); >> >> *var *moduleFunc = >> >> *"function(exports, module, require, __filename, >> __dirname){" *+ body + *"**\n**}**\n**//# sourceURL=" *+ path; >> >> >> *try {* >> >> *var *func = eval(moduleFunc); >> >> } *catch *(ex) { >> >> *if *(ex *instanceof **SyntaxError*) { >> >> /// WARNING! Large pile of Yak hair ahead! >> / >> >> / /*var *ne = ex.nashornException; >> >> *var *cause = ne.cause; >> >> *var *msg = cause.message.replace(*""*, file); >> >> *var *lineNumber = cause.*lineNumber;* >> >> console.log(*"ERROR: " *+ msg + *" in file " *+ file >> + *" at line " *+ lineNumber); >> } >> >> *throw *ex; >> } >> >> *var *module = { *exports*: {} }; >> >> func(module.*exports*, module, require, path, dir); >> >> *return *module.*exports*; >> >> } >> >> >> This seems like a hack to me - but I'm coming from the Java world >> so this may be par for the course in Javascript-land :) Hack or >> no, it is the best of both worlds: it does not change the global >> namespace, yet the code that it returns lives in the global >> context, so if you call a loaded function it will return a native >> object, not a ScriptObjectMirror. >> >> >> We'd like to have a built-in equivalent of this >> loadEvalfunction. It doesn't need to use those specific >> arguments (export, module, etc), but you must be able to pass >> arguments in to provide a context to the loaded code. >> >> >> Alternatively if you could make ScriptObjectMirrors 100% >> compatible with native objects that would work too. Then we >> could use loadWithNewGlobal. >> >> >> 2. The problem that we are having with objects returned by Java >> methods is the same as what I described above because the >> returned JSObjects are seen as ScriptObjectMirrors by the calling >> Javascript code. >> >> >> What we are doing now is wrapping each Java object with a >> Javascript proxy. When you call the proxy it calls the >> corresponding Java method, then converts the returned >> ScriptObjectMirrorinto a native JS object using a custom >> conversion function. >> >> >> What would be nice for this use case is a standard function to >> convert ScriptObjectMirrors to native JS objects (what I was >> calling asJSONCompatible below). Or if ScriptObjectMirrors were >> 100% compatible that would be even better - we could get rid of >> our JS proxy objects. >> >> >> I'm happy to file some enhancement requests. Though it seems >> like the bug trackers are read-only to the general public though, >> how would I get access? >> >> >> Thanks, >> >> >> >> -- Eric >> >> On Thu, May 12, 2016 at 12:36 AM, Sundararajan Athijegannathan >> > > wrote: >> >> Hi, >> >> Thanks for your comments! >> >> Making comments on forthcoming JDK releases is hard :) >> Whatever I'm >> saying now, may not happen - the usual disclaimer applies. >> >> No, we expect that only a subset of ES6 features will be >> implemented for >> Java 9. >> >> 1. On loading definitions without changing global namespace: >> you meant >> current global namespace? loadWithNewGlobal creates a new >> global and >> loads definitions into that. >> >> Would that be useful for you? or anything else? Which hack you're >> referring to? Please file an enhancement with your requirements. >> >> 2. on JSON: Again, will you please provide a simple test case >> and/or >> file an enhancement with requirements? >> >> Thanks, >> -Sundar >> >> On 5/12/2016 12:56 AM, Eric Pederson wrote: >> > I've been noticing the Java 9 ES6 features tweeted by >> @sundararajan_a >> > . Looks awesome! Will >> there be full >> > ES6 support in Java 9? >> > >> > There are a couple of other things we would love to see in >> the updated >> > Nashorn: >> > >> > 1. We've been using the same hack that you recommended to >> Tim Fox for >> > loading functions without changing the global namespace - >> the Avatar/js >> > CommonJS/require hack. It would be great if this was >> supported natively in >> > Nashorn via a new loadXXX(). >> > >> > 2. It would be also be great to have the inverse of >> asJSONCompatible for a) >> > JSObjects returned by Java code and b) objects from other >> scopes. Our name >> > for ScriptObjectMirrors in Javascript code is "mutant >> objects": they look >> > like regular JS objects but they are missing most of their >> DNA, and you >> > don't realize until you get an exception or silent failure >> somewhere down >> > the call chain where it's difficult to figure out why :) >> > >> > Anyway, the upcoming stuff looks great! >> > >> > Thanks, >> > >> > -- Eric >> >> > > From ericacm at gmail.com Tue May 17 16:47:53 2016 From: ericacm at gmail.com (Eric Pederson) Date: Tue, 17 May 2016 12:47:53 -0400 Subject: JDK9 features In-Reply-To: References: <0af361e3-0ad9-4671-33af-049682b52780@oracle.com> <3adf32e0-2690-1c52-e156-8341f9024d21@oracle.com> Message-ID: Thanks! On Tuesday, May 17, 2016, Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > Hi, > > Filed a bug: https://bugs.openjdk.java.net/browse/JDK-8157160 > > Thanks, > > -Sundar > > On 5/13/2016 8:16 PM, Eric Pederson wrote: > > Hi Sundar - > > It would be helpful for sure. We use JSON for serialization and debugging > a lot. Also if it worked it could simplify our custom ScriptObjectMirror > -> native object conversion logic from 30 lines down to > JSON.parse(JSON.stringify(scriptObjMirror)) :). > > Besides the JSON stuff our biggest problem has been ScriptObjectMirrors > being treated like regular objects and passed down call chains and then > either throwing exceptions or silently failing and it's hard to figure out > why. Junior developers get completely baffled. We have solved the problem > with the commonjs/require loading pattern on the script loading side and > the proxy pattern on the Java calling side. It would be nice to have > official solutions for these but it's not urgent. It might be something > worth adding to the documentation. > > Thanks, > > > > -- Eric > > On Fri, May 13, 2016 at 12:30 AM, Sundararajan Athijegannathan < > > sundararajan.athijegannathan at oracle.com > > > wrote: > >> Hi Eric, >> >> That commonjs/require loading pattern is not bad [wrapping eval'ed code >> inside a function]. If your loaded scripts are (somewhat) well-behaved, it >> does solve the problem of global namespace pollution. >> >> Yes, ScriptObjectMirrors are not uniformly treated like ScriptObject >> everywhere. But, I'm not sure how far we can fix that :( Is JSON handling >> (w.r.t ScriptObjectMirror) your main pain point? We *may* be able to >> address that. >> >> Thanks, >> >> -Sundar >> >> On 5/12/2016 11:10 PM, Eric Pederson wrote: >> >> Hi Sundar: >> >> 1. I investigated loadWithNewGlobal because it looked promising for this >> use case. Say you use loadWithNewGlobal to load a function. If you >> call the loaded function and it returns an object or array the caller gets >> a ScriptObjectMirror. The problems with a ScriptObjectMirror "object" >> are: >> >> - Cannot call Object methods like keys or getOwnPropertyNames. You >> get an exception: TypeError: cannot call undefined. To iterate over >> the properties you must use a for in loop. >> - Cannot convert ScriptObjectMirror to JSON using JSON.stringify. It >> returns undefined. >> >> If the function loaded with loadWithNewGlobal returns an array then >> things are better. Interestingly you can call most Array methods (like >> forEach and map) on a ScriptObjectMirror "array". But JSON.stringify also >> returns undefined. >> >> I did find one issue with an array returned by a loadWithNewGlobal >> loaded function - calling sort with a comparator. For example, if the >> loaded function returned testArray, a ScriptObjectMirror "array": >> >> *var **sorted *= *testArray*.sort(*function*(a, b) { >> >> *return *a - b; >> }); >> >> >> >> throws an exception*: *TypeError: function(a, b) { return a - b; } is >> not a function. >> >> >> These were the same "mutant" issues that we also saw with JSObjects >> returned by Java methods. >> >> >> The hack that we are using now to load code without effecting the global >> namespace is the same one discussed in this thread: >> >> >> http://thread.gmane.org/gmane.comp.java.openjdk.nashorn.devel/1722. >> >> >> The code that we are using is copied/adapted from Vertx (thanks, Tim!): >> >> >> function loadEval(path) { >> >> *var *dir = *new **File*(path).getParent(); >> >> *var *body = *readFile*(path); >> >> *var *moduleFunc = >> >> *"function(exports, module, require, __filename, __dirname){" *+ >> body + *"**\n**}**\n**//# sourceURL=" *+ path; >> >> >> *try {* >> >> *var *func = eval(moduleFunc); >> >> } *catch *(ex) { >> >> *if *(ex *instanceof **SyntaxError*) { >> >> >> *// WARNING! Large pile of Yak hair ahead! * >> >> *var *ne = ex.nashornException; >> >> *var *cause = ne.cause; >> >> *var *msg = cause.message.replace(*""*, file); >> >> *var *lineNumber = cause.*lineNumber;* >> >> console.log(*"ERROR: " *+ msg + *" in file " *+ file + *" at >> line " *+ lineNumber); >> } >> >> *throw *ex; >> } >> >> *var *module = { *exports*: {} }; >> >> func(module.*exports*, module, require, path, dir); >> >> *return *module.*exports*; >> >> } >> >> >> This seems like a hack to me - but I'm coming from the Java world so this >> may be par for the course in Javascript-land :) Hack or no, it is the >> best of both worlds: it does not change the global namespace, yet the code >> that it returns lives in the global context, so if you call a loaded >> function it will return a native object, not a ScriptObjectMirror. >> >> >> We'd like to have a built-in equivalent of this loadEval function. It >> doesn't need to use those specific arguments (export, module, etc), but >> you must be able to pass arguments in to provide a context to the loaded >> code. >> >> >> Alternatively if you could make ScriptObjectMirrors 100% compatible with >> native objects that would work too. Then we could use loadWithNewGlobal. >> >> >> 2. The problem that we are having with objects returned by Java methods >> is the same as what I described above because the returned JSObjects are >> seen as ScriptObjectMirrors by the calling Javascript code. >> >> >> What we are doing now is wrapping each Java object with a Javascript >> proxy. When you call the proxy it calls the corresponding Java method, >> then converts the returned ScriptObjectMirror into a native JS object >> using a custom conversion function. >> >> >> What would be nice for this use case is a standard function to convert >> ScriptObjectMirrors to native JS objects (what I was calling asJSONCompatible >> below). Or if ScriptObjectMirrors were 100% compatible that would be >> even better - we could get rid of our JS proxy objects. >> >> >> I'm happy to file some enhancement requests. Though it seems like the >> bug trackers are read-only to the general public though, how would I get >> access? >> >> >> Thanks, >> >> >> -- Eric >> >> On Thu, May 12, 2016 at 12:36 AM, Sundararajan Athijegannathan < >> sundararajan.athijegannathan at oracle.com >> >> > wrote: >> >>> Hi, >>> >>> Thanks for your comments! >>> >>> Making comments on forthcoming JDK releases is hard :) Whatever I'm >>> saying now, may not happen - the usual disclaimer applies. >>> >>> No, we expect that only a subset of ES6 features will be implemented for >>> Java 9. >>> >>> 1. On loading definitions without changing global namespace: you meant >>> current global namespace? loadWithNewGlobal creates a new global and >>> loads definitions into that. >>> >>> Would that be useful for you? or anything else? Which hack you're >>> referring to? Please file an enhancement with your requirements. >>> >>> 2. on JSON: Again, will you please provide a simple test case and/or >>> file an enhancement with requirements? >>> >>> Thanks, >>> -Sundar >>> >>> On 5/12/2016 12:56 AM, Eric Pederson wrote: >>> > I've been noticing the Java 9 ES6 features tweeted by @sundararajan_a >>> > . Looks awesome! Will there be >>> full >>> > ES6 support in Java 9? >>> > >>> > There are a couple of other things we would love to see in the updated >>> > Nashorn: >>> > >>> > 1. We've been using the same hack that you recommended to Tim Fox for >>> > loading functions without changing the global namespace - the Avatar/js >>> > CommonJS/require hack. It would be great if this was supported >>> natively in >>> > Nashorn via a new loadXXX(). >>> > >>> > 2. It would be also be great to have the inverse of asJSONCompatible >>> for a) >>> > JSObjects returned by Java code and b) objects from other scopes. Our >>> name >>> > for ScriptObjectMirrors in Javascript code is "mutant objects": they >>> look >>> > like regular JS objects but they are missing most of their DNA, and you >>> > don't realize until you get an exception or silent failure somewhere >>> down >>> > the call chain where it's difficult to figure out why :) >>> > >>> > Anyway, the upcoming stuff looks great! >>> > >>> > Thanks, >>> > >>> > -- Eric >>> >>> >> >> > > -- Sent from Gmail Mobile From sundararajan.athijegannathan at oracle.com Wed May 18 06:50:13 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 18 May 2016 12:20:13 +0530 Subject: RFR 8157160: JSON.stringify does not work on ScriptObjectMirror objects Message-ID: <91dd0945-69b1-23fe-a1a0-0a9824d67b42@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8157160/ for https://bugs.openjdk.java.net/browse/JDK-8157160 Thanks, -Sundar From michael.haupt at oracle.com Wed May 18 07:43:26 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 18 May 2016 09:43:26 +0200 Subject: RFR 8157160: JSON.stringify does not work on ScriptObjectMirror objects In-Reply-To: <91dd0945-69b1-23fe-a1a0-0a9824d67b42@oracle.com> References: <91dd0945-69b1-23fe-a1a0-0a9824d67b42@oracle.com> Message-ID: <9863675B-BBB6-49FC-8073-34177FEC7D50@oracle.com> Hi Sundar, lower-case thumbs up. Best, Michael > Am 18.05.2016 um 08:50 schrieb Sundararajan Athijegannathan : > > Please review http://cr.openjdk.java.net/~sundar/8157160/ for > https://bugs.openjdk.java.net/browse/JDK-8157160 > > Thanks, > > -Sundar > -- 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 sundararajan.athijegannathan at oracle.com Wed May 18 07:55:01 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 18 May 2016 13:25:01 +0530 Subject: RFR 8154192: Deprivilege java.scripting module In-Reply-To: <573B0D7F.9080907@oracle.com> References: <3e1bed67-ae64-00c2-2e99-21af225e2b30@oracle.com> <573B0D7F.9080907@oracle.com> Message-ID: Please review the updated webrevs. * Fixed Modules.gmk for order of modules: http://cr.openjdk.java.net/~sundar/8154192/top/webrev.01/ * From quick reading of j.u.ServiceLoader: AccessControlContext is captured in ServiceLoader constructor & used for iteration (RestrictedIterator). So, ScriptEngineManager calling only ServiceLoader constructor inside doPrivileged block seems fine. Also, I turned ProviderTest javax.script API test to use security manager - this tests loads a dummy script engine from a jar file in classpath. This test passes with security manager on. http://cr.openjdk.java.net/~sundar/8154192/jdk/webrev.01/ Yes, we can still revisit AllPermission for java.scripting module in a future change. Thanks, -Sundar On 5/17/2016 5:54 PM, Alan Bateman wrote: > On 17/05/2016 13:04, Sundararajan Athijegannathan wrote: >> Please review fix for https://bugs.openjdk.java.net/browse/JDK-8154192 >> >> java.scripting module is assigned to platform class loader (instead of >> boot loader). And java.scripting module is given AllPermission >> [previously it had AllPermission implicitly because of being boot loader >> code] >> >> jdk repo: >> >> http://cr.openjdk.java.net/~sundar/8154192/jdk/webrev.00/ >> >> top level repo: >> >> http://cr.openjdk.java.net/~sundar/8154192/top/webrev.00/ >> >> > Would it be possible to keep the PLATFORM_MODULES sorted? Otherwise it > looks okay as a first patch. I think we also need to understand why > this module needs AllPermission. From a quick look then it creates the > SL with all permissions but the iteration will be restricted by > whatever is on the stack so I just wonder if it works as intended. > > -Alan From hannes.wallnoefer at oracle.com Wed May 18 08:31:01 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 18 May 2016 10:31:01 +0200 Subject: RFR 8157160: JSON.stringify does not work on ScriptObjectMirror objects In-Reply-To: <91dd0945-69b1-23fe-a1a0-0a9824d67b42@oracle.com> References: <91dd0945-69b1-23fe-a1a0-0a9824d67b42@oracle.com> Message-ID: <573C2845.1070809@oracle.com> +1 Am 2016-05-18 um 08:50 schrieb Sundararajan Athijegannathan: > Please review http://cr.openjdk.java.net/~sundar/8157160/ for > https://bugs.openjdk.java.net/browse/JDK-8157160 > > Thanks, > > -Sundar > From Alan.Bateman at oracle.com Wed May 18 08:47:32 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 May 2016 09:47:32 +0100 Subject: RFR 8154192: Deprivilege java.scripting module In-Reply-To: References: <3e1bed67-ae64-00c2-2e99-21af225e2b30@oracle.com> <573B0D7F.9080907@oracle.com> Message-ID: <573C2C24.6000005@oracle.com> On 18/05/2016 08:55, Sundararajan Athijegannathan wrote: > Please review the updated webrevs. > > * Fixed Modules.gmk for order of modules: > > http://cr.openjdk.java.net/~sundar/8154192/top/webrev.01/ > > * From quick reading of j.u.ServiceLoader: AccessControlContext is > captured in ServiceLoader constructor & used for iteration > (RestrictedIterator). So, ScriptEngineManager calling only ServiceLoader > constructor inside doPrivileged block seems fine. Also, I turned > ProviderTest javax.script API test to use security manager - this tests > loads a dummy script engine from a jar file in classpath. This test > passes with security manager on. > > http://cr.openjdk.java.net/~sundar/8154192/jdk/webrev.01/ > > Yes, we can still revisit AllPermission for java.scripting module in a > future change. > One suggestion is to run ProviderTest twice, both with and without SM. The rest looks okay. -Alan. From sundararajan.athijegannathan at oracle.com Wed May 18 08:53:58 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 18 May 2016 14:23:58 +0530 Subject: RFR 8154192: Deprivilege java.scripting module In-Reply-To: <573C2C24.6000005@oracle.com> References: <3e1bed67-ae64-00c2-2e99-21af225e2b30@oracle.com> <573B0D7F.9080907@oracle.com> <573C2C24.6000005@oracle.com> Message-ID: <4f9e0afd-a268-fe11-4478-16335f38725d@oracle.com> Thanks. I'll make that change and push it. -Sundar On 5/18/2016 2:17 PM, Alan Bateman wrote: > On 18/05/2016 08:55, Sundararajan Athijegannathan wrote: >> Please review the updated webrevs. >> >> * Fixed Modules.gmk for order of modules: >> >> http://cr.openjdk.java.net/~sundar/8154192/top/webrev.01/ >> >> * From quick reading of j.u.ServiceLoader: AccessControlContext is >> captured in ServiceLoader constructor & used for iteration >> (RestrictedIterator). So, ScriptEngineManager calling only ServiceLoader >> constructor inside doPrivileged block seems fine. Also, I turned >> ProviderTest javax.script API test to use security manager - this tests >> loads a dummy script engine from a jar file in classpath. This test >> passes with security manager on. >> >> http://cr.openjdk.java.net/~sundar/8154192/jdk/webrev.01/ >> >> Yes, we can still revisit AllPermission for java.scripting module in a >> future change. >> > One suggestion is to run ProviderTest twice, both with and without SM. > The rest looks okay. > > -Alan. From michael.haupt at oracle.com Wed May 18 09:25:44 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 18 May 2016 11:25:44 +0200 Subject: RFR(S): 8157225: adopt method handle for array length getter in BeanLinker Message-ID: Dear all, please review this change. RFE: https://bugs.openjdk.java.net/browse/JDK-8157225 Webrev: http://cr.openjdk.java.net/~mhaupt/8157225/webrev.00/ Thanks, Michael -- 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 sundararajan.athijegannathan at oracle.com Wed May 18 09:28:04 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 18 May 2016 14:58:04 +0530 Subject: RFR(S): 8157225: adopt method handle for array length getter in BeanLinker In-Reply-To: References: Message-ID: +1 Nice! -Sundar On 5/18/2016 2:55 PM, Michael Haupt wrote: > Dear all, > > please review this change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8157225 > Webrev: http://cr.openjdk.java.net/~mhaupt/8157225/webrev.00/ > > Thanks, > > Michael > From hannes.wallnoefer at oracle.com Wed May 18 09:28:42 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 18 May 2016 11:28:42 +0200 Subject: RFR(S): 8157225: adopt method handle for array length getter in BeanLinker In-Reply-To: References: Message-ID: <573C35CA.7030607@oracle.com> +1 Am 2016-05-18 um 11:25 schrieb Michael Haupt: > Dear all, > > please review this change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8157225 > Webrev: http://cr.openjdk.java.net/~mhaupt/8157225/webrev.00/ > > Thanks, > > Michael > From sundararajan.athijegannathan at oracle.com Wed May 18 12:01:22 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 18 May 2016 17:31:22 +0530 Subject: RFR 8157241: Remove javac warnings of Nashorn "ant clean test" Message-ID: <2e9eb8e7-ff25-fd58-94c4-d1287582627f@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8157241/ for https://bugs.openjdk.java.net/browse/JDK-8157241 Thanks, -Sundar From michael.haupt at oracle.com Wed May 18 12:32:10 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 18 May 2016 14:32:10 +0200 Subject: RFR 8157241: Remove javac warnings of Nashorn "ant clean test" In-Reply-To: <2e9eb8e7-ff25-fd58-94c4-d1287582627f@oracle.com> References: <2e9eb8e7-ff25-fd58-94c4-d1287582627f@oracle.com> Message-ID: Hi Sundar, lower-case thumbs up. Best, Michael > Am 18.05.2016 um 14:01 schrieb Sundararajan Athijegannathan : > > Please review http://cr.openjdk.java.net/~sundar/8157241/ for > https://bugs.openjdk.java.net/browse/JDK-8157241 > > Thanks, > > -Sundar > -- 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 Wed May 18 14:11:16 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 18 May 2016 16:11:16 +0200 Subject: RFR(S): 8157225: adopt method handle for array length getter in BeanLinker In-Reply-To: References: Message-ID: <66A4673B-FF2C-4DD2-9C6D-2625487C9059@gmail.com> There?s a bit of an issue with this. Namely, the old GET_ARRAY_LENGTH being the unreflection of j.l.reflect.Array.getLength() worked for any array type, so it was always accompanied with ValidationType.IS_ARRAY. I believe this is wrong now and can cause ClassCastException at runtime (I say ?believe? as I can?t currently build jdk 9 so can?t confirm). This could be caught by a test that handles two arrays of different types in the same call site, e.g. with Nashorn: var intArray = Java.type(?int[]?) var doubleArray = Java.type(?double[]?) var arrs = [new intArray(0), new doubleArray(0)] for (var i in arrs) arrs[i].length Since the MethodHandles.arrayLength is typed to the concrete array class, it should be used with ValidationType.EXACT_CLASS. This will obviously cause call sites taking length of different kinds of arrays more polymorphic? FWIW, the IS_ARRAY validation type is probably obsolete now as it was only used for array length getters anyway. The polymorphism could be somewhat alleviated by having stable validation for all arrays of reference types. Maybe have one MethodHandles.arrayLength(Object[].class) handle cached to use with all arrays of reference types, and use a Validator(Object[].class, ValidationType.INSTANCE_OF) with it. Then you?d have stable linkage that can take the length of any reference-typed array, but you?d still trigger relinking for primitive-typed arrays. Attila. > On 18 May 2016, at 11:25, Michael Haupt wrote: > > Dear all, > > please review this change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8157225 > Webrev: http://cr.openjdk.java.net/~mhaupt/8157225/webrev.00/ > > Thanks, > > Michael > > -- > > > 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 May 18 14:35:23 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 18 May 2016 16:35:23 +0200 Subject: RFR 8157241: Remove javac warnings of Nashorn "ant clean test" In-Reply-To: <2e9eb8e7-ff25-fd58-94c4-d1287582627f@oracle.com> References: <2e9eb8e7-ff25-fd58-94c4-d1287582627f@oracle.com> Message-ID: <573C7DAB.8090503@oracle.com> +1 Am 2016-05-18 um 14:01 schrieb Sundararajan Athijegannathan: > Please review http://cr.openjdk.java.net/~sundar/8157241/ for > https://bugs.openjdk.java.net/browse/JDK-8157241 > > Thanks, > > -Sundar > From michael.haupt at oracle.com Wed May 18 15:23:43 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 18 May 2016 17:23:43 +0200 Subject: RFR(S): 8157225: adopt method handle for array length getter in BeanLinker In-Reply-To: <66A4673B-FF2C-4DD2-9C6D-2625487C9059@gmail.com> References: <66A4673B-FF2C-4DD2-9C6D-2625487C9059@gmail.com> Message-ID: <10C28202-1B67-4E30-804E-16CF785C94B7@oracle.com> Hi Attila, thanks for your comments. > Am 18.05.2016 um 16:11 schrieb Attila Szegedi : > There?s a bit of an issue with this. Namely, the old GET_ARRAY_LENGTH being the unreflection of j.l.reflect.Array.getLength() worked for any array type, so it was always accompanied with ValidationType.IS_ARRAY. I believe this is wrong now and can cause ClassCastException at runtime (I say ?believe? as I can?t currently build jdk 9 so can?t confirm). This could be caught by a test that handles two arrays of different types in the same call site, e.g. with Nashorn: > > var intArray = Java.type(?int[]?) > var doubleArray = Java.type(?double[]?) > var arrs = [new intArray(0), new doubleArray(0)] > for (var i in arrs) arrs[i].length Confirmed: $ jjs jjs> var intArray = Java.type("int[]") jjs> var doubleArray = Java.type("double[]") jjs> var arrs = [new intArray(0), new doubleArray(0)] jjs> for (var i in arrs) arrs[i].length java.lang.ClassCastException: Cannot cast [D to [I > Since the MethodHandles.arrayLength is typed to the concrete array class, it should be used with ValidationType.EXACT_CLASS. Also confirmed: $ jjs jjs> var intArray = Java.type("int[]") jjs> var doubleArray = Java.type("double[]") jjs> var arrs = [new intArray(0), new doubleArray(0)] jjs> for (var i in arrs) arrs[i].length 0 > This will obviously cause call sites taking length of different kinds of arrays more polymorphic? FWIW, the IS_ARRAY validation type is probably obsolete now as it was only used for array length getters anyway. Yes; there are two uses of IS_ARRAY that can be replaced with EXACT_CLASS ... > The polymorphism could be somewhat alleviated by having stable validation for all arrays of reference types. Maybe have one MethodHandles.arrayLength(Object[].class) handle cached to use with all arrays of reference types, and use a Validator(Object[].class, ValidationType.INSTANCE_OF) with it. Then you?d have stable linkage that can take the length of any reference-typed array, but you?d still trigger relinking for primitive-typed arrays. ... but shouldn't, right. I've filed a bug to adopt the quick fix with EXACT_CLASS [1], and another to deal with the relinking problem [2]. The solution you suggest should be possible; maybe the IS_ARRAY abstraction can be reused for this in a way that avoids relinking for primitive arrays by having a PIC-like structure. Best, Michael [1] https://bugs.openjdk.java.net/browse/JDK-8157250 [2] https://bugs.openjdk.java.net/browse/JDK-8157251 -- 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 Wed May 18 15:31:40 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 18 May 2016 17:31:40 +0200 Subject: RFR(S): 8157250: BeanLinker assumes fixed array type linkage Message-ID: <74F3F52F-C515-4097-B30B-3DA630082BE1@oracle.com> Dear all, please review this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8157250 Webrev: http://cr.openjdk.java.net/~mhaupt/8157250/webrev.00/ Thanks, 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 szegedia at gmail.com Wed May 18 15:34:50 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 18 May 2016 17:34:50 +0200 Subject: RFR(S): 8157250: BeanLinker assumes fixed array type linkage In-Reply-To: <74F3F52F-C515-4097-B30B-3DA630082BE1@oracle.com> References: <74F3F52F-C515-4097-B30B-3DA630082BE1@oracle.com> Message-ID: <345CAF60-DE8C-4796-BB9F-748C5E1EF39D@gmail.com> +1 > On 18 May 2016, at 17:31, Michael Haupt wrote: > > Dear all, > > please review this fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8157250 > Webrev: http://cr.openjdk.java.net/~mhaupt/8157250/webrev.00/ > > Thanks, > > 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 sundararajan.athijegannathan at oracle.com Wed May 18 15:35:54 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 18 May 2016 21:05:54 +0530 Subject: RFR(S): 8157250: BeanLinker assumes fixed array type linkage In-Reply-To: <345CAF60-DE8C-4796-BB9F-748C5E1EF39D@gmail.com> References: <74F3F52F-C515-4097-B30B-3DA630082BE1@oracle.com> <345CAF60-DE8C-4796-BB9F-748C5E1EF39D@gmail.com> Message-ID: +1 On 5/18/2016 9:04 PM, Attila Szegedi wrote: > +1 > >> On 18 May 2016, at 17:31, Michael Haupt wrote: >> >> Dear all, >> >> please review this fix. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8157250 >> Webrev: http://cr.openjdk.java.net/~mhaupt/8157250/webrev.00/ >> >> Thanks, >> >> 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 mandy.chung at oracle.com Wed May 18 16:11:54 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 18 May 2016 09:11:54 -0700 Subject: RFR 8154192: Deprivilege java.scripting module In-Reply-To: References: <3e1bed67-ae64-00c2-2e99-21af225e2b30@oracle.com> <573B0D7F.9080907@oracle.com> Message-ID: > On May 18, 2016, at 12:55 AM, Sundararajan Athijegannathan wrote: > > Please review the updated webrevs. > > * Fixed Modules.gmk for order of modules: > > http://cr.openjdk.java.net/~sundar/8154192/top/webrev.01/ > > * From quick reading of j.u.ServiceLoader: AccessControlContext is > captured in ServiceLoader constructor & used for iteration > (RestrictedIterator). So, ScriptEngineManager calling only ServiceLoader > constructor inside doPrivileged block seems fine. Also, I turned > ProviderTest javax.script API test to use security manager - this tests > loads a dummy script engine from a jar file in classpath. This test > passes with security manager on. > > http://cr.openjdk.java.net/~sundar/8154192/jdk/webrev.01/ > > Yes, we can still revisit AllPermission for java.scripting module in a > future change. +1 I saw you updated the test to run with and without SM which is good. Mandy From hannesw at gmail.com Wed May 18 16:36:54 2016 From: hannesw at gmail.com (=?UTF-8?Q?Hannes_Walln=c3=b6fer?=) Date: Wed, 18 May 2016 18:36:54 +0200 Subject: Review request for JDK-8066229: Fuzzing bug: Can't find scope depth Message-ID: <573C9A26.50307@gmail.com> Please review JDK-8066229: Fuzzing bug: Can't find scope depth http://cr.openjdk.java.net/~hannesw/8066229/webrev/ This adds a test case for bug that is already fixed. It also removes the EXPECTED file added in the previous commit (JDK-8157250). Thanks, Hannes From sundararajan.athijegannathan at oracle.com Wed May 18 16:42:04 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 18 May 2016 22:12:04 +0530 Subject: Review request for JDK-8066229: Fuzzing bug: Can't find scope depth In-Reply-To: <573C9A26.50307@gmail.com> References: <573C9A26.50307@gmail.com> Message-ID: <89ce3669-cef7-5442-85fb-aa35635810d7@oracle.com> +1 On 5/18/2016 10:06 PM, Hannes Walln?fer wrote: > Please review JDK-8066229: Fuzzing bug: Can't find scope depth > > http://cr.openjdk.java.net/~hannesw/8066229/webrev/ > > This adds a test case for bug that is already fixed. It also removes > the EXPECTED file added in the previous commit (JDK-8157250). > > Thanks, > Hannes From hannes.wallnoefer at oracle.com Wed May 18 17:50:00 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 18 May 2016 19:50:00 +0200 Subject: Review request for JDK-8157263: Octane svn repository no longer exists Message-ID: <573CAB48.60208@oracle.com> Please review JDK-8157263: Octane svn repository no longer exists: http://cr.openjdk.java.net/~hannesw/8157263/webrev/ Thanks, Hannes From sundararajan.athijegannathan at oracle.com Wed May 18 18:11:05 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 18 May 2016 23:41:05 +0530 Subject: Review request for JDK-8157263: Octane svn repository no longer exists In-Reply-To: <573CAB48.60208@oracle.com> References: <573CAB48.60208@oracle.com> Message-ID: <95794cf6-71c8-8197-0985-16cce9a16f6d@oracle.com> +1 On 5/18/2016 11:20 PM, Hannes Wallnoefer wrote: > Please review JDK-8157263: Octane svn repository no longer exists: > > http://cr.openjdk.java.net/~hannesw/8157263/webrev/ > > Thanks, > Hannes From michael.haupt at oracle.com Thu May 19 08:15:33 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 19 May 2016 10:15:33 +0200 Subject: Review request for JDK-8157263: Octane svn repository no longer exists In-Reply-To: <573CAB48.60208@oracle.com> References: <573CAB48.60208@oracle.com> Message-ID: <744E6138-1274-4B70-A827-3E8388D64547@oracle.com> Hi Hannes, lower-case thumbs up. Best, Michael > Am 18.05.2016 um 19:50 schrieb Hannes Wallnoefer : > > Please review JDK-8157263: Octane svn repository no longer exists: > > http://cr.openjdk.java.net/~hannesw/8157263/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 michael.haupt at oracle.com Thu May 19 08:15:40 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 19 May 2016 10:15:40 +0200 Subject: Review request for JDK-8066229: Fuzzing bug: Can't find scope depth In-Reply-To: <573C9A26.50307@gmail.com> References: <573C9A26.50307@gmail.com> Message-ID: <4D2EC40D-C0BB-4A16-9CB9-7159A9CE72CA@oracle.com> Hi Hannes, lower-case thumbs up. Best, Michael > Am 18.05.2016 um 18:36 schrieb Hannes Walln?fer : > > Please review JDK-8066229: Fuzzing bug: Can't find scope depth > > http://cr.openjdk.java.net/~hannesw/8066229/webrev/ > > This adds a test case for bug that is already fixed. It also removes the EXPECTED file added in the previous commit (JDK-8157250). > > Thanks, > Hannes -- 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 Thu May 19 11:35:07 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Thu, 19 May 2016 13:35:07 +0200 Subject: Review request for JDK-8066229: Fuzzing bug: Can't find scope depth In-Reply-To: <573C9A26.50307@gmail.com> References: <573C9A26.50307@gmail.com> Message-ID: <679A1B2E-8929-44DD-A002-59D20DD5B141@lagergren.net> +1 > On 18 May 2016, at 18:36, Hannes Walln?fer wrote: > > Please review JDK-8066229: Fuzzing bug: Can't find scope depth > > http://cr.openjdk.java.net/~hannesw/8066229/webrev/ > > This adds a test case for bug that is already fixed. It also removes the EXPECTED file added in the previous commit (JDK-8157250). > > Thanks, > Hannes From marcus at lagergren.net Thu May 19 11:35:25 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Thu, 19 May 2016 13:35:25 +0200 Subject: RFR 8157241: Remove javac warnings of Nashorn "ant clean test" In-Reply-To: <2e9eb8e7-ff25-fd58-94c4-d1287582627f@oracle.com> References: <2e9eb8e7-ff25-fd58-94c4-d1287582627f@oracle.com> Message-ID: <415D3A45-BD5F-4D26-B147-2BF140F8B763@lagergren.net> +1 > On 18 May 2016, at 14:01, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8157241/ for > https://bugs.openjdk.java.net/browse/JDK-8157241 > > Thanks, > > -Sundar > From marcus at lagergren.net Thu May 19 11:36:28 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Thu, 19 May 2016 13:36:28 +0200 Subject: RFR(S): 8157250: BeanLinker assumes fixed array type linkage In-Reply-To: <74F3F52F-C515-4097-B30B-3DA630082BE1@oracle.com> References: <74F3F52F-C515-4097-B30B-3DA630082BE1@oracle.com> Message-ID: <7DE7BDD1-8B35-4208-BAB4-F4B44061DF92@lagergren.net> +1 > On 18 May 2016, at 17:31, Michael Haupt wrote: > > Dear all, > > please review this fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8157250 > Webrev: http://cr.openjdk.java.net/~mhaupt/8157250/webrev.00/ > > Thanks, > > 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 sundararajan.athijegannathan at oracle.com Thu May 19 12:28:20 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 19 May 2016 17:58:20 +0530 Subject: RFR 8157310: jdk.dynalink.linker.support.Lookup should have more checks before adding module read link Message-ID: Please review http://cr.openjdk.java.net/~sundar/8157310/ for https://bugs.openjdk.java.net/browse/JDK-8157310 What is this fix? * When unreflecting caller sensitive methods, dynalink uses specific Lookup of actual caller (instead of publicLookup) - in nashorn's case it's be the Lookup of script class. * Script class may not have read link to the module of the class (of caller sensitive member). If there is any IllegalAccessError, dynalink adds the read link and tries to unreflect again. We don't want unnecessary module link read in such cases. Check has been added whether the package is exported from declaring module. Note that there is no security issue here. Even before the fix, module read edge does not give any capability. unreflect call after adding unnecessary read line would still fail for non-exported package case. There were unnecessary module read links created - which is being avoided now. * Additional "API" in Lookup.java slipped from jigsaw code into jdk9-dev. Those unreflectCallerSensitive and unreflectConstructorCallerSensitive were meant to be 'interim' somehow slipped. Now, only unreflect and unreflectConstructor in Lookup. Caller sensitiveness is hidden in the implementation. These methods were never APIs when dynalink API was created. Thanks, -Sundar From hannes.wallnoefer at oracle.com Thu May 19 14:15:51 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 19 May 2016 16:15:51 +0200 Subject: RFR 8157310: jdk.dynalink.linker.support.Lookup should have more checks before adding module read link In-Reply-To: References: Message-ID: <573DCA97.1010506@oracle.com> +1 Am 2016-05-19 um 14:28 schrieb Sundararajan Athijegannathan: > Please review http://cr.openjdk.java.net/~sundar/8157310/ for > https://bugs.openjdk.java.net/browse/JDK-8157310 > > What is this fix? > > * When unreflecting caller sensitive methods, dynalink uses specific > Lookup of actual caller (instead of publicLookup) - in nashorn's case > it's be the Lookup of script class. > > * Script class may not have read link to the module of the class (of > caller sensitive member). If there is any IllegalAccessError, dynalink > adds the read link and tries to > > unreflect again. We don't want unnecessary module link read in such > cases. Check has been added whether the package is exported from > declaring module. Note that there is no security issue here. Even > before the fix, module read edge does not give any capability. unreflect > call after adding unnecessary read line would still fail for > non-exported package case. There were unnecessary module read links > created - which is being avoided now. > > * Additional "API" in Lookup.java slipped from jigsaw code into > jdk9-dev. Those unreflectCallerSensitive and > unreflectConstructorCallerSensitive were meant to be 'interim' somehow > slipped. Now, only unreflect and unreflectConstructor in Lookup. Caller > sensitiveness is hidden in the implementation. These methods were never > APIs when dynalink API was created. > > Thanks, > > -Sundar > > From szegedia at gmail.com Fri May 20 06:52:12 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 20 May 2016 09:52:12 +0300 Subject: RFR 8157310: jdk.dynalink.linker.support.Lookup should have more checks before adding module read link In-Reply-To: References: Message-ID: <0F1CB1F9-B70C-454C-B104-C08D7D277AB2@gmail.com> +1. Nice work! > On 19 May 2016, at 15:28, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8157310/ for > https://bugs.openjdk.java.net/browse/JDK-8157310 > > What is this fix? > > * When unreflecting caller sensitive methods, dynalink uses specific > Lookup of actual caller (instead of publicLookup) - in nashorn's case > it's be the Lookup of script class. > > * Script class may not have read link to the module of the class (of > caller sensitive member). If there is any IllegalAccessError, dynalink > adds the read link and tries to > > unreflect again. We don't want unnecessary module link read in such > cases. Check has been added whether the package is exported from > declaring module. Note that there is no security issue here. Even > before the fix, module read edge does not give any capability. unreflect > call after adding unnecessary read line would still fail for > non-exported package case. There were unnecessary module read links > created - which is being avoided now. > > * Additional "API" in Lookup.java slipped from jigsaw code into > jdk9-dev. Those unreflectCallerSensitive and > unreflectConstructorCallerSensitive were meant to be 'interim' somehow > slipped. Now, only unreflect and unreflectConstructor in Lookup. Caller > sensitiveness is hidden in the implementation. These methods were never > APIs when dynalink API was created. > > Thanks, > > -Sundar > > From szegedia at gmail.com Fri May 20 06:52:20 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 20 May 2016 09:52:20 +0300 Subject: RFR 8157310: jdk.dynalink.linker.support.Lookup should have more checks before adding module read link In-Reply-To: References: Message-ID: <72F1FC32-5BEB-4296-B940-AAF010D2A951@gmail.com> +1. Nice work! > On 19 May 2016, at 15:28, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8157310/ for > https://bugs.openjdk.java.net/browse/JDK-8157310 > > What is this fix? > > * When unreflecting caller sensitive methods, dynalink uses specific > Lookup of actual caller (instead of publicLookup) - in nashorn's case > it's be the Lookup of script class. > > * Script class may not have read link to the module of the class (of > caller sensitive member). If there is any IllegalAccessError, dynalink > adds the read link and tries to > > unreflect again. We don't want unnecessary module link read in such > cases. Check has been added whether the package is exported from > declaring module. Note that there is no security issue here. Even > before the fix, module read edge does not give any capability. unreflect > call after adding unnecessary read line would still fail for > non-exported package case. There were unnecessary module read links > created - which is being avoided now. > > * Additional "API" in Lookup.java slipped from jigsaw code into > jdk9-dev. Those unreflectCallerSensitive and > unreflectConstructorCallerSensitive were meant to be 'interim' somehow > slipped. Now, only unreflect and unreflectConstructor in Lookup. Caller > sensitiveness is hidden in the implementation. These methods were never > APIs when dynalink API was created. > > Thanks, > > -Sundar > > From sundararajan.athijegannathan at oracle.com Fri May 20 07:12:27 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 20 May 2016 12:42:27 +0530 Subject: RFR 8157310: jdk.dynalink.linker.support.Lookup should have more checks before adding module read link In-Reply-To: <72F1FC32-5BEB-4296-B940-AAF010D2A951@gmail.com> References: <72F1FC32-5BEB-4296-B940-AAF010D2A951@gmail.com> Message-ID: <1d518620-3def-1cfb-6dc4-05a859667ec5@oracle.com> Hi, Thanks for the review. But, I adjusted the change slightly -- moved addModuleRead and caller-sensitive fallback attempt to CallerSensitiveDynamicMethod itself - leaving Lookup as general exception translating version of j.l.invoke.MethodHandle.Lookup. I think this is better caller sensitivity handling moved to specific place and Lookup remains a generic API. http://cr.openjdk.java.net/~sundar/8157310/webrev.01/ Thanks, -Sundar On 5/20/2016 12:22 PM, Attila Szegedi wrote: > +1. Nice work! > >> On 19 May 2016, at 15:28, Sundararajan Athijegannathan wrote: >> >> Please review http://cr.openjdk.java.net/~sundar/8157310/ for >> https://bugs.openjdk.java.net/browse/JDK-8157310 >> >> What is this fix? >> >> * When unreflecting caller sensitive methods, dynalink uses specific >> Lookup of actual caller (instead of publicLookup) - in nashorn's case >> it's be the Lookup of script class. >> >> * Script class may not have read link to the module of the class (of >> caller sensitive member). If there is any IllegalAccessError, dynalink >> adds the read link and tries to >> >> unreflect again. We don't want unnecessary module link read in such >> cases. Check has been added whether the package is exported from >> declaring module. Note that there is no security issue here. Even >> before the fix, module read edge does not give any capability. unreflect >> call after adding unnecessary read line would still fail for >> non-exported package case. There were unnecessary module read links >> created - which is being avoided now. >> >> * Additional "API" in Lookup.java slipped from jigsaw code into >> jdk9-dev. Those unreflectCallerSensitive and >> unreflectConstructorCallerSensitive were meant to be 'interim' somehow >> slipped. Now, only unreflect and unreflectConstructor in Lookup. Caller >> sensitiveness is hidden in the implementation. These methods were never >> APIs when dynalink API was created. >> >> Thanks, >> >> -Sundar >> >> From hannes.wallnoefer at oracle.com Fri May 20 07:38:47 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 20 May 2016 09:38:47 +0200 Subject: RFR 8157310: jdk.dynalink.linker.support.Lookup should have more checks before adding module read link In-Reply-To: <1d518620-3def-1cfb-6dc4-05a859667ec5@oracle.com> References: <72F1FC32-5BEB-4296-B940-AAF010D2A951@gmail.com> <1d518620-3def-1cfb-6dc4-05a859667ec5@oracle.com> Message-ID: <573EBF07.30902@oracle.com> Hi Sundar, I agree methods feel more in their place now. Hannes Am 2016-05-20 um 09:12 schrieb Sundararajan Athijegannathan: > Hi, > > Thanks for the review. But, I adjusted the change slightly -- moved > addModuleRead and caller-sensitive fallback attempt to > CallerSensitiveDynamicMethod itself - leaving Lookup as general > exception translating version of j.l.invoke.MethodHandle.Lookup. > > I think this is better caller sensitivity handling moved to specific > place and Lookup remains a generic API. > > http://cr.openjdk.java.net/~sundar/8157310/webrev.01/ > > Thanks, > > -Sundar > > > On 5/20/2016 12:22 PM, Attila Szegedi wrote: >> +1. Nice work! >> >>> On 19 May 2016, at 15:28, Sundararajan Athijegannathan wrote: >>> >>> Please review http://cr.openjdk.java.net/~sundar/8157310/ for >>> https://bugs.openjdk.java.net/browse/JDK-8157310 >>> >>> What is this fix? >>> >>> * When unreflecting caller sensitive methods, dynalink uses specific >>> Lookup of actual caller (instead of publicLookup) - in nashorn's case >>> it's be the Lookup of script class. >>> >>> * Script class may not have read link to the module of the class (of >>> caller sensitive member). If there is any IllegalAccessError, dynalink >>> adds the read link and tries to >>> >>> unreflect again. We don't want unnecessary module link read in such >>> cases. Check has been added whether the package is exported from >>> declaring module. Note that there is no security issue here. Even >>> before the fix, module read edge does not give any capability. unreflect >>> call after adding unnecessary read line would still fail for >>> non-exported package case. There were unnecessary module read links >>> created - which is being avoided now. >>> >>> * Additional "API" in Lookup.java slipped from jigsaw code into >>> jdk9-dev. Those unreflectCallerSensitive and >>> unreflectConstructorCallerSensitive were meant to be 'interim' somehow >>> slipped. Now, only unreflect and unreflectConstructor in Lookup. Caller >>> sensitiveness is hidden in the implementation. These methods were never >>> APIs when dynalink API was created. >>> >>> Thanks, >>> >>> -Sundar >>> >>> From szegedia at gmail.com Fri May 20 07:41:31 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 20 May 2016 10:41:31 +0300 Subject: RFR 8157310: jdk.dynalink.linker.support.Lookup should have more checks before adding module read link In-Reply-To: <573EBF07.30902@oracle.com> References: <72F1FC32-5BEB-4296-B940-AAF010D2A951@gmail.com> <1d518620-3def-1cfb-6dc4-05a859667ec5@oracle.com> <573EBF07.30902@oracle.com> Message-ID: <058DA9A2-C853-4BAF-BD41-7F13CA141ED7@gmail.com> Seconded, this is indeed better. +1 > On 20 May 2016, at 10:38, Hannes Wallnoefer wrote: > > Hi Sundar, > > I agree methods feel more in their place now. > > Hannes > > Am 2016-05-20 um 09:12 schrieb Sundararajan Athijegannathan: >> Hi, >> >> Thanks for the review. But, I adjusted the change slightly -- moved >> addModuleRead and caller-sensitive fallback attempt to >> CallerSensitiveDynamicMethod itself - leaving Lookup as general >> exception translating version of j.l.invoke.MethodHandle.Lookup. >> >> I think this is better caller sensitivity handling moved to specific >> place and Lookup remains a generic API. >> >> http://cr.openjdk.java.net/~sundar/8157310/webrev.01/ >> >> Thanks, >> >> -Sundar >> >> >> On 5/20/2016 12:22 PM, Attila Szegedi wrote: >>> +1. Nice work! >>> >>>> On 19 May 2016, at 15:28, Sundararajan Athijegannathan wrote: >>>> >>>> Please review http://cr.openjdk.java.net/~sundar/8157310/ for >>>> https://bugs.openjdk.java.net/browse/JDK-8157310 >>>> >>>> What is this fix? >>>> >>>> * When unreflecting caller sensitive methods, dynalink uses specific >>>> Lookup of actual caller (instead of publicLookup) - in nashorn's case >>>> it's be the Lookup of script class. >>>> >>>> * Script class may not have read link to the module of the class (of >>>> caller sensitive member). If there is any IllegalAccessError, dynalink >>>> adds the read link and tries to >>>> >>>> unreflect again. We don't want unnecessary module link read in such >>>> cases. Check has been added whether the package is exported from >>>> declaring module. Note that there is no security issue here. Even >>>> before the fix, module read edge does not give any capability. unreflect >>>> call after adding unnecessary read line would still fail for >>>> non-exported package case. There were unnecessary module read links >>>> created - which is being avoided now. >>>> >>>> * Additional "API" in Lookup.java slipped from jigsaw code into >>>> jdk9-dev. Those unreflectCallerSensitive and >>>> unreflectConstructorCallerSensitive were meant to be 'interim' somehow >>>> slipped. Now, only unreflect and unreflectConstructor in Lookup. Caller >>>> sensitiveness is hidden in the implementation. These methods were never >>>> APIs when dynalink API was created. >>>> >>>> Thanks, >>>> >>>> -Sundar >>>> >>>> > From jan.lahoda at oracle.com Fri May 20 10:44:52 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 20 May 2016 12:44:52 +0200 Subject: RFR: 8131017: jshell tool: pasting code with tabs invokes tab completion Message-ID: <573EEAA4.9030307@oracle.com> Please review. Problem: when pasting code that contains tab characters into both jshell and jjs, the tab completion gets invoked on tabs instead of using the tab character itself. The proposed solution is to set setCopyPasteDetection(true) on jline's ConsoleReader, which should enable jline's copy-paste detection, and avoid invoking the tab completion on paste. A limitation of the detection is that it cannot detect trailing tab characters, only can detect tab character followed by at least one more character. I hope that shouldn't be a big problem. Bug: https://bugs.openjdk.java.net/browse/JDK-8131017 Webrev - langtools: http://cr.openjdk.java.net/~jlahoda/8131017/langtools/webrev.00/ Webrev - nashorn: http://cr.openjdk.java.net/~jlahoda/8131017/nashorn/webrev.00/ Thanks, Jan From sundararajan.athijegannathan at oracle.com Fri May 20 12:16:29 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 20 May 2016 17:46:29 +0530 Subject: RFR: 8131017: jshell tool: pasting code with tabs invokes tab completion In-Reply-To: <573EEAA4.9030307@oracle.com> References: <573EEAA4.9030307@oracle.com> Message-ID: Looks good. -Sundar On 5/20/2016 4:14 PM, Jan Lahoda wrote: > Please review. > > Problem: when pasting code that contains tab characters into both > jshell and jjs, the tab completion gets invoked on tabs instead of > using the tab character itself. > > The proposed solution is to set setCopyPasteDetection(true) on jline's > ConsoleReader, which should enable jline's copy-paste detection, and > avoid invoking the tab completion on paste. A limitation of the > detection is that it cannot detect trailing tab characters, only can > detect tab character followed by at least one more character. I hope > that shouldn't be a big problem. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8131017 > > Webrev - langtools: > http://cr.openjdk.java.net/~jlahoda/8131017/langtools/webrev.00/ > > Webrev - nashorn: > http://cr.openjdk.java.net/~jlahoda/8131017/nashorn/webrev.00/ > > Thanks, > Jan From michael.haupt at oracle.com Fri May 20 13:47:50 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 20 May 2016 15:47:50 +0200 Subject: RFR(XXS): 8157444: exclude jjs shebang handling test from runs Message-ID: <45CBC350-3920-47F8-949C-3969FE2F9A69@oracle.com> Dear all, please review this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8157444 Webrev: http://cr.openjdk.java.net/~mhaupt/8157444/webrev.00/ Thanks, Michael -- 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 sundararajan.athijegannathan at oracle.com Fri May 20 13:49:32 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 20 May 2016 19:19:32 +0530 Subject: RFR(XXS): 8157444: exclude jjs shebang handling test from runs In-Reply-To: <45CBC350-3920-47F8-949C-3969FE2F9A69@oracle.com> References: <45CBC350-3920-47F8-949C-3969FE2F9A69@oracle.com> Message-ID: <6b628667-b19b-6db2-2f05-a57e627c9cea@oracle.com> +1 On 5/20/2016 7:17 PM, Michael Haupt wrote: > Dear all, > > please review this fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8157444 > Webrev: http://cr.openjdk.java.net/~mhaupt/8157444/webrev.00/ > > Thanks, > > Michael > From james.laskey at oracle.com Fri May 20 14:00:42 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 20 May 2016 11:00:42 -0300 Subject: RFR(XXS): 8157444: exclude jjs shebang handling test from runs In-Reply-To: <45CBC350-3920-47F8-949C-3969FE2F9A69@oracle.com> References: <45CBC350-3920-47F8-949C-3969FE2F9A69@oracle.com> Message-ID: <6AA6825C-6692-4C6E-83D0-677D9EF054BB@oracle.com> +1 > On May 20, 2016, at 10:47 AM, Michael Haupt wrote: > > Dear all, > > please review this fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8157444 > Webrev: http://cr.openjdk.java.net/~mhaupt/8157444/webrev.00/ > > Thanks, > > Michael > > -- > > > 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 May 20 14:01:31 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 20 May 2016 16:01:31 +0200 Subject: RFR(XXS): 8157444: exclude jjs shebang handling test from runs In-Reply-To: <45CBC350-3920-47F8-949C-3969FE2F9A69@oracle.com> References: <45CBC350-3920-47F8-949C-3969FE2F9A69@oracle.com> Message-ID: <573F18BB.3060000@oracle.com> +1 Am 2016-05-20 um 15:47 schrieb Michael Haupt: > Dear all, > > please review this fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8157444 > Webrev: http://cr.openjdk.java.net/~mhaupt/8157444/webrev.00/ > > Thanks, > > Michael > From sundararajan.athijegannathan at oracle.com Fri May 20 14:51:49 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 20 May 2016 20:21:49 +0530 Subject: [8u] approval request for 8157160: JSON.stringify does not work on ScriptObjectMirror objects Message-ID: <447480db-c547-2b35-16d0-52f286df745c@oracle.com> Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8157160 9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-May/006179.html 8u webrev: http://cr.openjdk.java.net/~sundar/8157160/8u/webrev.00/ The patch wouldn't apply "as is" because of slight difference in dynalink/Bootstrap code. I'm CC'ing this email to nashorn-dev as well for backport review. Thanks, -Sundar From sean.coffey at oracle.com Fri May 20 14:58:15 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 20 May 2016 15:58:15 +0100 Subject: [8u] approval request for 8157160: JSON.stringify does not work on ScriptObjectMirror objects In-Reply-To: <447480db-c547-2b35-16d0-52f286df745c@oracle.com> References: <447480db-c547-2b35-16d0-52f286df745c@oracle.com> Message-ID: <54527a1c-ca68-b771-d758-58b7c5e00a3f@oracle.com> Approved for jdk8u-dev but subject to peer review before pushing changes. Regards, Sean. On 20/05/2016 15:51, Sundararajan Athijegannathan wrote: > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8157160 > > 9 review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-May/006179.html > > 8u webrev: http://cr.openjdk.java.net/~sundar/8157160/8u/webrev.00/ > > The patch wouldn't apply "as is" because of slight difference in > dynalink/Bootstrap code. I'm CC'ing this email to nashorn-dev as well > for backport review. > > Thanks, > > -Sundar > > From james.laskey at oracle.com Fri May 20 15:08:33 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 20 May 2016 12:08:33 -0300 Subject: [8u] approval request for 8157160: JSON.stringify does not work on ScriptObjectMirror objects In-Reply-To: <447480db-c547-2b35-16d0-52f286df745c@oracle.com> References: <447480db-c547-2b35-16d0-52f286df745c@oracle.com> Message-ID: <13B9ED9D-B4D6-4C6F-B171-FB066DBF4ECE@oracle.com> +1 > On May 20, 2016, at 11:51 AM, Sundararajan Athijegannathan wrote: > > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8157160 > > 9 review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-May/006179.html > > 8u webrev: http://cr.openjdk.java.net/~sundar/8157160/8u/webrev.00/ > > The patch wouldn't apply "as is" because of slight difference in > dynalink/Bootstrap code. I'm CC'ing this email to nashorn-dev as well > for backport review. > > Thanks, > > -Sundar > > From marc at openendedgroup.com Mon May 23 22:11:52 2016 From: marc at openendedgroup.com (Marc Downie) Date: Mon, 23 May 2016 17:11:52 -0500 Subject: Dynalink and delete Message-ID: Dear all, First of all, many thanks for this year's JEP-276 / jdk.dynalink refactoring. We've been enjoying all of the benefits of installing a custom Linker without having to maintain a fork of Nashorn just to get it installed. We can massage and customize the face that Java objects present to JavaScript almost completely. The one thing that remains that I can't manipulate is the behavior of Java objects with respect to *delete*. In short we have elaborately customizable *dyn:setProp*, *setElem*, *getProp*, *getElem* that we can bridge to other languages and runtimes, but no *dyn:deleteX. *Is this by omission or by design? best, Marc From marcus at lagergren.net Tue May 24 09:51:04 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Tue, 24 May 2016 11:51:04 +0200 Subject: RFR: 8131017: jshell tool: pasting code with tabs invokes tab completion In-Reply-To: <573EEAA4.9030307@oracle.com> References: <573EEAA4.9030307@oracle.com> Message-ID: <764A304A-8A9A-4D53-BD12-BB3830EE6834@lagergren.net> +1 > On 20 May 2016, at 12:44, Jan Lahoda wrote: > > Please review. > > Problem: when pasting code that contains tab characters into both jshell and jjs, the tab completion gets invoked on tabs instead of using the tab character itself. > > The proposed solution is to set setCopyPasteDetection(true) on jline's ConsoleReader, which should enable jline's copy-paste detection, and avoid invoking the tab completion on paste. A limitation of the detection is that it cannot detect trailing tab characters, only can detect tab character followed by at least one more character. I hope that shouldn't be a big problem. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8131017 > > Webrev - langtools: > http://cr.openjdk.java.net/~jlahoda/8131017/langtools/webrev.00/ > > Webrev - nashorn: > http://cr.openjdk.java.net/~jlahoda/8131017/nashorn/webrev.00/ > > Thanks, > Jan From marcus at lagergren.net Tue May 24 09:52:46 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Tue, 24 May 2016 11:52:46 +0200 Subject: [8u] approval request for 8157160: JSON.stringify does not work on ScriptObjectMirror objects In-Reply-To: <447480db-c547-2b35-16d0-52f286df745c@oracle.com> References: <447480db-c547-2b35-16d0-52f286df745c@oracle.com> Message-ID: <2C749860-89BB-4699-91CA-F089A7CBAB22@lagergren.net> +1 > On 20 May 2016, at 16:51, Sundararajan Athijegannathan wrote: > > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8157160 > > 9 review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-May/006179.html > > 8u webrev: http://cr.openjdk.java.net/~sundar/8157160/8u/webrev.00/ > > The patch wouldn't apply "as is" because of slight difference in > dynalink/Bootstrap code. I'm CC'ing this email to nashorn-dev as well > for backport review. > > Thanks, > > -Sundar > > From sundararajan.athijegannathan at oracle.com Tue May 24 13:52:33 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 24 May 2016 19:22:33 +0530 Subject: RFR 8157680: Callback parameter of any JS builtin implementation should accept any Callable Message-ID: <5b695e02-6d89-d882-be82-7b782b92d9fa@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8157680/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8157680 Thanks, -Sundar From hannes.wallnoefer at oracle.com Tue May 24 13:58:57 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 24 May 2016 15:58:57 +0200 Subject: RFR 8157680: Callback parameter of any JS builtin implementation should accept any Callable In-Reply-To: <5b695e02-6d89-d882-be82-7b782b92d9fa@oracle.com> References: <5b695e02-6d89-d882-be82-7b782b92d9fa@oracle.com> Message-ID: <57445E21.2090007@oracle.com> This is a nice enhancement! +1 Am 2016-05-24 um 15:52 schrieb Sundararajan Athijegannathan: > Please review http://cr.openjdk.java.net/~sundar/8157680/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8157680 > > Thanks, > > -Sundar > From sundararajan.athijegannathan at oracle.com Wed May 25 04:20:31 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 25 May 2016 09:50:31 +0530 Subject: Dynalink and delete In-Reply-To: References: Message-ID: <93a44606-67ab-371f-0d83-3cc15d3eef02@oracle.com> I recall that we did discuss about the StandardOperation set. "delete" and "iterator" were discussed at one point. But, languages are very different and difficult to generalize to include all operations. For eg. Python's del does not return boolean, ECMAScript delete returns boolean and sometime throws TypeError (strict mode)! Hence dynalink has Operation as interface and StandardOperation as one implementation. In the hindsight, it *may* be desirable to include delete. But, it is too late for jdk9 to update dynalink API :( Best, -Sundar On 5/24/2016 3:41 AM, Marc Downie wrote: > Dear all, > > First of all, many thanks for this year's JEP-276 / jdk.dynalink > refactoring. We've been enjoying all of the benefits of installing a custom > Linker without having to maintain a fork of Nashorn just to get it > installed. We can massage and customize the face that Java objects present > to JavaScript almost completely. > > The one thing that remains that I can't manipulate is the behavior of Java > objects with respect to *delete*. In short we have elaborately customizable > *dyn:setProp*, *setElem*, *getProp*, *getElem* that we can bridge to other > languages and runtimes, but no *dyn:deleteX. *Is this by omission or by > design? > > best, > > Marc From sundararajan.athijegannathan at oracle.com Wed May 25 04:36:40 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 25 May 2016 10:06:40 +0530 Subject: Dynalink and delete In-Reply-To: <93a44606-67ab-371f-0d83-3cc15d3eef02@oracle.com> References: <93a44606-67ab-371f-0d83-3cc15d3eef02@oracle.com> Message-ID: <6719a83e-724b-ff2d-9238-6f35e630bb75@oracle.com> There is a not-so-pretty workaround though. Nashorn routes delete on jdk.nashorn.api.scripting.JSObject instances to removeMember method. If you can wrap your Java objects as JSObjects [ may be just for delete], then you can customize delete on your objects. var myJavaObj = .... ; // myJavaObj is an instance of MyJavaObject linked by pluggable Dynalink linker MyJavaObjectLinker myJavaObj.foo = "hello"; // set property handled by MyJavaObjectLinker delete jsObj(myJavaObj).foo; // jsObj is a function returns a JSObject wrapper of myJavaObj. The JSObject wrapper can override removeMember. // or a special property on myJavaObj to return a JSObject wrapper delete myJavaObj._.foo; // "_" property returns a JSObject wrapper on myJavaObject which then takes care of "delete" -Sundar On 5/25/2016 9:50 AM, Sundararajan Athijegannathan wrote: > I recall that we did discuss about the StandardOperation set. "delete" > and "iterator" were discussed at one point. But, languages are very > different and difficult to generalize to include all operations. For eg. > Python's del does not return boolean, ECMAScript delete returns boolean > and sometime throws TypeError (strict mode)! > > Hence dynalink has Operation as interface and StandardOperation as one > implementation. In the hindsight, it *may* be desirable to include > delete. But, it is too late for jdk9 to update dynalink API :( > > Best, > > -Sundar > > > On 5/24/2016 3:41 AM, Marc Downie wrote: >> Dear all, >> >> First of all, many thanks for this year's JEP-276 / jdk.dynalink >> refactoring. We've been enjoying all of the benefits of installing a custom >> Linker without having to maintain a fork of Nashorn just to get it >> installed. We can massage and customize the face that Java objects present >> to JavaScript almost completely. >> >> The one thing that remains that I can't manipulate is the behavior of Java >> objects with respect to *delete*. In short we have elaborately customizable >> *dyn:setProp*, *setElem*, *getProp*, *getElem* that we can bridge to other >> languages and runtimes, but no *dyn:deleteX. *Is this by omission or by >> design? >> >> best, >> >> Marc From sundararajan.athijegannathan at oracle.com Wed May 25 04:38:09 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 25 May 2016 10:08:09 +0530 Subject: RFR 8157789: Nashorn sample/test.js should not use undocumented System property Message-ID: Please review http://cr.openjdk.java.net/~sundar/8157789/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8157789 -Sundar From mandy.chung at oracle.com Wed May 25 05:04:03 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 24 May 2016 22:04:03 -0700 Subject: RFR 8157789: Nashorn sample/test.js should not use undocumented System property In-Reply-To: References: Message-ID: > On May 24, 2016, at 9:38 PM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8157789/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8157789 > +1 It?s good to replace with a documented system property. Mandy From michael.haupt at oracle.com Wed May 25 08:59:17 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 25 May 2016 10:59:17 +0200 Subject: RFR 8157680: Callback parameter of any JS builtin implementation should accept any Callable In-Reply-To: <5b695e02-6d89-d882-be82-7b782b92d9fa@oracle.com> References: <5b695e02-6d89-d882-be82-7b782b92d9fa@oracle.com> Message-ID: <5533938B-0217-4902-AB4F-D54A425726C1@oracle.com> Hi Sundar, lower-case thumbs up. Best, Michael > Am 24.05.2016 um 15:52 schrieb Sundararajan Athijegannathan : > > Please review http://cr.openjdk.java.net/~sundar/8157680/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8157680 > > Thanks, > > -Sundar > -- 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 sundararajan.athijegannathan at oracle.com Wed May 25 10:49:32 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 25 May 2016 16:19:32 +0530 Subject: RFR 8157819: TypeError when a java.util.Comparator object is invoked as a function Message-ID: <015eca45-6cca-fcc1-986a-f809f3d7edd1@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8157819/webrev.00 for https://bugs.openjdk.java.net/browse/JDK-8157819 Thanks, -Sundar From michael.haupt at oracle.com Wed May 25 11:49:39 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 25 May 2016 13:49:39 +0200 Subject: RFR 8157819: TypeError when a java.util.Comparator object is invoked as a function In-Reply-To: <015eca45-6cca-fcc1-986a-f809f3d7edd1@oracle.com> References: <015eca45-6cca-fcc1-986a-f809f3d7edd1@oracle.com> Message-ID: Hi Sundar, lower-case thumbs up, with remarks. * "is this a overridable" -> "... an overridable" * My feeling: the name isOverridableObjectMethod would describe the method's intent more clearly. * How about comparing the method types to statically initialised MethodType instances obtained from the methods in question? Best, Michael > Am 25.05.2016 um 12:49 schrieb Sundararajan Athijegannathan : > > Please review http://cr.openjdk.java.net/~sundar/8157819/webrev.00 for > https://bugs.openjdk.java.net/browse/JDK-8157819 > > 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 sundararajan.athijegannathan at oracle.com Wed May 25 12:09:33 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 25 May 2016 17:39:33 +0530 Subject: RFR 8157819: TypeError when a java.util.Comparator object is invoked as a function In-Reply-To: References: <015eca45-6cca-fcc1-986a-f809f3d7edd1@oracle.com> Message-ID: <59218847-92db-775b-20b3-6f45d318fc94@oracle.com> Hi, Thanks for the review. Updated : http://cr.openjdk.java.net/~sundar/8157819/webrev.01/ Renamed that method and fixed the article. Leaving MethodType suggestion, as that'd mean unreflect with publicLookup + caching methodTypes of known Object methods.. Thanks, -Sundar On 5/25/2016 5:19 PM, Michael Haupt wrote: > Hi Sundar, > > lower-case thumbs up, with remarks. > > * "is this a overridable" -> "... an overridable" > > * My feeling: the name isOverridableObjectMethod would describe the > method's intent more clearly. > > * How about comparing the method types to statically initialised > MethodType instances obtained from the methods in question? > > Best, > > Michael > >> Am 25.05.2016 um 12:49 schrieb Sundararajan Athijegannathan >> > >: >> >> Please review http://cr.openjdk.java.net/~sundar/8157819/webrev.00 >> for >> https://bugs.openjdk.java.net/browse/JDK-8157819 >> >> Thanks, >> >> -Sundar >> > > -- > > Oracle > 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 > Green Oracle Oracle is committed > to developing practices and products that help protect the environment > > From forax at univ-mlv.fr Wed May 25 12:09:42 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 25 May 2016 14:09:42 +0200 (CEST) Subject: RFR 8157819: TypeError when a java.util.Comparator object is invoked as a function In-Reply-To: References: <015eca45-6cca-fcc1-986a-f809f3d7edd1@oracle.com> Message-ID: <53770305.1496558.1464178182349.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Michael Haupt" > ?: "Sundararajan Athijegannathan" > Cc: nashorn-dev at openjdk.java.net > Envoy?: Mercredi 25 Mai 2016 13:49:39 > Objet: Re: RFR 8157819: TypeError when a java.util.Comparator object is invoked as a function > Hi Sundar, Hi Mickael, > Hi Sundar, > > lower-case thumbs up, with remarks. > > * "is this a overridable" -> "... an overridable" > > * My feeling: the name isOverridableObjectMethod would describe the method's > intent more clearly. yes > > * How about comparing the method types to statically initialised MethodType > instances obtained from the methods in question? you need to go to the route that create a MethodType from a Method, which require an allocation. Sundar, i think you can use Method.getParamaterCount() [1] instead of m.getParameterTypes().length, because m.getParameterTypes() clones the returning array. > > Best, > > Michael cheers, R?mi [1] https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/Method.html#getParameterCount-- > > > Am 25.05.2016 um 12:49 schrieb Sundararajan Athijegannathan > > : > > > > Please review http://cr.openjdk.java.net/~sundar/8157819/webrev.00 for > > https://bugs.openjdk.java.net/browse/JDK-8157819 > > > > 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 sundararajan.athijegannathan at oracle.com Wed May 25 12:29:04 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 25 May 2016 17:59:04 +0530 Subject: RFR 8157819: TypeError when a java.util.Comparator object is invoked as a function In-Reply-To: <53770305.1496558.1464178182349.JavaMail.zimbra@u-pem.fr> References: <015eca45-6cca-fcc1-986a-f809f3d7edd1@oracle.com> <53770305.1496558.1464178182349.JavaMail.zimbra@u-pem.fr> Message-ID: Using Method.getParameterCount() per R?mi's suggestion. Updated: http://cr.openjdk.java.net/~sundar/8157819/webrev.02/ Thanks, -Sundar On 5/25/2016 5:39 PM, Remi Forax wrote: > ----- Mail original ----- >> De: "Michael Haupt" >> ?: "Sundararajan Athijegannathan" >> Cc: nashorn-dev at openjdk.java.net >> Envoy?: Mercredi 25 Mai 2016 13:49:39 >> Objet: Re: RFR 8157819: TypeError when a java.util.Comparator object is invoked as a function >> > > Hi Sundar, Hi Mickael, > >> Hi Sundar, >> >> lower-case thumbs up, with remarks. >> >> * "is this a overridable" -> "... an overridable" >> >> * My feeling: the name isOverridableObjectMethod would describe the method's >> intent more clearly. > yes > >> * How about comparing the method types to statically initialised MethodType >> instances obtained from the methods in question? > you need to go to the route that create a MethodType from a Method, which require an allocation. > > Sundar, i think you can use Method.getParamaterCount() [1] instead of m.getParameterTypes().length, because m.getParameterTypes() clones the returning array. > >> Best, >> >> Michael > cheers, > > R?mi > > [1] https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/Method.html#getParameterCount-- > >>> Am 25.05.2016 um 12:49 schrieb Sundararajan Athijegannathan >>> : >>> >>> Please review http://cr.openjdk.java.net/~sundar/8157819/webrev.00 for >>> https://bugs.openjdk.java.net/browse/JDK-8157819 >>> >>> 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 Wed May 25 13:52:05 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 25 May 2016 15:52:05 +0200 Subject: RFR 8157819: TypeError when a java.util.Comparator object is invoked as a function In-Reply-To: References: <015eca45-6cca-fcc1-986a-f809f3d7edd1@oracle.com> <53770305.1496558.1464178182349.JavaMail.zimbra@u-pem.fr> Message-ID: <5745AE05.8000605@oracle.com> Looks good! Am 2016-05-25 um 14:29 schrieb Sundararajan Athijegannathan: > Using Method.getParameterCount() per R?mi's suggestion. > > Updated: http://cr.openjdk.java.net/~sundar/8157819/webrev.02/ > > Thanks, > > -Sundar > > > On 5/25/2016 5:39 PM, Remi Forax wrote: >> ----- Mail original ----- >>> De: "Michael Haupt" >>> ?: "Sundararajan Athijegannathan" >>> Cc: nashorn-dev at openjdk.java.net >>> Envoy?: Mercredi 25 Mai 2016 13:49:39 >>> Objet: Re: RFR 8157819: TypeError when a java.util.Comparator object is invoked as a function >>> >> Hi Sundar, Hi Mickael, >> >>> Hi Sundar, >>> >>> lower-case thumbs up, with remarks. >>> >>> * "is this a overridable" -> "... an overridable" >>> >>> * My feeling: the name isOverridableObjectMethod would describe the method's >>> intent more clearly. >> yes >> >>> * How about comparing the method types to statically initialised MethodType >>> instances obtained from the methods in question? >> you need to go to the route that create a MethodType from a Method, which require an allocation. >> >> Sundar, i think you can use Method.getParamaterCount() [1] instead of m.getParameterTypes().length, because m.getParameterTypes() clones the returning array. >> >>> Best, >>> >>> Michael >> cheers, >> >> R?mi >> >> [1] https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/Method.html#getParameterCount-- >> >>>> Am 25.05.2016 um 12:49 schrieb Sundararajan Athijegannathan >>>> : >>>> >>>> Please review http://cr.openjdk.java.net/~sundar/8157819/webrev.00 for >>>> https://bugs.openjdk.java.net/browse/JDK-8157819 >>>> >>>> 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 sundararajan.athijegannathan at oracle.com Wed May 25 14:04:34 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 25 May 2016 19:34:34 +0530 Subject: [8u] approval request for 8157680: Callback parameter of any JS builtin implementation should accept any Callable Message-ID: <59190b63-fbd0-fe2b-dd4d-4d3117a94a8d@oracle.com> Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8157680 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-May/006225.html jdk8u webrev: http://cr.openjdk.java.net/~sundar/8157680/8u/webrev.00/ The patch would not apply "as is" because there are few 8u specific calls from Bootstrap.java. CC'ing nashorn-dev team for backport review. Thanks, -Sundar From hannes.wallnoefer at oracle.com Wed May 25 14:16:41 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 25 May 2016 16:16:41 +0200 Subject: [8u] approval request for 8157680: Callback parameter of any JS builtin implementation should accept any Callable In-Reply-To: <59190b63-fbd0-fe2b-dd4d-4d3117a94a8d@oracle.com> References: <59190b63-fbd0-fe2b-dd4d-4d3117a94a8d@oracle.com> Message-ID: <5745B3C9.8010908@oracle.com> Hi Sundar, the backport looks good. Hannes Am 2016-05-25 um 16:04 schrieb Sundararajan Athijegannathan: > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8157680 > > jdk9 review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-May/006225.html > > jdk8u webrev: http://cr.openjdk.java.net/~sundar/8157680/8u/webrev.00/ > > The patch would not apply "as is" because there are few 8u specific > calls from Bootstrap.java. CC'ing nashorn-dev team for backport review. > > Thanks, > > -Sundar > From sean.coffey at oracle.com Wed May 25 15:33:01 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 25 May 2016 16:33:01 +0100 Subject: [8u] approval request for 8157680: Callback parameter of any JS builtin implementation should accept any Callable In-Reply-To: <5745B3C9.8010908@oracle.com> References: <59190b63-fbd0-fe2b-dd4d-4d3117a94a8d@oracle.com> <5745B3C9.8010908@oracle.com> Message-ID: <5745C5AD.4010508@oracle.com> Approved. Regards, Sean. On 25/05/16 15:16, Hannes Wallnoefer wrote: > Hi Sundar, > > the backport looks good. > > Hannes > > Am 2016-05-25 um 16:04 schrieb Sundararajan Athijegannathan: >> Please approve. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8157680 >> >> jdk9 review thread: >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-May/006225.html >> >> jdk8u webrev: http://cr.openjdk.java.net/~sundar/8157680/8u/webrev.00/ >> >> The patch would not apply "as is" because there are few 8u specific >> calls from Bootstrap.java. CC'ing nashorn-dev team for backport review. >> >> Thanks, >> >> -Sundar >> > From szegedia at gmail.com Wed May 25 16:29:10 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 25 May 2016 18:29:10 +0200 Subject: RFR 8157819: TypeError when a java.util.Comparator object is invoked as a function In-Reply-To: References: <015eca45-6cca-fcc1-986a-f809f3d7edd1@oracle.com> <53770305.1496558.1464178182349.JavaMail.zimbra@u-pem.fr> Message-ID: +1 On Wed, May 25, 2016 at 2:29 PM, Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > Using Method.getParameterCount() per R?mi's suggestion. > > Updated: http://cr.openjdk.java.net/~sundar/8157819/webrev.02/ > > Thanks, > > -Sundar > > > On 5/25/2016 5:39 PM, Remi Forax wrote: > > ----- Mail original ----- > >> De: "Michael Haupt" > >> ?: "Sundararajan Athijegannathan" < > sundararajan.athijegannathan at oracle.com> > >> Cc: nashorn-dev at openjdk.java.net > >> Envoy?: Mercredi 25 Mai 2016 13:49:39 > >> Objet: Re: RFR 8157819: TypeError when a java.util.Comparator object > is invoked as a function > >> > > > > Hi Sundar, Hi Mickael, > > > >> Hi Sundar, > >> > >> lower-case thumbs up, with remarks. > >> > >> * "is this a overridable" -> "... an overridable" > >> > >> * My feeling: the name isOverridableObjectMethod would describe the > method's > >> intent more clearly. > > yes > > > >> * How about comparing the method types to statically initialised > MethodType > >> instances obtained from the methods in question? > > you need to go to the route that create a MethodType from a Method, > which require an allocation. > > > > Sundar, i think you can use Method.getParamaterCount() [1] instead of > m.getParameterTypes().length, because m.getParameterTypes() clones the > returning array. > > > >> Best, > >> > >> Michael > > cheers, > > > > R?mi > > > > [1] > https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/Method.html#getParameterCount-- > > > >>> Am 25.05.2016 um 12:49 schrieb Sundararajan Athijegannathan > >>> : > >>> > >>> Please review http://cr.openjdk.java.net/~sundar/8157819/webrev.00 for > >>> https://bugs.openjdk.java.net/browse/JDK-8157819 > >>> > >>> 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 Thu May 26 16:30:56 2016 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Thu, 26 May 2016 09:30:56 -0700 (PDT) Subject: approval request for JDK-8138906:Test test/script/trusted/JDK-8087292.js intermittently fails Message-ID: <2370da2a-7ade-4915-bdf8-a89977f4147e@default> 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/005991.html Jdk8u-webrev : http://cr.openjdk.java.net/~sdama/8138906/8u/webrev.00/ Regards, Srinivas From marcus at lagergren.net Fri May 27 13:24:36 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Fri, 27 May 2016 15:24:36 +0200 Subject: approval request for JDK-8138906:Test test/script/trusted/JDK-8087292.js intermittently fails In-Reply-To: <2370da2a-7ade-4915-bdf8-a89977f4147e@default> References: <2370da2a-7ade-4915-bdf8-a89977f4147e@default> Message-ID: <2169CC4A-26B2-449C-ABF3-680CF6AAC658@lagergren.net> +1 > On 26 May 2016, at 18: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/005991.html > Jdk8u-webrev : http://cr.openjdk.java.net/~sdama/8138906/8u/webrev.00/ > > Regards, > Srinivas From marcus at lagergren.net Fri May 27 13:24:51 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Fri, 27 May 2016 15:24:51 +0200 Subject: RFR 8157680: Callback parameter of any JS builtin implementation should accept any Callable In-Reply-To: <5b695e02-6d89-d882-be82-7b782b92d9fa@oracle.com> References: <5b695e02-6d89-d882-be82-7b782b92d9fa@oracle.com> Message-ID: <36348877-B359-408F-831C-675064ABFC64@lagergren.net> +1 > On 24 May 2016, at 15:52, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8157680/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8157680 > > Thanks, > > -Sundar > From marcus at lagergren.net Fri May 27 13:25:15 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Fri, 27 May 2016 15:25:15 +0200 Subject: RFR 8157789: Nashorn sample/test.js should not use undocumented System property In-Reply-To: References: Message-ID: <55ACD577-AA74-49BF-A958-E8292CAFB207@lagergren.net> +1 > On 25 May 2016, at 06:38, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8157789/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8157789 > > -Sundar > From sundararajan.athijegannathan at oracle.com Mon May 30 08:24:19 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 30 May 2016 13:54:19 +0530 Subject: RFR 8158131: Nashorn should not use jdk.internal.module.Modules API Message-ID: <76c39a91-d3e2-733e-fb36-c0e089890572@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8158131/ for https://bugs.openjdk.java.net/browse/JDK-8158131 This code cleanup is to avoid Nashorn's use of JDK internal class jdk.internal.module.Modules. With this change, nashorn uses java.lang.reflect.Layer public API to create single Module layers as needed. And nashorn generates/loads code into appropriate modules (which calls java.lang.reflect.Module.addReads, .addExports public APIs) to add module export/read edges as needed. -Sundar From michael.haupt at oracle.com Mon May 30 08:46:14 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 30 May 2016 10:46:14 +0200 Subject: RFR 8158131: Nashorn should not use jdk.internal.module.Modules API In-Reply-To: <76c39a91-d3e2-733e-fb36-c0e089890572@oracle.com> References: <76c39a91-d3e2-733e-fb36-c0e089890572@oracle.com> Message-ID: Hi Sundar, lower-case thumbs up for both the jdk and nashorn changes, with remarks: == ModuleGraphManipulator.java == * please add a @see or @link to the place where the bytes are read and code is dynamically generated, or used, and vice versa. == JavaAdapterBytecodeGenerator.java == + private static final Module nashornModule = JavaAdapterBytecodeGenerator.class.getModule(); This borders on the emerging discipline of Jigsaw idioms and patterns ... assuming this class moves, at some point in the future, to another (internal?) module. This will itch. How about having one central authority saying "I represent the Nashorn module", rather than implicitly assuming the class at hand will be in that module forever? One line below, Object.class.getModule() looks like a waterproof representative for the java.base module. + private static byte[] MODULES_READ_ADDER_BYRES; If it cannot be final, how about @Stable? It would help, if not in terms of performance, so at least to document that this is an array that will be populated *once* and never change thereafter. + // private static final Module myModule; + { + FieldVisitor fv = cw.visitField(ACC_PRIVATE | ACC_FINAL | ACC_STATIC, + "myModule", "Ljava/lang/reflect/Module;", null, null); + fv.visitEnd(); + } Suggestion: adhere to Java coding style even in generated code and spell this as MY_MODULE. Best, Michael > Am 30.05.2016 um 10:24 schrieb Sundararajan Athijegannathan : > > Please review http://cr.openjdk.java.net/~sundar/8158131/ for > https://bugs.openjdk.java.net/browse/JDK-8158131 > > This code cleanup is to avoid Nashorn's use of JDK internal class > jdk.internal.module.Modules. > > With this change, nashorn uses java.lang.reflect.Layer public API to > create single Module layers as needed. And nashorn generates/loads code > into appropriate modules (which calls java.lang.reflect.Module.addReads, > .addExports public APIs) to add module export/read edges as needed. > > -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 sundararajan.athijegannathan at oracle.com Mon May 30 09:20:06 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 30 May 2016 14:50:06 +0530 Subject: RFR 8158131: Nashorn should not use jdk.internal.module.Modules API In-Reply-To: References: <76c39a91-d3e2-733e-fb36-c0e089890572@oracle.com> Message-ID: <58fd13c5-f03b-7ea1-9efb-45be8f8a3e7b@oracle.com> Hi, Inline replies below. On 5/30/2016 2:16 PM, Michael Haupt wrote: > Hi Sundar, > > lower-case thumbs up for both the jdk and nashorn changes, with remarks: > > == ModuleGraphManipulator.java == > > * please add a @see or @link to the place where the bytes are read and > code is dynamically generated, or used, and vice versa. > Will do. > == JavaAdapterBytecodeGenerator.java == > > + private static final Module nashornModule = > JavaAdapterBytecodeGenerator.class.getModule(); > > This borders on the emerging discipline of Jigsaw idioms and patterns > ... assuming this class moves, at some point in the future, to another > (internal?) module. This will itch. How about having one central > authority saying "I represent the Nashorn module", rather than > implicitly assuming the class at hand will be in that module forever? > One line below, Object.class.getModule() looks like a waterproof > representative for the java.base module. hmm.. if this class moves out of nashorn , many things will break anyway! i.e., this has to be in nashorn (because of security assumptions for eg). I could use Context class perhaps.. > > + private static byte[] MODULES_READ_ADDER_BYRES; > > If it cannot be final, how about @Stable? It would help, if not in > terms of performance, so at least to document that this is an array > that will be populated *once* and never change thereafter. > hmm.. @Stable would bring another internal API dependency to nashorn. Would like to avoid another internal API dependency to nashorn. > + // private static final Module myModule; > + { > + FieldVisitor fv = cw.visitField(ACC_PRIVATE | ACC_FINAL | > ACC_STATIC, > + "myModule", "Ljava/lang/reflect/Module;", null, null); > + fv.visitEnd(); > + } > > Suggestion: adhere to Java coding style even in generated code and > spell this as MY_MODULE. Will fix that. Thanks, -Sundar > > Best, > > Michael > >> Am 30.05.2016 um 10:24 schrieb Sundararajan Athijegannathan >> > >: >> >> Please review http://cr.openjdk.java.net/~sundar/8158131/ >> for >> https://bugs.openjdk.java.net/browse/JDK-8158131 >> >> This code cleanup is to avoid Nashorn's use of JDK internal class >> jdk.internal.module.Modules. >> >> With this change, nashorn uses java.lang.reflect.Layer public API to >> create single Module layers as needed. And nashorn generates/loads code >> into appropriate modules (which calls java.lang.reflect.Module.addReads, >> .addExports public APIs) to add module export/read edges as needed. >> >> -Sundar >> > > -- > > Oracle > 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 > Green Oracle Oracle is committed > to developing practices and products that help protect the environment > > From sundararajan.athijegannathan at oracle.com Mon May 30 10:43:22 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 30 May 2016 16:13:22 +0530 Subject: RFR 8158131: Nashorn should not use jdk.internal.module.Modules API In-Reply-To: <58fd13c5-f03b-7ea1-9efb-45be8f8a3e7b@oracle.com> References: <76c39a91-d3e2-733e-fb36-c0e089890572@oracle.com> <58fd13c5-f03b-7ea1-9efb-45be8f8a3e7b@oracle.com> Message-ID: <379dd2b8-ef74-0278-bdab-f2de029fdaf5@oracle.com> Updated nashorn webrev: http://cr.openjdk.java.net/~sundar/8158131/nashorn/webrev.01/ * Added @link in ModuleGraphManipulator.java's javadoc * Using Context.class.getModule() in all places where nashorn module is needed * Using all caps names for static final variables - nashornModule, javaBaseModule, myModule in generated -Sundar On 5/30/2016 2:50 PM, Sundararajan Athijegannathan wrote: > Hi, > > Inline replies below. > > > On 5/30/2016 2:16 PM, Michael Haupt wrote: >> Hi Sundar, >> >> lower-case thumbs up for both the jdk and nashorn changes, with remarks: >> >> == ModuleGraphManipulator.java == >> >> * please add a @see or @link to the place where the bytes are read and >> code is dynamically generated, or used, and vice versa. >> > Will do. > >> == JavaAdapterBytecodeGenerator.java == >> >> + private static final Module nashornModule = >> JavaAdapterBytecodeGenerator.class.getModule(); >> >> This borders on the emerging discipline of Jigsaw idioms and patterns >> ... assuming this class moves, at some point in the future, to another >> (internal?) module. This will itch. How about having one central >> authority saying "I represent the Nashorn module", rather than >> implicitly assuming the class at hand will be in that module forever? >> One line below, Object.class.getModule() looks like a waterproof >> representative for the java.base module. > hmm.. if this class moves out of nashorn , many things will break > anyway! i.e., this has to be in nashorn (because of security assumptions > for eg). I could use Context class perhaps.. > >> + private static byte[] MODULES_READ_ADDER_BYRES; >> >> If it cannot be final, how about @Stable? It would help, if not in >> terms of performance, so at least to document that this is an array >> that will be populated *once* and never change thereafter. >> > hmm.. @Stable would bring another internal API dependency to nashorn. > Would like to avoid another internal API dependency to nashorn. > >> + // private static final Module myModule; >> + { >> + FieldVisitor fv = cw.visitField(ACC_PRIVATE | ACC_FINAL | >> ACC_STATIC, >> + "myModule", "Ljava/lang/reflect/Module;", null, null); >> + fv.visitEnd(); >> + } >> >> Suggestion: adhere to Java coding style even in generated code and >> spell this as MY_MODULE. > Will fix that. > > Thanks, > -Sundar > >> Best, >> >> Michael >> >>> Am 30.05.2016 um 10:24 schrieb Sundararajan Athijegannathan >>> >> >: >>> >>> Please review http://cr.openjdk.java.net/~sundar/8158131/ >>> for >>> https://bugs.openjdk.java.net/browse/JDK-8158131 >>> >>> This code cleanup is to avoid Nashorn's use of JDK internal class >>> jdk.internal.module.Modules. >>> >>> With this change, nashorn uses java.lang.reflect.Layer public API to >>> create single Module layers as needed. And nashorn generates/loads code >>> into appropriate modules (which calls java.lang.reflect.Module.addReads, >>> .addExports public APIs) to add module export/read edges as needed. >>> >>> -Sundar >>> >> -- >> >> Oracle >> 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 >> Green Oracle Oracle is committed >> to developing practices and products that help protect the environment >> >> From Alan.Bateman at oracle.com Mon May 30 17:55:24 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 30 May 2016 18:55:24 +0100 Subject: RFR 8158131: Nashorn should not use jdk.internal.module.Modules API In-Reply-To: <379dd2b8-ef74-0278-bdab-f2de029fdaf5@oracle.com> References: <76c39a91-d3e2-733e-fb36-c0e089890572@oracle.com> <58fd13c5-f03b-7ea1-9efb-45be8f8a3e7b@oracle.com> <379dd2b8-ef74-0278-bdab-f2de029fdaf5@oracle.com> Message-ID: <574C7E8C.8030704@oracle.com> On 30/05/2016 11:43, Sundararajan Athijegannathan wrote: > Updated nashorn webrev: > http://cr.openjdk.java.net/~sundar/8158131/nashorn/webrev.01/ > > * Added @link in ModuleGraphManipulator.java's javadoc > > * Using Context.class.getModule() in all places where nashorn module is > needed > > * Using all caps names for static final variables - nashornModule, > javaBaseModule, myModule in generated > > I looked over the changes and good to see it using the API to create dynamic modules. I assume folks familiar with the Nashorn code will do the detailed review. -Alan From sundararajan.athijegannathan at oracle.com Tue May 31 07:17:33 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 31 May 2016 12:47:33 +0530 Subject: RFR 8158131: Nashorn should not use jdk.internal.module.Modules API In-Reply-To: <379dd2b8-ef74-0278-bdab-f2de029fdaf5@oracle.com> References: <76c39a91-d3e2-733e-fb36-c0e089890572@oracle.com> <58fd13c5-f03b-7ea1-9efb-45be8f8a3e7b@oracle.com> <379dd2b8-ef74-0278-bdab-f2de029fdaf5@oracle.com> Message-ID: Sorry, I have updated nashorn webrev again: http://cr.openjdk.java.net/~sundar/8158131/nashorn/webrev.02/ Incremental changes: * Missed "nashornModule" name in JavaAdapterClassLoader.java. Fixed it to use all caps name * AccessController.doPrivileged call in Context.createModuleTrusted. Earlier I had used an acc. context with "getClassLoader" and "createClassLoader" permissions. But, Layer.defineModules call requires just "getClassLoader" permission. Reduced acc. context accordingly. -Sundar On 5/30/2016 4:13 PM, Sundararajan Athijegannathan wrote: > Updated nashorn webrev: > http://cr.openjdk.java.net/~sundar/8158131/nashorn/webrev.01/ > > * Added @link in ModuleGraphManipulator.java's javadoc > > * Using Context.class.getModule() in all places where nashorn module is > needed > > * Using all caps names for static final variables - nashornModule, > javaBaseModule, myModule in generated > > -Sundar > > > On 5/30/2016 2:50 PM, Sundararajan Athijegannathan wrote: >> Hi, >> >> Inline replies below. >> >> >> On 5/30/2016 2:16 PM, Michael Haupt wrote: >>> Hi Sundar, >>> >>> lower-case thumbs up for both the jdk and nashorn changes, with remarks: >>> >>> == ModuleGraphManipulator.java == >>> >>> * please add a @see or @link to the place where the bytes are read and >>> code is dynamically generated, or used, and vice versa. >>> >> Will do. >> >>> == JavaAdapterBytecodeGenerator.java == >>> >>> + private static final Module nashornModule = >>> JavaAdapterBytecodeGenerator.class.getModule(); >>> >>> This borders on the emerging discipline of Jigsaw idioms and patterns >>> ... assuming this class moves, at some point in the future, to another >>> (internal?) module. This will itch. How about having one central >>> authority saying "I represent the Nashorn module", rather than >>> implicitly assuming the class at hand will be in that module forever? >>> One line below, Object.class.getModule() looks like a waterproof >>> representative for the java.base module. >> hmm.. if this class moves out of nashorn , many things will break >> anyway! i.e., this has to be in nashorn (because of security assumptions >> for eg). I could use Context class perhaps.. >> >>> + private static byte[] MODULES_READ_ADDER_BYRES; >>> >>> If it cannot be final, how about @Stable? It would help, if not in >>> terms of performance, so at least to document that this is an array >>> that will be populated *once* and never change thereafter. >>> >> hmm.. @Stable would bring another internal API dependency to nashorn. >> Would like to avoid another internal API dependency to nashorn. >> >>> + // private static final Module myModule; >>> + { >>> + FieldVisitor fv = cw.visitField(ACC_PRIVATE | ACC_FINAL | >>> ACC_STATIC, >>> + "myModule", "Ljava/lang/reflect/Module;", null, null); >>> + fv.visitEnd(); >>> + } >>> >>> Suggestion: adhere to Java coding style even in generated code and >>> spell this as MY_MODULE. >> Will fix that. >> >> Thanks, >> -Sundar >> >>> Best, >>> >>> Michael >>> >>>> Am 30.05.2016 um 10:24 schrieb Sundararajan Athijegannathan >>>> >>> >: >>>> >>>> Please review http://cr.openjdk.java.net/~sundar/8158131/ >>>> for >>>> https://bugs.openjdk.java.net/browse/JDK-8158131 >>>> >>>> This code cleanup is to avoid Nashorn's use of JDK internal class >>>> jdk.internal.module.Modules. >>>> >>>> With this change, nashorn uses java.lang.reflect.Layer public API to >>>> create single Module layers as needed. And nashorn generates/loads code >>>> into appropriate modules (which calls java.lang.reflect.Module.addReads, >>>> .addExports public APIs) to add module export/read edges as needed. >>>> >>>> -Sundar >>>> >>> -- >>> >>> Oracle >>> 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 >>> Green Oracle Oracle is committed >>> to developing practices and products that help protect the environment >>> >>> From hannes.wallnoefer at oracle.com Tue May 31 07:29:23 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 31 May 2016 09:29:23 +0200 Subject: RFR 8158131: Nashorn should not use jdk.internal.module.Modules API In-Reply-To: <574C7E8C.8030704@oracle.com> References: <76c39a91-d3e2-733e-fb36-c0e089890572@oracle.com> <58fd13c5-f03b-7ea1-9efb-45be8f8a3e7b@oracle.com> <379dd2b8-ef74-0278-bdab-f2de029fdaf5@oracle.com> <574C7E8C.8030704@oracle.com> Message-ID: <574D3D53.7040508@oracle.com> Sorry for the slow review, I needed some explanation from Sundar about the difficulties of dynamic module creation, cross-layer read edges etc. With that knowledge +1 for this change. Hannes Am 2016-05-30 um 19:55 schrieb Alan Bateman: > On 30/05/2016 11:43, Sundararajan Athijegannathan wrote: >> Updated nashorn webrev: >> http://cr.openjdk.java.net/~sundar/8158131/nashorn/webrev.01/ >> >> * Added @link in ModuleGraphManipulator.java's javadoc >> >> * Using Context.class.getModule() in all places where nashorn module is >> needed >> >> * Using all caps names for static final variables - nashornModule, >> javaBaseModule, myModule in generated >> >> > I looked over the changes and good to see it using the API to create > dynamic modules. I assume folks familiar with the Nashorn code will do > the detailed review. > > -Alan From hannes.wallnoefer at oracle.com Tue May 31 07:32:35 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 31 May 2016 09:32:35 +0200 Subject: RFR 8158131: Nashorn should not use jdk.internal.module.Modules API In-Reply-To: References: <76c39a91-d3e2-733e-fb36-c0e089890572@oracle.com> <58fd13c5-f03b-7ea1-9efb-45be8f8a3e7b@oracle.com> <379dd2b8-ef74-0278-bdab-f2de029fdaf5@oracle.com> Message-ID: <574D3E13.4020601@oracle.com> +1 for the incremental changes in the last iteration. Hannes Am 2016-05-31 um 09:17 schrieb Sundararajan Athijegannathan: > Sorry, I have updated nashorn webrev again: > > http://cr.openjdk.java.net/~sundar/8158131/nashorn/webrev.02/ > > Incremental changes: > > * Missed "nashornModule" name in JavaAdapterClassLoader.java. Fixed it > to use all caps name > * AccessController.doPrivileged call in Context.createModuleTrusted. > Earlier I had used an acc. context with "getClassLoader" and > "createClassLoader" permissions. > But, Layer.defineModules call requires just "getClassLoader" permission. > Reduced acc. context accordingly. > > -Sundar > > On 5/30/2016 4:13 PM, Sundararajan Athijegannathan wrote: >> Updated nashorn webrev: >> http://cr.openjdk.java.net/~sundar/8158131/nashorn/webrev.01/ >> >> * Added @link in ModuleGraphManipulator.java's javadoc >> >> * Using Context.class.getModule() in all places where nashorn module is >> needed >> >> * Using all caps names for static final variables - nashornModule, >> javaBaseModule, myModule in generated >> >> -Sundar >> >> >> On 5/30/2016 2:50 PM, Sundararajan Athijegannathan wrote: >>> Hi, >>> >>> Inline replies below. >>> >>> >>> On 5/30/2016 2:16 PM, Michael Haupt wrote: >>>> Hi Sundar, >>>> >>>> lower-case thumbs up for both the jdk and nashorn changes, with remarks: >>>> >>>> == ModuleGraphManipulator.java == >>>> >>>> * please add a @see or @link to the place where the bytes are read and >>>> code is dynamically generated, or used, and vice versa. >>>> >>> Will do. >>> >>>> == JavaAdapterBytecodeGenerator.java == >>>> >>>> + private static final Module nashornModule = >>>> JavaAdapterBytecodeGenerator.class.getModule(); >>>> >>>> This borders on the emerging discipline of Jigsaw idioms and patterns >>>> ... assuming this class moves, at some point in the future, to another >>>> (internal?) module. This will itch. How about having one central >>>> authority saying "I represent the Nashorn module", rather than >>>> implicitly assuming the class at hand will be in that module forever? >>>> One line below, Object.class.getModule() looks like a waterproof >>>> representative for the java.base module. >>> hmm.. if this class moves out of nashorn , many things will break >>> anyway! i.e., this has to be in nashorn (because of security assumptions >>> for eg). I could use Context class perhaps.. >>> >>>> + private static byte[] MODULES_READ_ADDER_BYRES; >>>> >>>> If it cannot be final, how about @Stable? It would help, if not in >>>> terms of performance, so at least to document that this is an array >>>> that will be populated *once* and never change thereafter. >>>> >>> hmm.. @Stable would bring another internal API dependency to nashorn. >>> Would like to avoid another internal API dependency to nashorn. >>> >>>> + // private static final Module myModule; >>>> + { >>>> + FieldVisitor fv = cw.visitField(ACC_PRIVATE | ACC_FINAL | >>>> ACC_STATIC, >>>> + "myModule", "Ljava/lang/reflect/Module;", null, null); >>>> + fv.visitEnd(); >>>> + } >>>> >>>> Suggestion: adhere to Java coding style even in generated code and >>>> spell this as MY_MODULE. >>> Will fix that. >>> >>> Thanks, >>> -Sundar >>> >>>> Best, >>>> >>>> Michael >>>> >>>>> Am 30.05.2016 um 10:24 schrieb Sundararajan Athijegannathan >>>>> >>>> >: >>>>> >>>>> Please review http://cr.openjdk.java.net/~sundar/8158131/ >>>>> for >>>>> https://bugs.openjdk.java.net/browse/JDK-8158131 >>>>> >>>>> This code cleanup is to avoid Nashorn's use of JDK internal class >>>>> jdk.internal.module.Modules. >>>>> >>>>> With this change, nashorn uses java.lang.reflect.Layer public API to >>>>> create single Module layers as needed. And nashorn generates/loads code >>>>> into appropriate modules (which calls java.lang.reflect.Module.addReads, >>>>> .addExports public APIs) to add module export/read edges as needed. >>>>> >>>>> -Sundar >>>>> >>>> -- >>>> >>>> Oracle >>>> 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 >>>> Green Oracle Oracle is committed >>>> to developing practices and products that help protect the environment >>>> >>>> From sundararajan.athijegannathan at oracle.com Tue May 31 15:00:23 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 31 May 2016 20:30:23 +0530 Subject: RFR 8158250: nashorn ant javadoc targets are broken Message-ID: <03781f02-5423-1048-1772-7aae89f96d3a@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8158250/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8158250 Thanks, -Sundar From hannes.wallnoefer at oracle.com Tue May 31 15:30:27 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 31 May 2016 17:30:27 +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: <574DAE13.3060808@oracle.com> Looks good! Am 2016-05-31 um 17:00 schrieb Sundararajan Athijegannathan: > Please review http://cr.openjdk.java.net/~sundar/8158250/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8158250 > > Thanks, > > -Sundar > From michael.haupt at oracle.com Tue May 31 15:42:25 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 31 May 2016 17:42:25 +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: <5A5EE8ED-78B9-4542-9DAF-B5A150928258@oracle.com> Hi Sundar, lower-case thumbs up! Best, Michael > Am 31.05.2016 um 17:00 schrieb Sundararajan Athijegannathan : > > Please review http://cr.openjdk.java.net/~sundar/8158250/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8158250 > > Thanks, > > -Sundar > -- 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 yikesaroni at gmail.com Tue May 31 20:23:16 2016 From: yikesaroni at gmail.com (yikes aroni) Date: Tue, 31 May 2016 16:23:16 -0400 Subject: "not an object" Message-ID: 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.