From james.laskey at oracle.com Fri Apr 8 17:05:42 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 8 Apr 2016 14:05:42 -0300 Subject: RFR: JDK-8075550 - Error "JavaFX runtime not found" in nashorn when load predefines scripts to import JavaFX packages Message-ID: The code was reworked to use jrtfs: instead of reading from javafx.jar. http://cr.openjdk.java.net/~jlaskey/8075550/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8075550 From kevin.rushforth at oracle.com Fri Apr 8 23:35:04 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 08 Apr 2016 16:35:04 -0700 Subject: RFR: JDK-8075550 - Error "JavaFX runtime not found" in nashorn when load predefines scripts to import JavaFX packages In-Reply-To: References: Message-ID: <57084028.90202@oracle.com> There are no public types exported by javafx.deploy so the change to use that module seems unneeded (I see that you used to include the SWT classes, which is likely what you want, but for which we don't yet have a solution in JDK 9). Everything else looks good to me. +1 -- Kevin Jim Laskey (Oracle) wrote: > The code was reworked to use jrtfs: instead of reading from javafx.jar. > > http://cr.openjdk.java.net/~jlaskey/8075550/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8075550 > > > > From michael.haupt at oracle.com Mon Apr 11 12:13:08 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 11 Apr 2016 14:13:08 +0200 Subject: RFR: JDK-8075550 - Error "JavaFX runtime not found" in nashorn when load predefines scripts to import JavaFX packages In-Reply-To: References: Message-ID: <7CF13757-0071-4E05-8253-945C03D0834B@oracle.com> Hi Jim, lower-case thumbs up! Best, Michael > Am 08.04.2016 um 19:05 schrieb Jim Laskey (Oracle) : > > The code was reworked to use jrtfs: instead of reading from javafx.jar. > > http://cr.openjdk.java.net/~jlaskey/8075550/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8075550 > > > -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From james.laskey at oracle.com Mon Apr 11 12:43:00 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 11 Apr 2016 09:43:00 -0300 Subject: RFR: JDK-8075550 - Error "JavaFX runtime not found" in nashorn when load predefines scripts to import JavaFX packages In-Reply-To: <7CF13757-0071-4E05-8253-945C03D0834B@oracle.com> References: <7CF13757-0071-4E05-8253-945C03D0834B@oracle.com> Message-ID: Any one else. > On Apr 11, 2016, at 9:13 AM, Michael Haupt wrote: > > Hi Jim, > > lower-case thumbs up! > > Best, > > Michael > >> Am 08.04.2016 um 19:05 schrieb Jim Laskey (Oracle) >: >> >> The code was reworked to use jrtfs: instead of reading from javafx.jar. >> >> http://cr.openjdk.java.net/~jlaskey/8075550/webrev/index.html >> https://bugs.openjdk.java.net/browse/JDK-8075550 >> >> >> > > -- > > > 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 Apr 11 12:52:12 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 11 Apr 2016 18:22:12 +0530 Subject: RFR: JDK-8075550 - Error "JavaFX runtime not found" in nashorn when load predefines scripts to import JavaFX packages In-Reply-To: References: <7CF13757-0071-4E05-8253-945C03D0834B@oracle.com> Message-ID: <570B9DFC.8020901@oracle.com> +1 On 4/11/2016 6:13 PM, Jim Laskey (Oracle) wrote: > Any one else. > >> On Apr 11, 2016, at 9:13 AM, Michael Haupt wrote: >> >> Hi Jim, >> >> lower-case thumbs up! >> >> Best, >> >> Michael >> >>> Am 08.04.2016 um 19:05 schrieb Jim Laskey (Oracle) >: >>> >>> The code was reworked to use jrtfs: instead of reading from javafx.jar. >>> >>> http://cr.openjdk.java.net/~jlaskey/8075550/webrev/index.html >>> https://bugs.openjdk.java.net/browse/JDK-8075550 >>> >>> >>> >> -- >> >> >> Dr. Michael Haupt | Principal Member of Technical Staff >> Phone: +49 331 200 7277 | Fax: +49 331 200 7561 >> Oracle Java Platform Group | LangTools Team | Nashorn >> Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany >> >> ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen >> Registergericht: Amtsgericht M?nchen, HRA 95603 >> >> Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande >> Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 >> Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher >> Oracle is committed to developing practices and products that help protect the environment >> From james.laskey at oracle.com Mon Apr 11 12:56:48 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 11 Apr 2016 09:56:48 -0300 Subject: RFR: JDK-8075550 - Error "JavaFX runtime not found" in nashorn when load predefines scripts to import JavaFX packages In-Reply-To: <570B9DFC.8020901@oracle.com> References: <7CF13757-0071-4E05-8253-945C03D0834B@oracle.com> <570B9DFC.8020901@oracle.com> Message-ID: <684FC24B-76F7-47D7-8F60-E7E7F67A3491@oracle.com> Thank you. > On Apr 11, 2016, at 9:52 AM, Sundararajan Athijegannathan wrote: > > +1 > > On 4/11/2016 6:13 PM, Jim Laskey (Oracle) wrote: >> Any one else. >> >>> On Apr 11, 2016, at 9:13 AM, Michael Haupt wrote: >>> >>> Hi Jim, >>> >>> lower-case thumbs up! >>> >>> Best, >>> >>> Michael >>> >>>> Am 08.04.2016 um 19:05 schrieb Jim Laskey (Oracle) >: >>>> >>>> The code was reworked to use jrtfs: instead of reading from javafx.jar. >>>> >>>> http://cr.openjdk.java.net/~jlaskey/8075550/webrev/index.html >>>> https://bugs.openjdk.java.net/browse/JDK-8075550 >>>> >>>> >>>> >>> -- >>> >>> >>> 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 Mon Apr 11 16:01:37 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 11 Apr 2016 18:01:37 +0200 Subject: RFR(S): 8137149: add tests for issues closed during Nashorn issue cleanup Message-ID: <6FA66BA5-1D04-4B81-86EC-301E9CADC05F@oracle.com> Dear all, please review this change. RFE: https://bugs.openjdk.java.net/browse/JDK-8137149 Webrev: http://cr.openjdk.java.net/~mhaupt/8137149/webrev.00/ The change adds tests for two issues that were previously not covered by tests, and that were closed as already fixed by other changes. 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 james.laskey at oracle.com Mon Apr 11 16:08:01 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 11 Apr 2016 13:08:01 -0300 Subject: RFR(S): 8137149: add tests for issues closed during Nashorn issue cleanup In-Reply-To: <6FA66BA5-1D04-4B81-86EC-301E9CADC05F@oracle.com> References: <6FA66BA5-1D04-4B81-86EC-301E9CADC05F@oracle.com> Message-ID: +1 > On Apr 11, 2016, at 1:01 PM, Michael Haupt wrote: > > Dear all, > > please review this change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8137149 > Webrev: http://cr.openjdk.java.net/~mhaupt/8137149/webrev.00/ > > The change adds tests for two issues that were previously not covered by tests, and that were closed as already fixed by other changes. > > 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 marcus at lagergren.net Wed Apr 13 07:46:28 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Wed, 13 Apr 2016 09:46:28 +0200 Subject: RFR: JDK-8075550 - Error "JavaFX runtime not found" in nashorn when load predefines scripts to import JavaFX packages In-Reply-To: References: Message-ID: <306D0700-B58E-4BBB-A3BB-C36C98931263@lagergren.net> +1 > On 08 Apr 2016, at 19:05, Jim Laskey (Oracle) wrote: > > The code was reworked to use jrtfs: instead of reading from javafx.jar. > > http://cr.openjdk.java.net/~jlaskey/8075550/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8075550 > > > From marcus at lagergren.net Wed Apr 13 07:47:04 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Wed, 13 Apr 2016 09:47:04 +0200 Subject: RFR(S): 8137149: add tests for issues closed during Nashorn issue cleanup In-Reply-To: <6FA66BA5-1D04-4B81-86EC-301E9CADC05F@oracle.com> References: <6FA66BA5-1D04-4B81-86EC-301E9CADC05F@oracle.com> Message-ID: <44797C98-BE95-4462-B238-53CFBAD4559F@lagergren.net> +1 > On 11 Apr 2016, at 18:01, Michael Haupt wrote: > > Dear all, > > please review this change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8137149 > Webrev: http://cr.openjdk.java.net/~mhaupt/8137149/webrev.00/ > > The change adds tests for two issues that were previously not covered by tests, and that were closed as already fixed by other changes. > > 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 daniel.smith at oracle.com Wed Apr 13 18:16:24 2016 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 13 Apr 2016 12:16:24 -0600 Subject: Call for Speakers -- 2016 JVM Language Summit Message-ID: <24FD249B-570E-4D7B-9BAE-D3191BAE464D@oracle.com> CALL FOR SPEAKERS -- JVM LANGUAGE SUMMIT, AUGUST 2016 We are pleased to announce the 2016 JVM Language Summit to be held at Oracle's Santa Clara campus on August 1-3, 2016. Registration is now open for speaker submissions and will remain open through May 23, 2016. There is no registration fee for speakers. A limited number of early registration slots are also available for regular attendees. The JVM Language Summit is an open technical collaboration among language designers, compiler writers, tool builders, runtime engineers, and VM architects. We will share our experiences as creators of both the JVM and programming languages for the JVM. We also welcome non-JVM developers of similar technologies to attend or speak on their runtime, VM, or language of choice. Presentations will be recorded and made available to the public. This event is being organized by language and JVM engineers -- no marketers involved! So bring your slide rules and be prepared for some seriously geeky discussions. Format The summit is held in a single classroom-style room to support direct communication between participants. About 100-120 attendees are expected. The schedule consists of a single track of traditional presentations (about 7 each day) interspersed with less-formal multitrack "workshop" discussion groups (2-3 each day) and, possibly, impromptu "lightning talks." Workshops will be less structured than in the past, favoring an open discussion format with only a small amount of prepared material. Thus, rather than collecting workshop abstracts from speakers, we're asking each registrant to suggest a few topics of interest. After choosing the most popular topics, we'll ask some registrants if they'd like to act as discussion leaders. Instructions for Speaker Registration If you'd like to give a presentation, please register as a Speaker and include a detailed abstract. Speaker registration will remain open through May 23. There is no fee. See below for help preparing your abstract and talk. You will be notified about whether your proposal has been accepted; if not, you will be able to register as a regular attendee. For a successful speaker submission, please note the following: - All talks should be deeply technical, given by designers and implementors to designers and implementors. We all speak bytecode here! - Each talk, we hope and expect, will inform the audience, in detail, about the state of the art of language design or implementation on the JVM, or will explore the present and future capabilities of the JVM itself. (Some will do so indirectly by discussing non-JVM technologies.) - Know your audience: attendees may not be likely to ever use your specific language or tool, but could learn something from your interactions with the JVM. A broad goal of the summit is to inspire us to work together on JVM-based technologies that enable a rich ecosystem at higher layers. To register: register.jvmlangsummit.com For further information: jvmlangsummit.com Questions: inquire2016 at jvmlangsummit.com From hannes.wallnoefer at oracle.com Mon Apr 25 11:49:57 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 25 Apr 2016 13:49:57 +0200 Subject: Review request for JDK-8134503: support ES6 parsing in Nashorn Message-ID: <571E0465.2060906@oracle.com> Please review JDK-8134503: support ES6 parsing in Nashorn http://cr.openjdk.java.net/~hannesw/8134503/webrev/ The original patch was contributed by Andreas Woess, I just did the integration into Nashorn tip. Thanks, Hannes From james.laskey at oracle.com Mon Apr 25 12:00:55 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 25 Apr 2016 09:00:55 -0300 Subject: Review request for JDK-8134503: support ES6 parsing in Nashorn In-Reply-To: <571E0465.2060906@oracle.com> References: <571E0465.2060906@oracle.com> Message-ID: +1 > On Apr 25, 2016, at 8:49 AM, Hannes Wallnoefer wrote: > > Please review JDK-8134503: support ES6 parsing in Nashorn > > http://cr.openjdk.java.net/~hannesw/8134503/webrev/ > > The original patch was contributed by Andreas Woess, I just did the integration into Nashorn tip. > > Thanks, > Hannes From sundararajan.athijegannathan at oracle.com Mon Apr 25 12:19:38 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 25 Apr 2016 17:49:38 +0530 Subject: Review request for JDK-8134503: support ES6 parsing in Nashorn In-Reply-To: <571E0465.2060906@oracle.com> References: <571E0465.2060906@oracle.com> Message-ID: <8963506f-c124-9723-5217-78d096f38738@oracle.com> * new sources copyright year to be 2016 * can the new IR node classes be final? ClassNode etc.? * .EXPECTED files have new endPosition now. are we being precise now? +1 -Sundar On 4/25/2016 5:19 PM, Hannes Wallnoefer wrote: > Please review JDK-8134503: support ES6 parsing in Nashorn > > http://cr.openjdk.java.net/~hannesw/8134503/webrev/ > > The original patch was contributed by Andreas Woess, I just did the > integration into Nashorn tip. > > Thanks, > Hannes From michael.haupt at oracle.com Mon Apr 25 12:39:27 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 25 Apr 2016 14:39:27 +0200 Subject: Review request for JDK-8134503: support ES6 parsing in Nashorn In-Reply-To: <571E0465.2060906@oracle.com> References: <571E0465.2060906@oracle.com> Message-ID: Hi Hannes, that's a really significant improvement, thanks for taking this on! There is one thing that I think needs to be addressed. Several occurrences of throw error(...) pass a plain English string, rather than passing the result of a call to AbstractParser.message(...), which stands in the path of message internationalisation. Some invocations of String.format() in this setting pass only a String but no arguments (these will go away automatically when the messages are converted to retrieval). Nits: * Block.java - this (in the first chunk) can go away, or should not be commented out: + // assert start <= finish; * Parser.java - the label here should be indented: + private void statementList() { + // Accumulate statements until end of list. */ +loop: + while (type != EOF) { + switch (type) { + case EOF: Best, Michael > Am 25.04.2016 um 13:49 schrieb Hannes Wallnoefer : > > Please review JDK-8134503: support ES6 parsing in Nashorn > > http://cr.openjdk.java.net/~hannesw/8134503/webrev/ > > The original patch was contributed by Andreas Woess, I just did the integration into Nashorn tip. > > Thanks, > Hannes -- 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 andreas.woess at oracle.com Mon Apr 25 16:13:58 2016 From: andreas.woess at oracle.com (Andreas Woess) Date: Mon, 25 Apr 2016 18:13:58 +0200 Subject: RFR: 8155025: 0.001.toFixed(2) should return "0.00" not "0" Message-ID: <571E4246.7020209@oracle.com> Please review: http://cr.openjdk.java.net/~aw/8155025/webrev/ https://bugs.openjdk.java.net/browse/JDK-8155025 This is a bug introduced by JDK-8010803, so it doesn't affect jdk8. Thanks, Andreas From james.laskey at oracle.com Mon Apr 25 16:17:48 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 25 Apr 2016 13:17:48 -0300 Subject: RFR: 8155025: 0.001.toFixed(2) should return "0.00" not "0" In-Reply-To: <571E4246.7020209@oracle.com> References: <571E4246.7020209@oracle.com> Message-ID: +1 (validated against v8) > On Apr 25, 2016, at 1:13 PM, Andreas Woess wrote: > > Please review: > http://cr.openjdk.java.net/~aw/8155025/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8155025 > > This is a bug introduced by JDK-8010803, so it doesn't affect jdk8. > > Thanks, > Andreas From hannes.wallnoefer at oracle.com Mon Apr 25 17:05:45 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 25 Apr 2016 19:05:45 +0200 Subject: RFR: 8155025: 0.001.toFixed(2) should return "0.00" not "0" In-Reply-To: <571E4246.7020209@oracle.com> References: <571E4246.7020209@oracle.com> Message-ID: <571E4E69.4050303@oracle.com> +1 Thanks for spotting this, Andreas! Hannes Am 2016-04-25 um 18:13 schrieb Andreas Woess: > Please review: > http://cr.openjdk.java.net/~aw/8155025/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8155025 > > This is a bug introduced by JDK-8010803, so it doesn't affect jdk8. > > Thanks, > Andreas From florian.bruckner at 3kraft.com Tue Apr 26 09:53:23 2016 From: florian.bruckner at 3kraft.com (Florian Bruckner (3kraft)) Date: Tue, 26 Apr 2016 11:53:23 +0200 Subject: JDK-8148068 long is no longer a number Message-ID: <571F3A93.6010503@3kraft.com> Guys, you need to stop introducing changes like these into jdk8u. It has been the third or fourth time a change in Nashorn in jdk8u has broken our application. What broke this time was that we are passing a java epoch as long to nashorn and use this to construct a date from it (with moment.js) and do some calculations around this date. Because long is no longer a number, moment.js does no longer construct a (correct) date. Thanks for listening and sorry about the ranting. regards Florian From hannes.wallnoefer at oracle.com Tue Apr 26 09:58:25 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 26 Apr 2016 11:58:25 +0200 Subject: Review request for JDK-8134503: support ES6 parsing in Nashorn In-Reply-To: <8963506f-c124-9723-5217-78d096f38738@oracle.com> References: <571E0465.2060906@oracle.com> <8963506f-c124-9723-5217-78d096f38738@oracle.com> Message-ID: <571F3BC1.2050102@oracle.com> Thanks for the reviews. I uploaded a new webrev: http://cr.openjdk.java.net/~hannesw/8134503/webrev.01/ I left the copyright year as 2015, 2016 for those files I got with that date from Andreas, I think that's the correct thing to do. The change of endPosition for object literal property nodes is in fact more precise now. It used to be the end position of the property name, whereas now it is the end position of the whole property (including its value). Hannes Am 2016-04-25 um 14:19 schrieb Sundararajan Athijegannathan: > * new sources copyright year to be 2016 > > * can the new IR node classes be final? ClassNode etc.? > > * .EXPECTED files have new endPosition now. are we being precise now? > > +1 > > -Sundar > > On 4/25/2016 5:19 PM, Hannes Wallnoefer wrote: >> Please review JDK-8134503: support ES6 parsing in Nashorn >> >> http://cr.openjdk.java.net/~hannesw/8134503/webrev/ >> >> The original patch was contributed by Andreas Woess, I just did the >> integration into Nashorn tip. >> >> Thanks, >> Hannes From hannes.wallnoefer at oracle.com Tue Apr 26 10:13:34 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 26 Apr 2016 12:13:34 +0200 Subject: JDK-8148068 long is no longer a number In-Reply-To: <571F3A93.6010503@3kraft.com> References: <571F3A93.6010503@3kraft.com> Message-ID: <571F3F4E.3050007@oracle.com> Hi Florian, Sorry about that. When we made that change we were aware of the fact that it could break existing code. However, the behaviour we had (treating longs as JS numbers) also caused some very real bugs when numbers grew larger than 53 bits. After some back and forth we decided to solve this issue the way we did. Can you please point me to the function in moment.js that breaks? It would be interesting to see what that code does and whether there is something we can do about it. Regards, Hannes Am 2016-04-26 um 11:53 schrieb Florian Bruckner (3kraft): > Guys, > > > > you need to stop introducing changes like these into jdk8u. It has > been the third or fourth time a change in Nashorn in jdk8u has broken > our application. > > What broke this time was that we are passing a java epoch as long to > nashorn and use this to construct a date from it (with moment.js) and > do some calculations around this date. Because long is no longer a > number, moment.js does no longer construct a (correct) date. > > > > Thanks for listening and sorry about the ranting. > > regards > > Florian From florian.bruckner at 3kraft.com Tue Apr 26 11:07:18 2016 From: florian.bruckner at 3kraft.com (Florian Bruckner (3kraft)) Date: Tue, 26 Apr 2016 13:07:18 +0200 Subject: JDK-8148068 long is no longer a number In-Reply-To: <571F3F4E.3050007@oracle.com> References: <571F3A93.6010503@3kraft.com> <571F3F4E.3050007@oracle.com> Message-ID: <571F4BE6.5060509@3kraft.com> Hi Hannes, it is this one: http://momentjs.com/docs/#/parsing/unix-timestamp-milliseconds/ It looks quite straight forward to me. If the input is a number, try parsing as milliseconds epoch, if it is a string, try ISO 8601. We allow both types to be passed into the script and let moment.js decide how to handle it. With 8u92, when an epoch long is passed, moment constructs itself with the current time. So it is not that moment.js breaks - it is just different behavior that is triggered since 8u92 because the long we pass into the script is no longer a number. regards, Florian On 26.04.16 12:13, Hannes Wallnoefer wrote: > Hi Florian, > > Sorry about that. When we made that change we were aware of the fact that it could break existing > code. However, the behaviour we had (treating longs as JS numbers) also caused some very real bugs > when numbers grew larger than 53 bits. After some back and forth we decided to solve this issue > the way we did. > > Can you please point me to the function in moment.js that breaks? It would be interesting to see > what that code does and whether there is something we can do about it. > > Regards, > Hannes > > > Am 2016-04-26 um 11:53 schrieb Florian Bruckner (3kraft): >> Guys, >> >> >> >> you need to stop introducing changes like these into jdk8u. It has been the third or fourth time >> a change in Nashorn in jdk8u has broken our application. >> >> What broke this time was that we are passing a java epoch as long to nashorn and use this to >> construct a date from it (with moment.js) and do some calculations around this date. Because long >> is no longer a number, moment.js does no longer construct a (correct) date. >> >> >> >> Thanks for listening and sorry about the ranting. >> >> regards >> >> Florian > > -- Mobile: +43 699 102 53 901 | Phone: +43 1 9204549 113 | Fax: +43 1 9204549 3113 | 3kraft.com 3kraft IT GmbH & Co KG | Wasagasse 26/2 | 1090 Wien | ?sterreich | FN 333787 p (HG Wien) Komplement?r: 3kraft IT GmbH | Wasagasse 26/2 | 1090 Wien | ?sterreich | FN 333558 b (HG Wien) From sundararajan.athijegannathan at oracle.com Tue Apr 26 11:34:18 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 26 Apr 2016 17:04:18 +0530 Subject: Review request for JDK-8134503: support ES6 parsing in Nashorn In-Reply-To: <571F3BC1.2050102@oracle.com> References: <571E0465.2060906@oracle.com> <8963506f-c124-9723-5217-78d096f38738@oracle.com> <571F3BC1.2050102@oracle.com> Message-ID: <7dddd1c1-78d0-f6d6-5bf1-b5bce956cf93@oracle.com> +1 -Sundar On 4/26/2016 3:28 PM, Hannes Wallnoefer wrote: > Thanks for the reviews. I uploaded a new webrev: > > http://cr.openjdk.java.net/~hannesw/8134503/webrev.01/ > > I left the copyright year as 2015, 2016 for those files I got with > that date from Andreas, I think that's the correct thing to do. > > The change of endPosition for object literal property nodes is in fact > more precise now. It used to be the end position of the property name, > whereas now it is the end position of the whole property (including > its value). > > Hannes > > Am 2016-04-25 um 14:19 schrieb Sundararajan Athijegannathan: >> * new sources copyright year to be 2016 >> >> * can the new IR node classes be final? ClassNode etc.? >> >> * .EXPECTED files have new endPosition now. are we being precise now? >> >> +1 >> >> -Sundar >> >> On 4/25/2016 5:19 PM, Hannes Wallnoefer wrote: >>> Please review JDK-8134503: support ES6 parsing in Nashorn >>> >>> http://cr.openjdk.java.net/~hannesw/8134503/webrev/ >>> >>> The original patch was contributed by Andreas Woess, I just did the >>> integration into Nashorn tip. >>> >>> Thanks, >>> Hannes > From emilian.bold at gmail.com Tue Apr 26 19:10:02 2016 From: emilian.bold at gmail.com (Emilian Bold) Date: Tue, 26 Apr 2016 22:10:02 +0300 Subject: Nashorn comment nodes in the syntax tree Message-ID: Hello, NetBeans used a modified Rhino that had useful features for an IDE like comment nodes and parser-level sanitization. As far as I know there is no way to get the comments in the Nashorn Tree API (created as part of JEP 236) or in the jdk.nashorn.internal.ir Node subclasses. Obviously having access to comment contents and comment offsets is very useful. An IDE, for example, would provide code folding for the multiline comment. Am I missing some proper way to get this information? I believe an extra option for Parser.create() would be nice (plus a CommentTree and a visitComment method). --emi From sundararajan.athijegannathan at oracle.com Wed Apr 27 14:18:09 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 27 Apr 2016 19:48:09 +0530 Subject: Nashorn comment nodes in the syntax tree In-Reply-To: References: Message-ID: Hi, I filed an enhancement request: https://bugs.openjdk.java.net/browse/JDK-8155242 Thanks, -Sundar On 4/27/2016 12:40 AM, Emilian Bold wrote: > Hello, > > NetBeans used a modified Rhino that had useful features for an IDE like > comment nodes and parser-level sanitization. > > As far as I know there is no way to get the comments in the Nashorn Tree > API (created as part of JEP 236) or in the jdk.nashorn.internal.ir Node > subclasses. > > Obviously having access to comment contents and comment offsets is very > useful. An IDE, for example, would provide code folding for the multiline > comment. > > Am I missing some proper way to get this information? > > I believe an extra option for Parser.create() would be nice (plus a > CommentTree and a visitComment method). > > --emi