From sdeleuze at pivotal.io Mon Jun 1 12:05:23 2015 From: sdeleuze at pivotal.io (Sebastien Deleuze) Date: Mon, 1 Jun 2015 14:05:23 +0200 Subject: Data corruption with Nashorn + Handlebars and concurrent requests In-Reply-To: <5564099C.7080205@oracle.com> References: <55522F32.5060302@oracle.com> <5562D5A8.8010608@oracle.com> <55640881.6030401@oracle.com> <5564099C.7080205@oracle.com> Message-ID: See Handlebars developers feedback [1]. As suggested before, Handlerbars is not designed with concurrency in mind, but they may accept some pull requests to improve that if that means no regression for other regular users. I will try to have a look to at least identify what should be done and have an idea of the amount of work needed to fix that. [1] https://github.com/wycats/handlebars.js/issues/1031#issuecomment-107271075 On Tue, May 26, 2015 at 7:50 AM, A. Sundararajan < sundararajan.athijegannathan at oracle.com> wrote: > Oops. double negative :) > > /but the compiled handlebars function may not be MT-unsafe./ > > should have been > > "but the compiled handlebars function may not be MT-safe". > > -Sundar > > > On Tuesday 26 May 2015 11:15 AM, A. Sundararajan wrote: > >> Actually either the Handlebars.compile or the compiled function could be >> MT-unsafe. FWIW, I tried the following change to handlebars's render.js >> script: >> >> function renderHandlebars(template, model) { >> >> // Create a real Javascript Object from the model Map >> var data = {}; >> for (var k in model) { >> // Convert Java Iterable and List to real Javascript arrays >> if (model[k] instanceof Java.type("java.lang.Iterable")) { >> data[k] = Java.from(model[k]); >> } else { >> data[k] = model[k]; >> } >> } >> // TODO Manage compiled template cache >> var compiledTemplate = Handlebars.compile(template); >> >> // call compiled template function as synchronized >> // use Handlebars object as lock >> >> return Java.synchronized(function(data) { >> compiledTemplate(data); >> }, Handlebars); >> } >> >> With that change, it appears handlebars MT-usage seems fine [i.e., no >> exception seen]. This suggests that the Handlebars.compile itself is >> MT-safe but the compiled handlebars function may not be MT-unsafe. FYI. >> > > From attila.szegedi at oracle.com Mon Jun 1 12:44:03 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 1 Jun 2015 14:44:03 +0200 Subject: Review request for JDK-8066218: UTF-32LE mistakenly detected as UTF-16LE Message-ID: Please review JDK-8066218 "UTF-32LE mistakenly detected as UTF-16LE" at for Thanks, Attila. From sundararajan.athijegannathan at oracle.com Mon Jun 1 13:00:16 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 01 Jun 2015 18:30:16 +0530 Subject: Review request for JDK-8066218: UTF-32LE mistakenly detected as UTF-16LE In-Reply-To: References: Message-ID: <556C5760.4030209@oracle.com> +1 On Monday 01 June 2015 06:14 PM, Attila Szegedi wrote: > Please review JDK-8066218 "UTF-32LE mistakenly detected as UTF-16LE" at for > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Mon Jun 1 13:03:32 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 01 Jun 2015 18:33:32 +0530 Subject: Data corruption with Nashorn + Handlebars and concurrent requests In-Reply-To: References: <55522F32.5060302@oracle.com> <5562D5A8.8010608@oracle.com> <55640881.6030401@oracle.com> <5564099C.7080205@oracle.com> Message-ID: <556C5824.5090606@oracle.com> Okay, thanks for the notification. I'll close the bug for now -- we can re-open if there is any nashorn issue identified during the work you do on handlebars. Thanks, -Sundar On Monday 01 June 2015 05:35 PM, Sebastien Deleuze wrote: > See Handlebars developers feedback [1]. > > As suggested before, Handlerbars is not designed with concurrency in mind, > but they may accept some pull requests to improve that if that means no > regression for other regular users. > I will try to have a look to at least identify what should be done and have > an idea of the amount of work needed to fix that. > > [1] > https://github.com/wycats/handlebars.js/issues/1031#issuecomment-107271075 > > On Tue, May 26, 2015 at 7:50 AM, A. Sundararajan < > sundararajan.athijegannathan at oracle.com> wrote: > >> Oops. double negative :) >> >> /but the compiled handlebars function may not be MT-unsafe./ >> >> should have been >> >> "but the compiled handlebars function may not be MT-safe". >> >> -Sundar >> >> >> On Tuesday 26 May 2015 11:15 AM, A. Sundararajan wrote: >> >>> Actually either the Handlebars.compile or the compiled function could be >>> MT-unsafe. FWIW, I tried the following change to handlebars's render.js >>> script: >>> >>> function renderHandlebars(template, model) { >>> >>> // Create a real Javascript Object from the model Map >>> var data = {}; >>> for (var k in model) { >>> // Convert Java Iterable and List to real Javascript arrays >>> if (model[k] instanceof Java.type("java.lang.Iterable")) { >>> data[k] = Java.from(model[k]); >>> } else { >>> data[k] = model[k]; >>> } >>> } >>> // TODO Manage compiled template cache >>> var compiledTemplate = Handlebars.compile(template); >>> >>> // call compiled template function as synchronized >>> // use Handlebars object as lock >>> >>> return Java.synchronized(function(data) { >>> compiledTemplate(data); >>> }, Handlebars); >>> } >>> >>> With that change, it appears handlebars MT-usage seems fine [i.e., no >>> exception seen]. This suggests that the Handlebars.compile itself is >>> MT-safe but the compiled handlebars function may not be MT-unsafe. FYI. >>> >> From sundararajan.athijegannathan at oracle.com Mon Jun 1 13:27:45 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 01 Jun 2015 18:57:45 +0530 Subject: Bug? script context doesn't revert if changed during eval In-Reply-To: References: <555B2552.6000909@oracle.com> Message-ID: <556C5DD1.20108@oracle.com> Hi, Sorry for the delayed response. Thanks for the test program. Yes, I confirm that this is a bug. I ported your Scala program to java and filed an issue: https://bugs.openjdk.java.net/browse/JDK-8081609 Thanks, -Sundar On Tuesday 19 May 2015 07:06 PM, Dima Golubets wrote: > Sure, > > Here is the code (I have attached zipped sources too). > > > object Program extends App { > val factory = new NashornScriptEngineFactory > val engine = factory.getScriptEngine > > val globalBindings = engine.createBindings() > val engineBindings = engine.getBindings(ScriptContext.ENGINE_SCOPE) > > val context = new SimpleScriptContext() > context.setBindings(globalBindings, ScriptContext.GLOBAL_SCOPE) > context.setBindings(engineBindings, ScriptContext.ENGINE_SCOPE) > > engineBindings.put("program", this) > globalBindings.put("text", "initial text") > > engine.eval( > """ > |print(text); > |program.someMethod(); > |print(text); > | > """.stripMargin, context) > > /* I would expect the following text output: > initial text > another text > initial text > > However I get: > initial text > another text > another text > */ > > def someMethod() = { > > val globalBindings = engine.createBindings() > > // a context with a new global bindings, same engine bindings > val context = new SimpleScriptContext() > context.setBindings(globalBindings, ScriptContext.GLOBAL_SCOPE) > context.setBindings(engineBindings, ScriptContext.ENGINE_SCOPE) > > globalBindings.put("text", "another text") > > engine.eval("print(text)", context) > > } > } > > > On Tue, May 19, 2015 at 2:58 PM A. Sundararajan < > sundararajan.athijegannathan at oracle.com> wrote: > >> Will you please post simple test program demonstrating the problem >> you're facing? >> >> -Sundar >> >> Dima Golubets wrote: >>> Hi! >>> >>> I call engine.eval, which calls some Java code which in turn calls eval >>> again, but with another script context. However this new script context >>> gets up the call stack somehow and the rest of the javascript code >>> continues to execute with variables defined in that another context. >>> >>> Is it a bug, or eval inside eval is not supported? >>> >> From sundararajan.athijegannathan at oracle.com Mon Jun 1 16:03:37 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 01 Jun 2015 21:33:37 +0530 Subject: RFR 8081609: engine.eval call from a java method which was called from a previous engine.eval results in wrong ScriptContext being used. Message-ID: <556C8259.2040902@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8081609/ for https://bugs.openjdk.java.net/browse/JDK-8081609 Thanks, -Sundar From attila.szegedi at oracle.com Mon Jun 1 16:24:28 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 1 Jun 2015 18:24:28 +0200 Subject: RFR 8081609: engine.eval call from a java method which was called from a previous engine.eval results in wrong ScriptContext being used. In-Reply-To: <556C8259.2040902@oracle.com> References: <556C8259.2040902@oracle.com> Message-ID: <6191389F-DDB2-4078-AAF7-82F3C2A389D1@oracle.com> +1 > On Jun 1, 2015, at 6:03 PM, A. Sundararajan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8081609/ for https://bugs.openjdk.java.net/browse/JDK-8081609 > > Thanks, > -Sundar From joe.darcy at oracle.com Mon Jun 1 21:19:54 2015 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 01 Jun 2015 14:19:54 -0700 Subject: JDK 9 RFR of JDK-8075555:Add tiered testing definitions to the nashorn repo Message-ID: <556CCC7A.40108@oracle.com> Nashorn team, Please review these changes to regularize Nashorn regression testing infrastructure with the JDK tiered testing policy. [1] JDK-8075555:Add tiered testing definitions to the nashorn repo http://cr.openjdk.java.net/~darcy/8075555.0/ In brief, testing tiers are defined (with an empty tier 1 for Nashorn) and an empty problem list is added. When analogous changes are made in all the repositories, it will be possible to use a jtreg command like jtreg -exclude:ProblemList.txt [... other options...] :tier$N for any repo. Thanks, -Joe [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html From marcus.lagergren at oracle.com Tue Jun 2 06:56:15 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 2 Jun 2015 08:56:15 +0200 Subject: Review request for JDK-8066218: UTF-32LE mistakenly detected as UTF-16LE In-Reply-To: References: Message-ID: <1982C2D5-E054-4362-B520-9DAFAA69E568@oracle.com> +1 > On 01 Jun 2015, at 14:44, Attila Szegedi wrote: > > Please review JDK-8066218 "UTF-32LE mistakenly detected as UTF-16LE" at for > > Thanks, > Attila. From marcus.lagergren at oracle.com Tue Jun 2 06:56:32 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 2 Jun 2015 08:56:32 +0200 Subject: RFR 8081609: engine.eval call from a java method which was called from a previous engine.eval results in wrong ScriptContext being used. In-Reply-To: <556C8259.2040902@oracle.com> References: <556C8259.2040902@oracle.com> Message-ID: +1 > On 01 Jun 2015, at 18:03, A. Sundararajan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8081609/ for https://bugs.openjdk.java.net/browse/JDK-8081609 > > Thanks, > -Sundar From marcus.lagergren at oracle.com Tue Jun 2 06:56:56 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 2 Jun 2015 08:56:56 +0200 Subject: JDK 9 RFR of JDK-8075555:Add tiered testing definitions to the nashorn repo In-Reply-To: <556CCC7A.40108@oracle.com> References: <556CCC7A.40108@oracle.com> Message-ID: +1 > On 01 Jun 2015, at 23:19, joe darcy wrote: > > Nashorn team, > > Please review these changes to regularize Nashorn regression testing infrastructure with the JDK tiered testing policy. [1] > > JDK-8075555:Add tiered testing definitions to the nashorn repo > http://cr.openjdk.java.net/~darcy/8075555.0/ > > In brief, testing tiers are defined (with an empty tier 1 for Nashorn) and an empty problem list is added. > > When analogous changes are made in all the repositories, it will be possible to use a jtreg command like > > jtreg -exclude:ProblemList.txt [... other options...] :tier$N > > for any repo. > > Thanks, > > -Joe > > [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html From sundararajan.athijegannathan at oracle.com Tue Jun 2 07:12:16 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 02 Jun 2015 12:42:16 +0530 Subject: JDK 9 RFR of JDK-8075555:Add tiered testing definitions to the nashorn repo In-Reply-To: References: <556CCC7A.40108@oracle.com> Message-ID: <556D5750.4010308@oracle.com> +1 On Tuesday 02 June 2015 12:26 PM, Marcus Lagergren wrote: > +1 > >> On 01 Jun 2015, at 23:19, joe darcy wrote: >> >> Nashorn team, >> >> Please review these changes to regularize Nashorn regression testing infrastructure with the JDK tiered testing policy. [1] >> >> JDK-8075555:Add tiered testing definitions to the nashorn repo >> http://cr.openjdk.java.net/~darcy/8075555.0/ >> >> In brief, testing tiers are defined (with an empty tier 1 for Nashorn) and an empty problem list is added. >> >> When analogous changes are made in all the repositories, it will be possible to use a jtreg command like >> >> jtreg -exclude:ProblemList.txt [... other options...] :tier$N >> >> for any repo. >> >> Thanks, >> >> -Joe >> >> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html From michael.haupt at oracle.com Tue Jun 2 08:09:18 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 2 Jun 2015 10:09:18 +0200 Subject: RFR (XS): 8081604: rename ScriptingFunctions.tokenizeCommandLine Message-ID: Dear all, please review and sponsor this small refactoring fix: RFE: https://bugs.openjdk.java.net/browse/JDK-8081604 Changeset: http://cr.openjdk.java.net/~mhaupt/8081604/webrev.00/ Formerly, ScriptingFunctions.tokenizeCommandLine() was a private utility method. It is now public and used in TestFinder as well, which calls for a more generic name. The change refactors the method name, as well as its local variables. Tested with "ant test". Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | HotSpot Compiler Team Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Tue Jun 2 08:09:20 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 2 Jun 2015 10:09:20 +0200 Subject: RFR (XS): 8081603: erroneous dot file generated from Nashorn --print-code Message-ID: Dear all, please review and sponsor this small fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8081603 Changeset: http://cr.openjdk.java.net/~mhaupt/8081603/webrev.00/ When using the --print-code option with an output directory, dot files would sometimes contain lines reporting on caught exceptions. These are supposed to be part of the labels on graph nodes. The string would however end with a hard line break, which does not comply with dot label string formatting rules. The fix emits a dot compliant line break. Tested manually with dot. Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | HotSpot Compiler Team Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From sundararajan.athijegannathan at oracle.com Tue Jun 2 08:10:12 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 02 Jun 2015 13:40:12 +0530 Subject: RFR (XS): 8081604: rename ScriptingFunctions.tokenizeCommandLine In-Reply-To: References: Message-ID: <556D64E4.9040306@oracle.com> +1 On Tuesday 02 June 2015 01:39 PM, Michael Haupt wrote: > Dear all, > > please review and sponsor this small refactoring fix: > RFE: https://bugs.openjdk.java.net/browse/JDK-8081604 > Changeset: http://cr.openjdk.java.net/~mhaupt/8081604/webrev.00/ > > Formerly, ScriptingFunctions.tokenizeCommandLine() was a private utility method. It is now public and used in TestFinder as well, which calls for a more generic name. The change refactors the method name, as well as its local variables. > > Tested with "ant test". > > Thanks, > > Michael > From sundararajan.athijegannathan at oracle.com Tue Jun 2 08:11:05 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 02 Jun 2015 13:41:05 +0530 Subject: RFR (XS): 8081603: erroneous dot file generated from Nashorn --print-code In-Reply-To: References: Message-ID: <556D6519.3060701@oracle.com> +1 On Tuesday 02 June 2015 01:39 PM, Michael Haupt wrote: > Dear all, > > please review and sponsor this small fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8081603 > Changeset: http://cr.openjdk.java.net/~mhaupt/8081603/webrev.00/ > > When using the --print-code option with an output directory, dot files would sometimes contain lines reporting on caught exceptions. These are supposed to be part of the labels on graph nodes. The string would however end with a hard line break, which does not comply with dot label string formatting rules. The fix emits a dot compliant line break. > > Tested manually with dot. > > Thanks, > > Michael > From attila.szegedi at oracle.com Tue Jun 2 08:32:11 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 2 Jun 2015 10:32:11 +0200 Subject: RFR (XS): 8081603: erroneous dot file generated from Nashorn --print-code In-Reply-To: References: Message-ID: <1F0228D1-9353-49FD-A04D-4692D9D60C59@oracle.com> +1 > On Jun 2, 2015, at 10:09 AM, Michael Haupt wrote: > > Dear all, > > please review and sponsor this small fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8081603 > Changeset: http://cr.openjdk.java.net/~mhaupt/8081603/webrev.00/ > > When using the --print-code option with an output directory, dot files would sometimes contain lines reporting on caught exceptions. These are supposed to be part of the labels on graph nodes. The string would however end with a hard line break, which does not comply with dot label string formatting rules. The fix emits a dot compliant line break. > > Tested manually with dot. > > Thanks, > > Michael > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | HotSpot Compiler Team > Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany > Oracle is committed to developing practices and products that help protect the environment > From attila.szegedi at oracle.com Tue Jun 2 08:32:24 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 2 Jun 2015 10:32:24 +0200 Subject: RFR (XS): 8081604: rename ScriptingFunctions.tokenizeCommandLine In-Reply-To: <556D64E4.9040306@oracle.com> References: <556D64E4.9040306@oracle.com> Message-ID: <4F1972A3-47CB-4141-A928-12174E5FEDB0@oracle.com> +1 > On Jun 2, 2015, at 10:10 AM, A. Sundararajan wrote: > > +1 > > On Tuesday 02 June 2015 01:39 PM, Michael Haupt wrote: >> Dear all, >> >> please review and sponsor this small refactoring fix: >> RFE: https://bugs.openjdk.java.net/browse/JDK-8081604 >> Changeset: http://cr.openjdk.java.net/~mhaupt/8081604/webrev.00/ >> >> Formerly, ScriptingFunctions.tokenizeCommandLine() was a private utility method. It is now public and used in TestFinder as well, which calls for a more generic name. The change refactors the method name, as well as its local variables. >> >> Tested with "ant test". >> >> Thanks, >> >> Michael >> > From marcus.lagergren at oracle.com Tue Jun 2 08:32:08 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 2 Jun 2015 10:32:08 +0200 Subject: RFR (XS): 8081604: rename ScriptingFunctions.tokenizeCommandLine In-Reply-To: References: Message-ID: <2A164FFF-852C-414A-87E5-5457B0BCBEB8@oracle.com> +1 > On 02 Jun 2015, at 10:09, Michael Haupt wrote: > > Dear all, > > please review and sponsor this small refactoring fix: > RFE: https://bugs.openjdk.java.net/browse/JDK-8081604 > Changeset: http://cr.openjdk.java.net/~mhaupt/8081604/webrev.00/ > > Formerly, ScriptingFunctions.tokenizeCommandLine() was a private utility method. It is now public and used in TestFinder as well, which calls for a more generic name. The change refactors the method name, as well as its local variables. > > Tested with "ant test". > > Thanks, > > Michael > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | HotSpot Compiler Team > Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany > Oracle is committed to developing practices and products that help protect the environment > From marcus.lagergren at oracle.com Tue Jun 2 08:32:13 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 2 Jun 2015 10:32:13 +0200 Subject: RFR (XS): 8081603: erroneous dot file generated from Nashorn --print-code In-Reply-To: References: Message-ID: <8BA47E36-AADC-4D1F-B983-C8E86875289A@oracle.com> +1 > On 02 Jun 2015, at 10:09, Michael Haupt wrote: > > Dear all, > > please review and sponsor this small fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8081603 > Changeset: http://cr.openjdk.java.net/~mhaupt/8081603/webrev.00/ > > When using the --print-code option with an output directory, dot files would sometimes contain lines reporting on caught exceptions. These are supposed to be part of the labels on graph nodes. The string would however end with a hard line break, which does not comply with dot label string formatting rules. The fix emits a dot compliant line break. > > Tested manually with dot. > > Thanks, > > Michael > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | HotSpot Compiler Team > Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany > Oracle is committed to developing practices and products that help protect the environment > From attila.szegedi at oracle.com Tue Jun 2 11:54:30 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 2 Jun 2015 13:54:30 +0200 Subject: Review request for JDK-8066773: JSON-friendly wrapper for objects In-Reply-To: References: <5A6666C2-91B9-4DEF-9B69-8AD014A16725@oracle.com> <556860A7.6050607@oracle.com> Message-ID: <764E4C38-00AE-4911-879D-EBAEC0518D60@oracle.com> Folks, please review the 8u-dev backport at . The only change is that JSONListAdapter needs an explicit implementation of toNumber() method as in 8 JSObject interface can't have a default implementation of it. Thanks, Attila. > On May 29, 2015, at 4:34 PM, Jim Laskey (Oracle) wrote: > > +1 > >> On May 29, 2015, at 9:50 AM, A. Sundararajan wrote: >> >> +1 >> >> On Friday 29 May 2015 05:39 PM, Attila Szegedi wrote: >>> Please review JDK-8066773 "JSON-friendly wrapper for objects" at for >>> >>> Thanks, >>> Attila. >> > From michael.haupt at oracle.com Tue Jun 2 12:00:43 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 2 Jun 2015 14:00:43 +0200 Subject: RFR (S): 8080275: transparently download testng.jar for Nashorn testing Message-ID: <22F47234-16B8-450A-A033-804E5B8FF922@oracle.com> Dear all, please review and sponsor this fix: RFE: https://bugs.openjdk.java.net/browse/JDK-8080275 Webrev: http://cr.openjdk.java.net/~mhaupt/8080275/webrev.00 The Nashorn README file used to contain instructions for how to download and place testng.jar. This is now handled by the "ant externals" command. Tested by deleting testng.jar and running "ant externals", followed by tests. Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | HotSpot Compiler Team Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Tue Jun 2 12:00:46 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 2 Jun 2015 14:00:46 +0200 Subject: RFR (XS): 8081668: fix Nashorn ant externals command Message-ID: <2719586E-3BA7-450F-BDAC-046773BEB297@oracle.com> Dear all, please review and sponsor this small fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8081668 Webrev: http://cr.openjdk.java.net/~mhaupt/8081668/webrev.00 Recent changes in the Showdown project on Github led to dependencies no longer being available for download, which would lead to failures in fresh Nashorn workspaces. Falling back to a revision of the project that has these files fixes this. Tested in a fresh workspace. Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | HotSpot Compiler Team Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From sundararajan.athijegannathan at oracle.com Tue Jun 2 12:25:26 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 02 Jun 2015 17:55:26 +0530 Subject: Review request for JDK-8066773: JSON-friendly wrapper for objects In-Reply-To: <764E4C38-00AE-4911-879D-EBAEC0518D60@oracle.com> References: <5A6666C2-91B9-4DEF-9B69-8AD014A16725@oracle.com> <556860A7.6050607@oracle.com> <764E4C38-00AE-4911-879D-EBAEC0518D60@oracle.com> Message-ID: <556DA0B6.1030407@oracle.com> +1 On Tuesday 02 June 2015 05:24 PM, Attila Szegedi wrote: > Folks, please review the 8u-dev backport at . The only change is that JSONListAdapter needs an explicit implementation of toNumber() method as in 8 JSObject interface can't have a default implementation of it. > > Thanks, > Attila. > >> On May 29, 2015, at 4:34 PM, Jim Laskey (Oracle) wrote: >> >> +1 >> >>> On May 29, 2015, at 9:50 AM, A. Sundararajan wrote: >>> >>> +1 >>> >>> On Friday 29 May 2015 05:39 PM, Attila Szegedi wrote: >>>> Please review JDK-8066773 "JSON-friendly wrapper for objects" at for >>>> >>>> Thanks, >>>> Attila. From hannes.wallnoefer at oracle.com Tue Jun 2 12:26:41 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 02 Jun 2015 14:26:41 +0200 Subject: RFR (S): 8080275: transparently download testng.jar for Nashorn testing In-Reply-To: <22F47234-16B8-450A-A033-804E5B8FF922@oracle.com> References: <22F47234-16B8-450A-A033-804E5B8FF922@oracle.com> Message-ID: <556DA101.9030805@oracle.com> +1 Am 2015-06-02 um 14:00 schrieb Michael Haupt: > Dear all, > > please review and sponsor this fix: > RFE: https://bugs.openjdk.java.net/browse/JDK-8080275 > Webrev: http://cr.openjdk.java.net/~mhaupt/8080275/webrev.00 > > The Nashorn README file used to contain instructions for how to download and place testng.jar. This is now handled by the "ant externals" command. > > Tested by deleting testng.jar and running "ant externals", followed by tests. > > Thanks, > > Michael > From hannes.wallnoefer at oracle.com Tue Jun 2 12:26:52 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 02 Jun 2015 14:26:52 +0200 Subject: RFR (XS): 8081668: fix Nashorn ant externals command In-Reply-To: <2719586E-3BA7-450F-BDAC-046773BEB297@oracle.com> References: <2719586E-3BA7-450F-BDAC-046773BEB297@oracle.com> Message-ID: <556DA10C.7030906@oracle.com> +1 Am 2015-06-02 um 14:00 schrieb Michael Haupt: > Dear all, > > please review and sponsor this small fix: > Bug: https://bugs.openjdk.java.net/browse/JDK-8081668 > Webrev: http://cr.openjdk.java.net/~mhaupt/8081668/webrev.00 > > Recent changes in the Showdown project on Github led to dependencies no longer being available for download, which would lead to failures in fresh Nashorn workspaces. Falling back to a revision of the project that has these files fixes this. > > Tested in a fresh workspace. > > Thanks, > > Michael > From sundararajan.athijegannathan at oracle.com Tue Jun 2 12:27:13 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 02 Jun 2015 17:57:13 +0530 Subject: RFR (S): 8080275: transparently download testng.jar for Nashorn testing In-Reply-To: <22F47234-16B8-450A-A033-804E5B8FF922@oracle.com> References: <22F47234-16B8-450A-A033-804E5B8FF922@oracle.com> Message-ID: <556DA121.8060005@oracle.com> +1 On Tuesday 02 June 2015 05:30 PM, Michael Haupt wrote: > Dear all, > > please review and sponsor this fix: > RFE: https://bugs.openjdk.java.net/browse/JDK-8080275 > Webrev: http://cr.openjdk.java.net/~mhaupt/8080275/webrev.00 > > The Nashorn README file used to contain instructions for how to download and place testng.jar. This is now handled by the "ant externals" command. > > Tested by deleting testng.jar and running "ant externals", followed by tests. > > Thanks, > > Michael > From sundararajan.athijegannathan at oracle.com Tue Jun 2 12:27:42 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 02 Jun 2015 17:57:42 +0530 Subject: RFR (XS): 8081668: fix Nashorn ant externals command In-Reply-To: <2719586E-3BA7-450F-BDAC-046773BEB297@oracle.com> References: <2719586E-3BA7-450F-BDAC-046773BEB297@oracle.com> Message-ID: <556DA13E.2030604@oracle.com> +1 On Tuesday 02 June 2015 05:30 PM, Michael Haupt wrote: > Dear all, > > please review and sponsor this small fix: > Bug: https://bugs.openjdk.java.net/browse/JDK-8081668 > Webrev: http://cr.openjdk.java.net/~mhaupt/8081668/webrev.00 > > Recent changes in the Showdown project on Github led to dependencies no longer being available for download, which would lead to failures in fresh Nashorn workspaces. Falling back to a revision of the project that has these files fixes this. > > Tested in a fresh workspace. > > Thanks, > > Michael > From hannes.wallnoefer at oracle.com Tue Jun 2 13:14:19 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 02 Jun 2015 15:14:19 +0200 Subject: Review request for JDK-8066220: Fuzzing bug: MethodHandle bug (Object, Object) != (boolean)Object Message-ID: <556DAC2B.7060900@oracle.com> Please review JDK-8066220: Fuzzing bug: MethodHandle bug (Object,Object) != (boolean)Object: http://cr.openjdk.java.net/~hannesw/8066220/ Thanks, Hannes From attila.szegedi at oracle.com Tue Jun 2 14:43:44 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 2 Jun 2015 16:43:44 +0200 Subject: Review request for JDK-8066220: Fuzzing bug: MethodHandle bug (Object, Object) != (boolean)Object In-Reply-To: <556DAC2B.7060900@oracle.com> References: <556DAC2B.7060900@oracle.com> Message-ID: +1 > On Jun 2, 2015, at 3:14 PM, Hannes Wallnoefer wrote: > > Please review JDK-8066220: Fuzzing bug: MethodHandle bug (Object,Object) != (boolean)Object: > > http://cr.openjdk.java.net/~hannesw/8066220/ > > Thanks, > Hannes From sundararajan.athijegannathan at oracle.com Tue Jun 2 14:46:14 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 02 Jun 2015 20:16:14 +0530 Subject: Review request for JDK-8066220: Fuzzing bug: MethodHandle bug (Object, Object) != (boolean)Object In-Reply-To: <556DAC2B.7060900@oracle.com> References: <556DAC2B.7060900@oracle.com> Message-ID: <556DC1B6.2080005@oracle.com> +1 On Tuesday 02 June 2015 06:44 PM, Hannes Wallnoefer wrote: > Please review JDK-8066220: Fuzzing bug: MethodHandle bug > (Object,Object) != (boolean)Object: > > http://cr.openjdk.java.net/~hannesw/8066220/ > > Thanks, > Hannes From michael.haupt at oracle.com Tue Jun 2 14:58:05 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 2 Jun 2015 16:58:05 +0200 Subject: RFR (XS): 8081696: reduce dependency of Nashorn tests on external components Message-ID: <790BB114-8F73-4F12-AA7A-33595EA66254@oracle.com> Dear all, please review and sponsor this fix. RFE: https://bugs.openjdk.java.net/browse/JDK-8081696 Webrev: http://cr.openjdk.java.net/~mhaupt/8081696/webrev.00 It reduces the dependency of standard tests on externally downloaded components. TestNG, which is external and required for testing, is the only left dependency. Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | HotSpot Compiler Team Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From attila.szegedi at oracle.com Tue Jun 2 15:00:57 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 2 Jun 2015 17:00:57 +0200 Subject: RFR (XS): 8081696: reduce dependency of Nashorn tests on external components In-Reply-To: <790BB114-8F73-4F12-AA7A-33595EA66254@oracle.com> References: <790BB114-8F73-4F12-AA7A-33595EA66254@oracle.com> Message-ID: <2D1C955B-051C-4A91-96CA-399C39018648@oracle.com> +1 > On Jun 2, 2015, at 4:58 PM, Michael Haupt wrote: > > Dear all, > > please review and sponsor this fix. > RFE: https://bugs.openjdk.java.net/browse/JDK-8081696 > Webrev: http://cr.openjdk.java.net/~mhaupt/8081696/webrev.00 > > It reduces the dependency of standard tests on externally downloaded components. TestNG, which is external and required for testing, is the only left dependency. > > Thanks, > > Michael > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | HotSpot Compiler Team > Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany > Oracle is committed to developing practices and products that help protect the environment > From sundararajan.athijegannathan at oracle.com Tue Jun 2 15:04:34 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 02 Jun 2015 20:34:34 +0530 Subject: RFR (XS): 8081696: reduce dependency of Nashorn tests on external components In-Reply-To: <790BB114-8F73-4F12-AA7A-33595EA66254@oracle.com> References: <790BB114-8F73-4F12-AA7A-33595EA66254@oracle.com> Message-ID: <556DC602.9010305@oracle.com> +1 On Tuesday 02 June 2015 08:28 PM, Michael Haupt wrote: > Dear all, > > please review and sponsor this fix. > RFE: https://bugs.openjdk.java.net/browse/JDK-8081696 > Webrev: http://cr.openjdk.java.net/~mhaupt/8081696/webrev.00 > > It reduces the dependency of standard tests on externally downloaded components. TestNG, which is external and required for testing, is the only left dependency. > > Thanks, > > Michael > From marcus.lagergren at oracle.com Wed Jun 3 11:09:25 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 3 Jun 2015 13:09:25 +0200 Subject: Review request for JDK-8066773: JSON-friendly wrapper for objects In-Reply-To: <764E4C38-00AE-4911-879D-EBAEC0518D60@oracle.com> References: <5A6666C2-91B9-4DEF-9B69-8AD014A16725@oracle.com> <556860A7.6050607@oracle.com> <764E4C38-00AE-4911-879D-EBAEC0518D60@oracle.com> Message-ID: +1 > On 02 Jun 2015, at 13:54, Attila Szegedi wrote: > > Folks, please review the 8u-dev backport at . The only change is that JSONListAdapter needs an explicit implementation of toNumber() method as in 8 JSObject interface can't have a default implementation of it. > > Thanks, > Attila. > >> On May 29, 2015, at 4:34 PM, Jim Laskey (Oracle) wrote: >> >> +1 >> >>> On May 29, 2015, at 9:50 AM, A. Sundararajan wrote: >>> >>> +1 >>> >>> On Friday 29 May 2015 05:39 PM, Attila Szegedi wrote: >>>> Please review JDK-8066773 "JSON-friendly wrapper for objects" at for >>>> >>>> Thanks, >>>> Attila. >>> >> > From sundararajan.athijegannathan at oracle.com Wed Jun 3 12:21:37 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 03 Jun 2015 17:51:37 +0530 Subject: RFR 8081809: Missing final modifier in method parameters (nashorn code convention) Message-ID: <556EF151.5090301@oracle.com> Hi, Please review http://cr.openjdk.java.net/~sundar/8081809/ for https://bugs.openjdk.java.net/browse/JDK-8081809 Also fixing sample "find_nonfinals.js" to skip abstract, native methods and skip classes that result in ExceptionInInitializerError. Thanks, -Sundar From attila.szegedi at oracle.com Wed Jun 3 13:12:39 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 3 Jun 2015 15:12:39 +0200 Subject: RFR 8081809: Missing final modifier in method parameters (nashorn code convention) In-Reply-To: <556EF151.5090301@oracle.com> References: <556EF151.5090301@oracle.com> Message-ID: <90B2BADB-764D-4960-8065-BD7300BDE174@oracle.com> +1 > On Jun 3, 2015, at 2:21 PM, A. Sundararajan wrote: > > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8081809/ for https://bugs.openjdk.java.net/browse/JDK-8081809 > > Also fixing sample "find_nonfinals.js" to skip abstract, native methods and skip classes that result in ExceptionInInitializerError. > > Thanks, > -Sundar From hannes.wallnoefer at oracle.com Wed Jun 3 13:17:15 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 03 Jun 2015 15:17:15 +0200 Subject: RFR 8081809: Missing final modifier in method parameters (nashorn code convention) In-Reply-To: <556EF151.5090301@oracle.com> References: <556EF151.5090301@oracle.com> Message-ID: <556EFE5B.9090804@oracle.com> +1 Am 2015-06-03 um 14:21 schrieb A. Sundararajan: > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8081809/ for > https://bugs.openjdk.java.net/browse/JDK-8081809 > > Also fixing sample "find_nonfinals.js" to skip abstract, native > methods and skip classes that result in ExceptionInInitializerError. > > Thanks, > -Sundar From attila.szegedi at oracle.com Wed Jun 3 14:01:54 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 3 Jun 2015 16:01:54 +0200 Subject: Review request for JDK-8081813: JSONListAdapter should delegate its [[DefaultValue]] to wrapped object Message-ID: Please review JDK-8081813 "JSONListAdapter should delegate its [[DefaultValue]] to wrapped object" for for both 9 and 8u-dev. webrev for jdk9: webrev for jdk8u-dev: The change for 9 contains the addition of toNumber() as well, to make it consistent with state already in 8u-dev. The change for 8u-dev accounts for the lack of getDefaultValue() method on the JSObject interface in 8. Thanks, Attila. From marcus.lagergren at oracle.com Wed Jun 3 14:04:10 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 3 Jun 2015 16:04:10 +0200 Subject: Review request for JDK-8081813: JSONListAdapter should delegate its [[DefaultValue]] to wrapped object In-Reply-To: References: Message-ID: <84E877FA-1727-495A-B907-529D0C20EA76@oracle.com> +1 > On 03 Jun 2015, at 16:01, Attila Szegedi wrote: > > Please review JDK-8081813 "JSONListAdapter should delegate its [[DefaultValue]] to wrapped object" for for both 9 and 8u-dev. > > webrev for jdk9: > webrev for jdk8u-dev: > > The change for 9 contains the addition of toNumber() as well, to make it consistent with state already in 8u-dev. > The change for 8u-dev accounts for the lack of getDefaultValue() method on the JSObject interface in 8. > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Wed Jun 3 14:18:58 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 03 Jun 2015 19:48:58 +0530 Subject: Review request for JDK-8081813: JSONListAdapter should delegate its [[DefaultValue]] to wrapped object In-Reply-To: <84E877FA-1727-495A-B907-529D0C20EA76@oracle.com> References: <84E877FA-1727-495A-B907-529D0C20EA76@oracle.com> Message-ID: <556F0CD2.7010804@oracle.com> +1 On Wednesday 03 June 2015 07:34 PM, Marcus Lagergren wrote: > +1 > >> On 03 Jun 2015, at 16:01, Attila Szegedi wrote: >> >> Please review JDK-8081813 "JSONListAdapter should delegate its [[DefaultValue]] to wrapped object" for for both 9 and 8u-dev. >> >> webrev for jdk9: >> webrev for jdk8u-dev: >> >> The change for 9 contains the addition of toNumber() as well, to make it consistent with state already in 8u-dev. >> The change for 8u-dev accounts for the lack of getDefaultValue() method on the JSObject interface in 8. >> >> Thanks, >> Attila. From attila.szegedi at oracle.com Wed Jun 3 15:34:34 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 3 Jun 2015 17:34:34 +0200 Subject: Constant propagation in Nashorn compiler pipeline Message-ID: This is to initiate a discussion of (maybe) adding some form of constant propagation into Nashorn?s compiler pipeline. We currently do constant folding as a early phase (Lower), but we don?t have constant propagation. Michael Haupt expressed interest to tackle this, and I thought it?d be best to work out the design kinks here in the open so others can also chime in if they want. Scope ===== We?re talking about intra-function constant propagation over non-scoped local variables only. That should not be too hard to do. It could be somewhat similar to how LocalVariableTypesCalculator (LVTC) works, actually. LVTC currently does def-use tracking of type information from assignment to IdentNode objects and propagates the type information into use of IdentNode objects, through their shared Symbol. This is similar, except it could be used to propagate constant values. Of course, if we wanted, later we could even extend it to something else, e.g. range analysis, or really any other invariants. It?s just a matter of how much work are we comfortable having the compiler do. Implementation notes ================= By the way of implementation, we?d need a top-down (meaning, it operates on enterXxx() methods; possibly multipass for loops, same as LVTC) pass that keeps a Map and builds another Map. After it?s done, we?d need another pass, this time bottom-up (operating on leaveXxx() methods), replacing every IdentNode identified as having constant value with a LiteralNode instead. We should actually be even smarter about it, and have the top-down pass do another round of constant folding, using a generic Map instead of Map and evaluate expressions on the top-down pass and substitute already known constants opportunistically attempting to evaluate other expressions into constants. E.g. it could then collapse: var a = 3; var b = 2; var c = a + b; into var c = 5; (and eliminate a and b if they aren?t used elsewhere) We?d still need the bottom-up pass to perform the final replacement of folded constants. As such, the replacement of IdentNode with a LiteralNode would just become a special case of constant folding after propagation :-) An important element of the solution is to ensure that if at control flow join points a Symbol arrives containing different possible constant values on different branches (or a constant and a non-constant), then its const-ness has to be erased. Function literals ============ Also, we should figure out a way to represent a ?literal? for a function. We currently don?t do that. Constant propagation for function objects isn?t trivial as we can?t just replace every occurrence with a new FunctionNode; on the other hand it?d be nice to have as invocations of constant-propagated (proven never to change) functions could be performed without a guard, e.g. function () { function f() { ? } ? f(); Please review http://cr.openjdk.java.net/~sundar/8085810/ for https://bugs.openjdk.java.net/browse/JDK-8085810 Thanks, -Sundar From marcus.lagergren at oracle.com Thu Jun 4 12:45:22 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 4 Jun 2015 14:45:22 +0200 Subject: RFR 8085810: Return value of Objects.requireNonNull call can be used In-Reply-To: <557042E8.4080000@oracle.com> References: <557042E8.4080000@oracle.com> Message-ID: <7E0EFD77-B69C-4E55-BACE-83C40EF9CCF5@oracle.com> +1 > On 04 Jun 2015, at 14:22, A. Sundararajan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8085810/ for https://bugs.openjdk.java.net/browse/JDK-8085810 > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Fri Jun 5 08:44:17 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 05 Jun 2015 14:14:17 +0530 Subject: [8u60] approval request for 8081809: Missing final modifier in method parameters (nashorn code convention) Message-ID: <55716161.7060300@oracle.com> Please approve. bug: https://bugs.openjdk.java.net/browse/JDK-8081809 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-June/004664.html jdk8u-dev webrev: http://cr.openjdk.java.net/~sundar/8081809/8u60/webrev.00/ Not backported 'as is' - as there are jdk9 specific classes that don't exist in jdk8u-dev. But the subset backported is backported 'as is'. I'm still CC'ing nashorn-dev. Thanks, -Sundar From sean.coffey at oracle.com Fri Jun 5 08:47:31 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Fri, 05 Jun 2015 09:47:31 +0100 Subject: [8u60] approval request for 8081809: Missing final modifier in method parameters (nashorn code convention) In-Reply-To: <55716161.7060300@oracle.com> References: <55716161.7060300@oracle.com> Message-ID: <55716223.1040205@oracle.com> Approved pending peer code review. Regards, Sean. On 05/06/2015 09:44, A. Sundararajan wrote: > Please approve. > > bug: https://bugs.openjdk.java.net/browse/JDK-8081809 > jdk9 review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-June/004664.html > jdk8u-dev webrev: > http://cr.openjdk.java.net/~sundar/8081809/8u60/webrev.00/ > > Not backported 'as is' - as there are jdk9 specific classes that don't > exist in jdk8u-dev. But the subset backported is backported 'as is'. > I'm still CC'ing nashorn-dev. > > Thanks, > -Sundar From marcus.lagergren at oracle.com Fri Jun 5 09:13:40 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 5 Jun 2015 11:13:40 +0200 Subject: [8u60] approval request for 8081809: Missing final modifier in method parameters (nashorn code convention) In-Reply-To: <55716161.7060300@oracle.com> References: <55716161.7060300@oracle.com> Message-ID: +1 > On 05 Jun 2015, at 10:44, A. Sundararajan wrote: > > Please approve. > > bug: https://bugs.openjdk.java.net/browse/JDK-8081809 > jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-June/004664.html > jdk8u-dev webrev: http://cr.openjdk.java.net/~sundar/8081809/8u60/webrev.00/ > > Not backported 'as is' - as there are jdk9 specific classes that don't exist in jdk8u-dev. But the subset backported is backported 'as is'. I'm still CC'ing nashorn-dev. > > Thanks, > -Sundar From attila.szegedi at oracle.com Fri Jun 5 09:13:27 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 5 Jun 2015 11:13:27 +0200 Subject: [8u60] approval request for 8081809: Missing final modifier in method parameters (nashorn code convention) In-Reply-To: <55716223.1040205@oracle.com> References: <55716161.7060300@oracle.com> <55716223.1040205@oracle.com> Message-ID: <938C7837-9716-462F-AF04-E4331133D332@oracle.com> I approve these changes. > On Jun 5, 2015, at 10:47 AM, Se?n Coffey wrote: > > Approved pending peer code review. > > Regards, > Sean. > > On 05/06/2015 09:44, A. Sundararajan wrote: >> Please approve. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8081809 >> jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-June/004664.html >> jdk8u-dev webrev: http://cr.openjdk.java.net/~sundar/8081809/8u60/webrev.00/ >> >> Not backported 'as is' - as there are jdk9 specific classes that don't exist in jdk8u-dev. But the subset backported is backported 'as is'. I'm still CC'ing nashorn-dev. >> >> Thanks, >> -Sundar > From michael.haupt at oracle.com Fri Jun 5 09:38:12 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 5 Jun 2015 11:38:12 +0200 Subject: RFR (S): 8080087: Nashorn $ENV.PWD is originally undefined Message-ID: Dear all, please review and sponsor this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8080087 Webrev: http://cr.openjdk.java.net/~mhaupt/8080087/webrev.00 In Nashorn scripting mode, $ENV.PWD contains the current working directory. This is imported from the environment on unixy platforms. As the PWD variable is nonexistent on Windows by default, it needs to be set explicitly. Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | HotSpot Compiler Team Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From sundararajan.athijegannathan at oracle.com Fri Jun 5 09:49:27 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 05 Jun 2015 15:19:27 +0530 Subject: RFR (S): 8080087: Nashorn $ENV.PWD is originally undefined In-Reply-To: References: Message-ID: <557170A7.8070106@oracle.com> Hi, Can we do if (! env.containsKey(ScriptingFunctions.PWD_NAME)) { env.put(ScriptingFunctions.PWD_NAME, System.getProperty("user.dir"), scriptEnv._strict); } in Global.java instead of checking for Windows platform explicitly? -Sundar On Friday 05 June 2015 03:08 PM, Michael Haupt wrote: > Dear all, > > please review and sponsor this fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8080087 > Webrev: http://cr.openjdk.java.net/~mhaupt/8080087/webrev.00 > > In Nashorn scripting mode, $ENV.PWD contains the current working directory. This is imported from the environment on unixy platforms. As the PWD variable is nonexistent on Windows by default, it needs to be set explicitly. > > Thanks, > > Michael > From michael.haupt at oracle.com Fri Jun 5 09:57:46 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 5 Jun 2015 11:57:46 +0200 Subject: RFR (S): 8080087: Nashorn $ENV.PWD is originally undefined In-Reply-To: <557170A7.8070106@oracle.com> References: <557170A7.8070106@oracle.com> Message-ID: <4D086363-C767-4F70-82DF-13A9176C9203@oracle.com> Hi Sundar, I'm not tied to this solution. The code is as it is because it seems to be an issue of the Windows platform in particular. Would you think checking for key presence is more robust? Best, Michael > Am 05.06.2015 um 11:49 schrieb A. Sundararajan : > > Hi, > > Can we do > > if (! env.containsKey(ScriptingFunctions.PWD_NAME)) { > env.put(ScriptingFunctions.PWD_NAME, System.getProperty("user.dir"), scriptEnv._strict); > } > > in Global.java instead of checking for Windows platform explicitly? > > -Sundar > > On Friday 05 June 2015 03:08 PM, Michael Haupt wrote: >> Dear all, >> >> please review and sponsor this fix. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8080087 >> Webrev: http://cr.openjdk.java.net/~mhaupt/8080087/webrev.00 >> >> In Nashorn scripting mode, $ENV.PWD contains the current working directory. This is imported from the environment on unixy platforms. As the PWD variable is nonexistent on Windows by default, it needs to be set explicitly. >> >> Thanks, >> >> Michael >> > -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | HotSpot Compiler Team Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Fri Jun 5 10:04:44 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 5 Jun 2015 12:04:44 +0200 Subject: RFR (S): 8080087: Nashorn $ENV.PWD is originally undefined In-Reply-To: <4D086363-C767-4F70-82DF-13A9176C9203@oracle.com> References: <557170A7.8070106@oracle.com> <4D086363-C767-4F70-82DF-13A9176C9203@oracle.com> Message-ID: <025994BB-463F-4414-8D05-E0895C3C1159@oracle.com> Hi - anyway, alternative webrev: http://cr.openjdk.java.net/~mhaupt/8080087/webrev.01 - please pick. :-) Michael > Am 05.06.2015 um 11:57 schrieb Michael Haupt : > > Hi Sundar, > > I'm not tied to this solution. The code is as it is because it seems to be an issue of the Windows platform in particular. Would you think checking for key presence is more robust? > > Best, > > Michael > >> Am 05.06.2015 um 11:49 schrieb A. Sundararajan : >> >> Hi, >> >> Can we do >> >> if (! env.containsKey(ScriptingFunctions.PWD_NAME)) { >> env.put(ScriptingFunctions.PWD_NAME, System.getProperty("user.dir"), scriptEnv._strict); >> } >> >> in Global.java instead of checking for Windows platform explicitly? >> >> -Sundar >> >> On Friday 05 June 2015 03:08 PM, Michael Haupt wrote: >>> Dear all, >>> >>> please review and sponsor this fix. >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080087 >>> Webrev: http://cr.openjdk.java.net/~mhaupt/8080087/webrev.00 >>> >>> In Nashorn scripting mode, $ENV.PWD contains the current working directory. This is imported from the environment on unixy platforms. As the PWD variable is nonexistent on Windows by default, it needs to be set explicitly. >>> >>> Thanks, >>> >>> Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | HotSpot Compiler Team Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From sundararajan.athijegannathan at oracle.com Fri Jun 5 10:10:50 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 05 Jun 2015 15:40:50 +0530 Subject: RFR (S): 8080087: Nashorn $ENV.PWD is originally undefined In-Reply-To: <4D086363-C767-4F70-82DF-13A9176C9203@oracle.com> References: <557170A7.8070106@oracle.com> <4D086363-C767-4F70-82DF-13A9176C9203@oracle.com> Message-ID: <557175AA.8060407@oracle.com> Hi Michael, Just to avoid OS name prefix check (if possible) and also define "PWD" to be "user.dir" value on all platforms where it is not available from the OS environment. Thanks, -Sundar On Friday 05 June 2015 03:27 PM, Michael Haupt wrote: > Hi Sundar, > > I'm not tied to this solution. The code is as it is because it seems to be an issue of the Windows platform in particular. Would you think checking for key presence is more robust? > > Best, > > Michael > >> Am 05.06.2015 um 11:49 schrieb A. Sundararajan : >> >> Hi, >> >> Can we do >> >> if (! env.containsKey(ScriptingFunctions.PWD_NAME)) { >> env.put(ScriptingFunctions.PWD_NAME, System.getProperty("user.dir"), scriptEnv._strict); >> } >> >> in Global.java instead of checking for Windows platform explicitly? >> >> -Sundar >> >> On Friday 05 June 2015 03:08 PM, Michael Haupt wrote: >>> Dear all, >>> >>> please review and sponsor this fix. >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080087 >>> Webrev: http://cr.openjdk.java.net/~mhaupt/8080087/webrev.00 >>> >>> In Nashorn scripting mode, $ENV.PWD contains the current working directory. This is imported from the environment on unixy platforms. As the PWD variable is nonexistent on Windows by default, it needs to be set explicitly. >>> >>> Thanks, >>> >>> Michael >>> From sundararajan.athijegannathan at oracle.com Fri Jun 5 10:11:09 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 05 Jun 2015 15:41:09 +0530 Subject: RFR (S): 8080087: Nashorn $ENV.PWD is originally undefined In-Reply-To: <025994BB-463F-4414-8D05-E0895C3C1159@oracle.com> References: <557170A7.8070106@oracle.com> <4D086363-C767-4F70-82DF-13A9176C9203@oracle.com> <025994BB-463F-4414-8D05-E0895C3C1159@oracle.com> Message-ID: <557175BD.90500@oracle.com> +1 :) -Sundar On Friday 05 June 2015 03:34 PM, Michael Haupt wrote: > Hi - > > anyway, alternative webrev: http://cr.openjdk.java.net/~mhaupt/8080087/webrev.01 - please pick. :-) > > Michael > >> Am 05.06.2015 um 11:57 schrieb Michael Haupt : >> >> Hi Sundar, >> >> I'm not tied to this solution. The code is as it is because it seems to be an issue of the Windows platform in particular. Would you think checking for key presence is more robust? >> >> Best, >> >> Michael >> >>> Am 05.06.2015 um 11:49 schrieb A. Sundararajan : >>> >>> Hi, >>> >>> Can we do >>> >>> if (! env.containsKey(ScriptingFunctions.PWD_NAME)) { >>> env.put(ScriptingFunctions.PWD_NAME, System.getProperty("user.dir"), scriptEnv._strict); >>> } >>> >>> in Global.java instead of checking for Windows platform explicitly? >>> >>> -Sundar >>> >>> On Friday 05 June 2015 03:08 PM, Michael Haupt wrote: >>>> Dear all, >>>> >>>> please review and sponsor this fix. >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080087 >>>> Webrev: http://cr.openjdk.java.net/~mhaupt/8080087/webrev.00 >>>> >>>> In Nashorn scripting mode, $ENV.PWD contains the current working directory. This is imported from the environment on unixy platforms. As the PWD variable is nonexistent on Windows by default, it needs to be set explicitly. >>>> >>>> Thanks, >>>> >>>> Michael > From marcus.lagergren at oracle.com Fri Jun 5 10:41:30 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 5 Jun 2015 12:41:30 +0200 Subject: RFR (S): 8080087: Nashorn $ENV.PWD is originally undefined In-Reply-To: References: Message-ID: <2895C1B1-5FCF-49A1-BA72-B811DB84A9E3@oracle.com> +1 > On 05 Jun 2015, at 11:38, Michael Haupt wrote: > > Dear all, > > please review and sponsor this fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8080087 > Webrev: http://cr.openjdk.java.net/~mhaupt/8080087/webrev.00 > > In Nashorn scripting mode, $ENV.PWD contains the current working directory. This is imported from the environment on unixy platforms. As the PWD variable is nonexistent on Windows by default, it needs to be set explicitly. > > Thanks, > > Michael > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | HotSpot Compiler Team > Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany > Oracle is committed to developing practices and products that help protect the environment > From attila.szegedi at oracle.com Fri Jun 5 13:33:53 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 5 Jun 2015 15:33:53 +0200 Subject: RFR 8085810: Return value of Objects.requireNonNull call can be used In-Reply-To: <7E0EFD77-B69C-4E55-BACE-83C40EF9CCF5@oracle.com> References: <557042E8.4080000@oracle.com> <7E0EFD77-B69C-4E55-BACE-83C40EF9CCF5@oracle.com> Message-ID: <2D755084-5D8A-4F77-9EDA-AC81A61A15B9@oracle.com> +1 > On Jun 4, 2015, at 2:45 PM, Marcus Lagergren wrote: > > +1 > >> On 04 Jun 2015, at 14:22, A. Sundararajan wrote: >> >> Please review http://cr.openjdk.java.net/~sundar/8085810/ for https://bugs.openjdk.java.net/browse/JDK-8085810 >> >> Thanks, >> -Sundar > From magnus.ihse.bursie at oracle.com Fri Jun 5 14:07:20 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 05 Jun 2015 16:07:20 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) Message-ID: <5571AD18.7080701@oracle.com> This review request covers the main part of the work for JEP-223, the new version string format [1]. Basically, we'll call this release Java "9", instead of Java "1.9.0". This patch is a folding of all work that has been done so far in the branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly covers build changes, with some code changes in hotspot, jdk, nashorn and langtools that either are corresponding changes in the product code due to the compiler define flags changing from the build, or follow-up changes to handle the new format. The JEP-223 work is not finished by this patch. In fact, there are known issues remaining even after this patch, typically by code that reads the "java.version" property and tries to parse it. However, this patch is not directly destined for jdk9/dev, but will go into the special verona/stage forest. As for all patches destined for verona/stage it will be code reviewed as if going to jdk9/dev. Once in verona/stage it will bide its time, and it will be complemented with follow-up patches to address remaining issues. When all such issues are resolved and JEP-223 is fully implemented, all changes will be pushed at once (without further code reviews) into jdk9/dev. This patch has been contributed by Magnus Ihse Bursie, Kumar Srinivasan and Alejandro Murillo. Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 [1] http://openjdk.java.net/jeps/223 From sundararajan.athijegannathan at oracle.com Fri Jun 5 14:30:27 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 05 Jun 2015 20:00:27 +0530 Subject: [8u60] approval request for 8085810: Return value of Objects.requireNonNull call can be used Message-ID: <5571B283.9040501@oracle.com> Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8085810 jdk8u-dev webrev: http://cr.openjdk.java.net/~sundar/8085810/8u60/webrev.00/ jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-June/004671.html This is a code clean up fix. Apart from modular source layout difference, the backport leaves change in one jdk9 specific file (ParserImpl.java). All other changes are same. CC'ing nashorn team. Thanks, -Sundar From rob.mckenna at oracle.com Fri Jun 5 14:32:36 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 05 Jun 2015 15:32:36 +0100 Subject: [8u60] approval request for 8085810: Return value of Objects.requireNonNull call can be used In-Reply-To: <5571B283.9040501@oracle.com> References: <5571B283.9040501@oracle.com> Message-ID: <5571B304.2010507@oracle.com> Approved assuming the nashorn team are ok with it. -Rob On 05/06/15 15:30, A. Sundararajan wrote: > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8085810 > jdk8u-dev webrev: > http://cr.openjdk.java.net/~sundar/8085810/8u60/webrev.00/ > jdk9 review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-June/004671.html > > This is a code clean up fix. Apart from modular source layout > difference, the backport leaves change in one jdk9 specific file > (ParserImpl.java). All other changes are same. CC'ing nashorn team. > > Thanks, > -Sundar From attila.szegedi at oracle.com Fri Jun 5 14:39:16 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 5 Jun 2015 16:39:16 +0200 Subject: [8u60] approval request for 8085810: Return value of Objects.requireNonNull call can be used In-Reply-To: <5571B304.2010507@oracle.com> References: <5571B283.9040501@oracle.com> <5571B304.2010507@oracle.com> Message-ID: Yes, it?s ok. +1. > On Jun 5, 2015, at 4:32 PM, Rob McKenna wrote: > > Approved assuming the nashorn team are ok with it. > > -Rob > > On 05/06/15 15:30, A. Sundararajan wrote: >> Please approve. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8085810 >> jdk8u-dev webrev: >> http://cr.openjdk.java.net/~sundar/8085810/8u60/webrev.00/ >> jdk9 review thread: >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-June/004671.html >> >> This is a code clean up fix. Apart from modular source layout >> difference, the backport leaves change in one jdk9 specific file >> (ParserImpl.java). All other changes are same. CC'ing nashorn team. >> >> Thanks, >> -Sundar From sundararajan.athijegannathan at oracle.com Fri Jun 5 16:52:08 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 05 Jun 2015 22:22:08 +0530 Subject: RFR 8085802: Nashorn -nse option causes parse error on anonymous function definition Message-ID: <5571D3B8.4000901@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8085802/ for https://bugs.openjdk.java.net/browse/JDK-8085802 Thanks, -Sundar From marcus.lagergren at oracle.com Fri Jun 5 18:38:21 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 5 Jun 2015 20:38:21 +0200 Subject: RFR 8085802: Nashorn -nse option causes parse error on anonymous function definition In-Reply-To: <5571D3B8.4000901@oracle.com> References: <5571D3B8.4000901@oracle.com> Message-ID: <222092CF-A5D7-4DDC-86C9-8C8530714DB2@oracle.com> +1 > On 05 Jun 2015, at 18:52, A. Sundararajan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8085802/ for https://bugs.openjdk.java.net/browse/JDK-8085802 > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Mon Jun 8 03:03:12 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 08 Jun 2015 08:33:12 +0530 Subject: RFR 8085937: add autoimports sample script to easily explore Java classes in interactive mode Message-ID: <557505F0.9000601@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8085937/ for https://bugs.openjdk.java.net/browse/JDK-8085937 Thanks, -Sundar From michael.haupt at oracle.com Mon Jun 8 07:07:05 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 8 Jun 2015 09:07:05 +0200 Subject: RFR 8085937: add autoimports sample script to easily explore Java classes in interactive mode In-Reply-To: <557505F0.9000601@oracle.com> References: <557505F0.9000601@oracle.com> Message-ID: Hi Sundar, note there's no capital R in my review. > Am 08.06.2015 um 05:03 schrieb A. Sundararajan : > Please review http://cr.openjdk.java.net/~sundar/8085937/ for https://bugs.openjdk.java.net/browse/JDK-8085937 autoimports.js: There are some nits in the comment at the beginning of the file; here's an edit of the entire comment: It is tedious to import Java classes used in a script. Sometimes it is easier use simple names of java classes and have a script auto import Java classes. You can load this script at the start of an interactive jjs session or at the start of your script. This script defines a __noSuchProperty__ hook to auto import Java classes as needed and when they are referred to for the first time in your script. You can also call the "autoimports" function to print script statements that you need to use in your script, i.e., have the function generate a script to import Java classes used by your script so far. After running your script, you can call autoimports to get the exact Java imports you need and replace the autoimports load with the generated import statements (to avoid costly init of the autoimports script). autoimports.js, lines 136, 140: use === rather than ==? Other than that, no remarks! Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | HotSpot Compiler Team Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From marcus.lagergren at oracle.com Mon Jun 8 07:07:56 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 8 Jun 2015 09:07:56 +0200 Subject: RFR 8085937: add autoimports sample script to easily explore Java classes in interactive mode In-Reply-To: References: <557505F0.9000601@oracle.com> Message-ID: What Michael said. Otherwise +1 /M > On 08 Jun 2015, at 09:07, Michael Haupt wrote: > > Hi Sundar, > > note there's no capital R in my review. > >> Am 08.06.2015 um 05:03 schrieb A. Sundararajan : >> Please review http://cr.openjdk.java.net/~sundar/8085937/ for https://bugs.openjdk.java.net/browse/JDK-8085937 > > autoimports.js: There are some nits in the comment at the beginning of the file; here's an edit of the entire comment: > > It is tedious to import Java classes used in a script. Sometimes it is easier use simple names of java classes and have a script auto import Java classes. You can load this script at the start of an interactive jjs session or at the start of your script. This script defines a __noSuchProperty__ hook to auto import Java classes as > needed and when they are referred to for the first time in your script. You can also call the "autoimports" function to print script statements that you need to use in your script, i.e., have the function generate a script to import Java classes used by your script so far. After running your script, you can call autoimports to get the exact Java imports you need and replace the autoimports load with the generated import statements (to avoid costly init of the autoimports script). > > autoimports.js, lines 136, 140: use === rather than ==? > > Other than that, no remarks! > > Best, > > Michael > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | HotSpot Compiler Team > Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany > Oracle is committed to developing practices and products that help protect the environment > From attila.szegedi at oracle.com Mon Jun 8 07:42:58 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 8 Jun 2015 09:42:58 +0200 Subject: RFR 8085802: Nashorn -nse option causes parse error on anonymous function definition In-Reply-To: <5571D3B8.4000901@oracle.com> References: <5571D3B8.4000901@oracle.com> Message-ID: <732BEAF4-055A-4927-A911-EF17E54E5767@oracle.com> +1 > On Jun 5, 2015, at 6:52 PM, A. Sundararajan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8085802/ for https://bugs.openjdk.java.net/browse/JDK-8085802 > > Thanks, > -Sundar From attila.szegedi at oracle.com Mon Jun 8 07:45:59 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 8 Jun 2015 09:45:59 +0200 Subject: RFR 8085937: add autoimports sample script to easily explore Java classes in interactive mode In-Reply-To: References: <557505F0.9000601@oracle.com> Message-ID: <8BBC94DD-673F-44F9-9052-BAD8940E138C@oracle.com> +1 likewise with Michael?s observations. > On Jun 8, 2015, at 9:07 AM, Marcus Lagergren wrote: > > What Michael said. Otherwise +1 > > /M > >> On 08 Jun 2015, at 09:07, Michael Haupt wrote: >> >> Hi Sundar, >> >> note there's no capital R in my review. >> >>> Am 08.06.2015 um 05:03 schrieb A. Sundararajan : >>> Please review http://cr.openjdk.java.net/~sundar/8085937/ for https://bugs.openjdk.java.net/browse/JDK-8085937 >> >> autoimports.js: There are some nits in the comment at the beginning of the file; here's an edit of the entire comment: >> >> It is tedious to import Java classes used in a script. Sometimes it is easier use simple names of java classes and have a script auto import Java classes. You can load this script at the start of an interactive jjs session or at the start of your script. This script defines a __noSuchProperty__ hook to auto import Java classes as >> needed and when they are referred to for the first time in your script. You can also call the "autoimports" function to print script statements that you need to use in your script, i.e., have the function generate a script to import Java classes used by your script so far. After running your script, you can call autoimports to get the exact Java imports you need and replace the autoimports load with the generated import statements (to avoid costly init of the autoimports script). >> >> autoimports.js, lines 136, 140: use === rather than ==? >> >> Other than that, no remarks! >> >> Best, >> >> Michael >> >> -- >> >> >> Dr. Michael Haupt | Principal Member of Technical Staff >> Phone: +49 331 200 7277 | Fax: +49 331 200 7561 >> Oracle Java Platform Group | HotSpot Compiler Team >> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany >> Oracle is committed to developing practices and products that help protect the environment >> > From michael.haupt at oracle.com Mon Jun 8 08:34:24 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 8 Jun 2015 10:34:24 +0200 Subject: RFR (M): 8085885: address Javadoc warnings in Nashorn source code Message-ID: Dear all, please review and sponsor this (doc-only) change. RFE: https://bugs.openjdk.java.net/browse/JDK-8085885 Webrev: http://cr.openjdk.java.net/~mhaupt/8085885/webrev.00 This fixes Javadoc warnings, improves formatting in Javadoc generated from the affected files, and reformats them for on-screen reading. Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | HotSpot Compiler Team Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From sundararajan.athijegannathan at oracle.com Mon Jun 8 08:37:38 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 08 Jun 2015 14:07:38 +0530 Subject: RFR 8085937: add autoimports sample script to easily explore Java classes in interactive mode In-Reply-To: References: <557505F0.9000601@oracle.com> Message-ID: <55755452.8060608@oracle.com> Thanks for the review. I've edited comment as suggested. Updated review @ http://cr.openjdk.java.net/~sundar/8085937/webrev.01/ for reference. As for == vs === , for JS primitive String comparison both should be same. Thanks, -Sundar On Monday 08 June 2015 12:37 PM, Michael Haupt wrote: > Hi Sundar, > > note there's no capital R in my review. > >> Am 08.06.2015 um 05:03 schrieb A. Sundararajan : >> Please review http://cr.openjdk.java.net/~sundar/8085937/ for https://bugs.openjdk.java.net/browse/JDK-8085937 > autoimports.js: There are some nits in the comment at the beginning of the file; here's an edit of the entire comment: > > It is tedious to import Java classes used in a script. Sometimes it is easier use simple names of java classes and have a script auto import Java classes. You can load this script at the start of an interactive jjs session or at the start of your script. This script defines a __noSuchProperty__ hook to auto import Java classes as > needed and when they are referred to for the first time in your script. You can also call the "autoimports" function to print script statements that you need to use in your script, i.e., have the function generate a script to import Java classes used by your script so far. After running your script, you can call autoimports to get the exact Java imports you need and replace the autoimports load with the generated import statements (to avoid costly init of the autoimports script). > > autoimports.js, lines 136, 140: use === rather than ==? > > Other than that, no remarks! > > Best, > > Michael > From erik.joelsson at oracle.com Mon Jun 8 09:05:02 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 08 Jun 2015 11:05:02 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5571AD18.7080701@oracle.com> References: <5571AD18.7080701@oracle.com> Message-ID: <55755ABE.9010000@oracle.com> Hello, Looks pretty good. Found some typos: jdk_util.c: 99: specia_update_version jdk-version.m4: 31: assing 124, 132: --with--version-pre-base has a dash too many? I see this pattern consistently used though, am I missing something? /Erik On 2015-06-05 16:07, Magnus Ihse Bursie wrote: > This review request covers the main part of the work for JEP-223, the > new version string format [1]. Basically, we'll call this release Java > "9", instead of Java "1.9.0". > > This patch is a folding of all work that has been done so far in the > branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly > covers build changes, with some code changes in hotspot, jdk, nashorn > and langtools that either are corresponding changes in the product > code due to the compiler define flags changing from the build, or > follow-up changes to handle the new format. > > The JEP-223 work is not finished by this patch. In fact, there are > known issues remaining even after this patch, typically by code that > reads the "java.version" property and tries to parse it. However, this > patch is not directly destined for jdk9/dev, but will go into the > special verona/stage forest. As for all patches destined for > verona/stage it will be code reviewed as if going to jdk9/dev. Once in > verona/stage it will bide its time, and it will be complemented with > follow-up patches to address remaining issues. When all such issues > are resolved and JEP-223 is fully implemented, all changes will be > pushed at once (without further code reviews) into jdk9/dev. > > This patch has been contributed by Magnus Ihse Bursie, Kumar > Srinivasan and Alejandro Murillo. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > > [1] http://openjdk.java.net/jeps/223 > From hannes.wallnoefer at oracle.com Mon Jun 8 09:16:58 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 08 Jun 2015 11:16:58 +0200 Subject: RFR (M): 8085885: address Javadoc warnings in Nashorn source code In-Reply-To: References: Message-ID: <55755D8A.7040102@oracle.com> +1 I don't have a clear preference for some of the formatting changes (like blank lines between @param and other tags) but don't feel it's worth any bikeshedding :) Hannes Am 2015-06-08 um 10:34 schrieb Michael Haupt: > Dear all, > > please review and sponsor this (doc-only) change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8085885 > Webrev: http://cr.openjdk.java.net/~mhaupt/8085885/webrev.00 > > This fixes Javadoc warnings, improves formatting in Javadoc generated from the affected files, and reformats them for on-screen reading. > > Thanks, > > Michael > From Alan.Bateman at oracle.com Mon Jun 8 09:34:12 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Jun 2015 10:34:12 +0100 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5571AD18.7080701@oracle.com> References: <5571AD18.7080701@oracle.com> Message-ID: <55756194.3080506@oracle.com> On 05/06/2015 15:07, Magnus Ihse Bursie wrote: > This review request covers the main part of the work for JEP-223, the > new version string format [1]. Basically, we'll call this release Java > "9", instead of Java "1.9.0". > > This patch is a folding of all work that has been done so far in the > branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly > covers build changes, with some code changes in hotspot, jdk, nashorn > and langtools that either are corresponding changes in the product > code due to the compiler define flags changing from the build, or > follow-up changes to handle the new format. > > The JEP-223 work is not finished by this patch. In fact, there are > known issues remaining even after this patch, typically by code that > reads the "java.version" property and tries to parse it. However, this > patch is not directly destined for jdk9/dev, but will go into the > special verona/stage forest. As for all patches destined for > verona/stage it will be code reviewed as if going to jdk9/dev. Once in > verona/stage it will bide its time, and it will be complemented with > follow-up patches to address remaining issues. When all such issues > are resolved and JEP-223 is fully implemented, all changes will be > pushed at once (without further code reviews) into jdk9/dev. > > This patch has been contributed by Magnus Ihse Bursie, Kumar > Srinivasan and Alejandro Murillo. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 I looked through the code changes, skipping most of the make files :-) Version.java.template - the comment in jvmSecurityVersion() still talks about 1.6 and newer. Can this be replaced to just say that it returns the security version? Will the update_version and special_update_version fields eventually be dropped from the jvm_version_info stricture? Related, there seems to be a typo in the comment in jdk_util.c where it has "specia_update_version". The webrev shows a change to this comment in jvm.h: "Third, this file contains various I/O and network operations needed by the standard Java I/O and network APIs." I think this comment can be removed because those JVM_* functions were removed some time ago. Otherwise looks okay to me. -Alan. From marcus.lagergren at oracle.com Mon Jun 8 10:16:54 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 8 Jun 2015 12:16:54 +0200 Subject: RFR (M): 8085885: address Javadoc warnings in Nashorn source code In-Reply-To: References: Message-ID: <0EC7C792-1F2F-479C-90D7-6C3C69E0372F@oracle.com> +1 - Thanks for this cleanup! > On 08 Jun 2015, at 10:34, Michael Haupt wrote: > > Dear all, > > please review and sponsor this (doc-only) change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8085885 > Webrev: http://cr.openjdk.java.net/~mhaupt/8085885/webrev.00 > > This fixes Javadoc warnings, improves formatting in Javadoc generated from the affected files, and reformats them for on-screen reading. > > Thanks, > > Michael > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | HotSpot Compiler Team > Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany > Oracle is committed to developing practices and products that help protect the environment > From marcus.lagergren at oracle.com Mon Jun 8 10:17:20 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 8 Jun 2015 12:17:20 +0200 Subject: RFR 8085937: add autoimports sample script to easily explore Java classes in interactive mode In-Reply-To: <55755452.8060608@oracle.com> References: <557505F0.9000601@oracle.com> <55755452.8060608@oracle.com> Message-ID: +1 > On 08 Jun 2015, at 10:37, A. Sundararajan wrote: > > Thanks for the review. I've edited comment as suggested. Updated review @ > > http://cr.openjdk.java.net/~sundar/8085937/webrev.01/ > > for reference. As for == vs === , for JS primitive String comparison both should be same. > > Thanks, > -Sundar > > On Monday 08 June 2015 12:37 PM, Michael Haupt wrote: >> Hi Sundar, >> >> note there's no capital R in my review. >> >>> Am 08.06.2015 um 05:03 schrieb A. Sundararajan : >>> Please review http://cr.openjdk.java.net/~sundar/8085937/ for https://bugs.openjdk.java.net/browse/JDK-8085937 >> autoimports.js: There are some nits in the comment at the beginning of the file; here's an edit of the entire comment: >> >> It is tedious to import Java classes used in a script. Sometimes it is easier use simple names of java classes and have a script auto import Java classes. You can load this script at the start of an interactive jjs session or at the start of your script. This script defines a __noSuchProperty__ hook to auto import Java classes as >> needed and when they are referred to for the first time in your script. You can also call the "autoimports" function to print script statements that you need to use in your script, i.e., have the function generate a script to import Java classes used by your script so far. After running your script, you can call autoimports to get the exact Java imports you need and replace the autoimports load with the generated import statements (to avoid costly init of the autoimports script). >> >> autoimports.js, lines 136, 140: use === rather than ==? >> >> Other than that, no remarks! >> >> Best, >> >> Michael >> > From sundararajan.athijegannathan at oracle.com Mon Jun 8 11:56:41 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 08 Jun 2015 17:26:41 +0530 Subject: [8u60] 8085937: add autoimports sample script to easily explore Java classes in interactive mode Message-ID: <557582F9.4060502@oracle.com> Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8085937 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-June/004691.html jdk8u-dev webrev: http://cr.openjdk.java.net/~sundar/8085937/8u60/webrev.00/ Not backported 'as is' since there jrtfs file system walking cannot be used in jdk8. Using rt.jar walking instead. Rest of the autoimports.js is same code. CC'ing nashorn team for additional review. Thanks, -Sundar From marcus.lagergren at oracle.com Mon Jun 8 12:18:18 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 8 Jun 2015 14:18:18 +0200 Subject: [8u60] 8085937: add autoimports sample script to easily explore Java classes in interactive mode In-Reply-To: <557582F9.4060502@oracle.com> References: <557582F9.4060502@oracle.com> Message-ID: <3B7BFA28-9F51-4531-BB11-174CA8DF958E@oracle.com> +1 > On 08 Jun 2015, at 13:56, A. Sundararajan wrote: > > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8085937 > jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-June/004691.html > jdk8u-dev webrev: http://cr.openjdk.java.net/~sundar/8085937/8u60/webrev.00/ > > Not backported 'as is' since there jrtfs file system walking cannot be used in jdk8. Using rt.jar walking instead. Rest of the autoimports.js is same code. CC'ing nashorn team for additional review. > > Thanks, > -Sundar From rob.mckenna at oracle.com Mon Jun 8 12:21:09 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 08 Jun 2015 13:21:09 +0100 Subject: [8u60] 8085937: add autoimports sample script to easily explore Java classes in interactive mode In-Reply-To: <3B7BFA28-9F51-4531-BB11-174CA8DF958E@oracle.com> References: <557582F9.4060502@oracle.com> <3B7BFA28-9F51-4531-BB11-174CA8DF958E@oracle.com> Message-ID: <557588B5.2000207@oracle.com> Approved. -Rob On 08/06/15 13:18, Marcus Lagergren wrote: > +1 > >> On 08 Jun 2015, at 13:56, A. Sundararajan wrote: >> >> Please approve. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8085937 >> jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-June/004691.html >> jdk8u-dev webrev: http://cr.openjdk.java.net/~sundar/8085937/8u60/webrev.00/ >> >> Not backported 'as is' since there jrtfs file system walking cannot be used in jdk8. Using rt.jar walking instead. Rest of the autoimports.js is same code. CC'ing nashorn team for additional review. >> >> Thanks, >> -Sundar > From magnus.ihse.bursie at oracle.com Mon Jun 8 12:37:01 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 8 Jun 2015 14:37:01 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <55756194.3080506@oracle.com> References: <5571AD18.7080701@oracle.com> <55756194.3080506@oracle.com> Message-ID: <1136B10A-72A2-421D-8333-1943353F662C@oracle.com> > 8 jun 2015 kl. 11:34 skrev Alan Bateman : > >> On 05/06/2015 15:07, Magnus Ihse Bursie wrote: >> This review request covers the main part of the work for JEP-223, the new version string format [1]. Basically, we'll call this release Java "9", instead of Java "1.9.0". >> >> This patch is a folding of all work that has been done so far in the branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly covers build changes, with some code changes in hotspot, jdk, nashorn and langtools that either are corresponding changes in the product code due to the compiler define flags changing from the build, or follow-up changes to handle the new format. >> >> The JEP-223 work is not finished by this patch. In fact, there are known issues remaining even after this patch, typically by code that reads the "java.version" property and tries to parse it. However, this patch is not directly destined for jdk9/dev, but will go into the special verona/stage forest. As for all patches destined for verona/stage it will be code reviewed as if going to jdk9/dev. Once in verona/stage it will bide its time, and it will be complemented with follow-up patches to address remaining issues. When all such issues are resolved and JEP-223 is fully implemented, all changes will be pushed at once (without further code reviews) into jdk9/dev. >> >> This patch has been contributed by Magnus Ihse Bursie, Kumar Srinivasan and Alejandro Murillo. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > > I looked through the code changes, skipping most of the make files :-) > > Version.java.template - the comment in jvmSecurityVersion() still talks about 1.6 and newer. Can this be replaced to just say that it returns the security version? > > Will the update_version and special_update_version fields eventually be dropped from the jvm_version_info stricture? Related, there seems to be a typo in the comment in jdk_util.c where it has "specia_update_version". > > The webrev shows a change to this comment in jvm.h: > "Third, this file contains various I/O and network operations needed by the standard Java I/O and network APIs." > I think this comment can be removed because those JVM_* functions were removed some time ago. > > Otherwise looks okay to me. The API functions in Version.java and jvm.h are not finished. The specification in the JEP talks about a java.util.Version, that I presume will replace the sun.misc.Version, and that will fully implement an API to access the version string and all it's parts, according to the JEP definition. Also, the native interface will have to be changed to accommodate a version number with an arbitrarily number of dot separated parts. These changes will be done later on in the verona/stage forest. Are you ok with addressing these concerns at such a later time? /Magnus > > -Alan. From sundararajan.athijegannathan at oracle.com Mon Jun 8 12:55:17 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 08 Jun 2015 18:25:17 +0530 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <1136B10A-72A2-421D-8333-1943353F662C@oracle.com> References: <5571AD18.7080701@oracle.com> <55756194.3080506@oracle.com> <1136B10A-72A2-421D-8333-1943353F662C@oracle.com> Message-ID: <557590B5.8090906@oracle.com> +1 on Nashorn changes. -Sundar On Monday 08 June 2015 06:07 PM, Magnus Ihse Bursie wrote: >> 8 jun 2015 kl. 11:34 skrev Alan Bateman : >> >>> On 05/06/2015 15:07, Magnus Ihse Bursie wrote: >>> This review request covers the main part of the work for JEP-223, the new version string format [1]. Basically, we'll call this release Java "9", instead of Java "1.9.0". >>> >>> This patch is a folding of all work that has been done so far in the branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly covers build changes, with some code changes in hotspot, jdk, nashorn and langtools that either are corresponding changes in the product code due to the compiler define flags changing from the build, or follow-up changes to handle the new format. >>> >>> The JEP-223 work is not finished by this patch. In fact, there are known issues remaining even after this patch, typically by code that reads the "java.version" property and tries to parse it. However, this patch is not directly destined for jdk9/dev, but will go into the special verona/stage forest. As for all patches destined for verona/stage it will be code reviewed as if going to jdk9/dev. Once in verona/stage it will bide its time, and it will be complemented with follow-up patches to address remaining issues. When all such issues are resolved and JEP-223 is fully implemented, all changes will be pushed at once (without further code reviews) into jdk9/dev. >>> >>> This patch has been contributed by Magnus Ihse Bursie, Kumar Srinivasan and Alejandro Murillo. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 >>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >> I looked through the code changes, skipping most of the make files :-) >> >> Version.java.template - the comment in jvmSecurityVersion() still talks about 1.6 and newer. Can this be replaced to just say that it returns the security version? >> >> Will the update_version and special_update_version fields eventually be dropped from the jvm_version_info stricture? Related, there seems to be a typo in the comment in jdk_util.c where it has "specia_update_version". >> >> The webrev shows a change to this comment in jvm.h: >> "Third, this file contains various I/O and network operations needed by the standard Java I/O and network APIs." >> I think this comment can be removed because those JVM_* functions were removed some time ago. >> >> Otherwise looks okay to me. > The API functions in Version.java and jvm.h are not finished. The specification in the JEP talks about a java.util.Version, that I presume will replace the sun.misc.Version, and that will fully implement an API to access the version string and all it's parts, according to the JEP definition. Also, the native interface will have to be changed to accommodate a version number with an arbitrarily number of dot separated parts. These changes will be done later on in the verona/stage forest. > > Are you ok with addressing these concerns at such a later time? > > /Magnus > >> -Alan. From michael.haupt at oracle.com Mon Jun 8 14:54:04 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 8 Jun 2015 16:54:04 +0200 Subject: RFR(S): 8080490: add $EXECV command to Nashorn scripting mode Message-ID: <5066542A-B790-4409-9DD8-31716140D2AD@oracle.com> Dear all, please review and sponsor this change. RFE: https://bugs.openjdk.java.net/browse/JDK-8080490 Webrev: http://cr.openjdk.java.net/~mhaupt/8080490/webrev.00 The $EXEC command now accepts, in addition to the command and stdin strings, more arguments that can be passed as varargs or as an array. These are appended to the command line. Tested with test/test262parallel. Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | HotSpot Compiler Team Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From attila.szegedi at oracle.com Mon Jun 8 16:48:35 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 8 Jun 2015 18:48:35 +0200 Subject: Help us make Nashorn great: 8u60 Rampdown 2 draws near Message-ID: Dear Nashorn users, a significant deadline is approaching for JDK 8u60 (and by extension, Nashorn) in June, namely the Rampdown 2 milestone; it was announced at > and you can see the milestones at >. We would appreciate if you have the opportunity to test your own Nashorn-using software with current Early Access releases of 8u60 available at > (new builds are released frequently). Until Rampdown 2, it is easier for us to fix bugs and get the fixes in the 8u-dev repo so that it catches the 8u60 train. With Rampdown 2, stabilization begins and as a general rule in that phase only showstopper bugs will be considered. Thank You, Attila. From Alan.Bateman at oracle.com Mon Jun 8 20:41:09 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Jun 2015 21:41:09 +0100 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <1136B10A-72A2-421D-8333-1943353F662C@oracle.com> References: <5571AD18.7080701@oracle.com> <55756194.3080506@oracle.com> <1136B10A-72A2-421D-8333-1943353F662C@oracle.com> Message-ID: <5575FDE5.5020002@oracle.com> On 08/06/2015 13:37, Magnus Ihse Bursie wrote: > : > The API functions in Version.java and jvm.h are not finished. The specification in the JEP talks about a java.util.Version, that I presume will replace the sun.misc.Version, and that will fully implement an API to access the version string and all it's parts, according to the JEP definition. Also, the native interface will have to be changed to accommodate a version number with an arbitrarily number of dot separated parts. These changes will be done later on in the verona/stage forest. > > Are you ok with addressing these concerns at such a later time? > Sure, esp. since my comments are indeed in the area that isn't complete in this webrev. -Alan From joe.darcy at oracle.com Tue Jun 9 00:56:49 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 08 Jun 2015 17:56:49 -0700 Subject: FYI, make file support for tiered testing targets underway, JDK-8075571: Support tiered testing make targets Message-ID: <557639D1.60603@oracle.com> Hello Nashorn team, FYI, I have some in-progress changes to add Makefile support for tiered testing: JDK-8075571: Support tiered testing make targets http://cr.openjdk.java.net/~darcy/8075571.0/ For the Nashorn repo, this look like it would involve adding a Makefile to nashorn/test (a clone of the jaxp makefile with s/jaxp/nashorn/g). In addition, there would be some additions to TEST.groups consistent with updates planned for other repos. The review is happening on build-dev: http://mail.openjdk.java.net/pipermail/build-dev/2015-June/015133.html Thanks, -Joe From sundararajan.athijegannathan at oracle.com Tue Jun 9 05:15:21 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 09 Jun 2015 10:45:21 +0530 Subject: RFR 8086032: Add compiler error tests when syntax extensions are used with --no-syntax-extensions option Message-ID: <55767669.8000600@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8086032/ for https://bugs.openjdk.java.net/browse/JDK-8086032 Thanks, -Sundar From hannes.wallnoefer at oracle.com Tue Jun 9 08:14:51 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 09 Jun 2015 10:14:51 +0200 Subject: RFR 8086032: Add compiler error tests when syntax extensions are used with --no-syntax-extensions option In-Reply-To: <55767669.8000600@oracle.com> References: <55767669.8000600@oracle.com> Message-ID: <5576A07B.2040406@oracle.com> The "methods" function in javahelp.js should use str.lastIndexOf(']') to get the end of the string, otherwise an array return value or parameter will trip it up. I'm wondering why the terminating "undefined" is necessary. The load() function should really always return undefined, it does so in all other JavaScript shells. Even so, I'm not sure it is it correct that load returns the last declared function? Going to consult the spec about this. Otherwise +1, nice addition to the tests! Hannes Am 2015-06-09 um 07:15 schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8086032/ for > https://bugs.openjdk.java.net/browse/JDK-8086032 > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Tue Jun 9 08:19:09 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 09 Jun 2015 13:49:09 +0530 Subject: RFR 8086032: Add compiler error tests when syntax extensions are used with --no-syntax-extensions option In-Reply-To: <5576A07B.2040406@oracle.com> References: <55767669.8000600@oracle.com> <5576A07B.2040406@oracle.com> Message-ID: <5576A17D.3070600@oracle.com> On Tuesday 09 June 2015 01:44 PM, Hannes Wallnoefer wrote: > The "methods" function in javahelp.js should use str.lastIndexOf(']') > to get the end of the string, otherwise an array return value or > parameter will trip it up. Good find. lastIndexOf found something beyond the signature part.. hmm.. > > I'm wondering why the terminating "undefined" is necessary. The load() > function should really always return undefined, it does so in all > other JavaScript shells. Even so, I'm not sure it is it correct that > load returns the last declared function? Going to consult the spec > about this. Unfortunately, load of a script with definitions prints last function - which I think is a bug. undefined is a workaround to avoid printing last function. Thanks -Sundar > > Otherwise +1, nice addition to the tests! > > Hannes > > > Am 2015-06-09 um 07:15 schrieb A. Sundararajan: >> Please review http://cr.openjdk.java.net/~sundar/8086032/ for >> https://bugs.openjdk.java.net/browse/JDK-8086032 >> >> Thanks, >> -Sundar > From attila.szegedi at oracle.com Tue Jun 9 08:24:09 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 9 Jun 2015 10:24:09 +0200 Subject: RFR 8086032: Add compiler error tests when syntax extensions are used with --no-syntax-extensions option In-Reply-To: <55767669.8000600@oracle.com> References: <55767669.8000600@oracle.com> Message-ID: <0688D904-7DC0-4CB0-98C5-6609B42D33E3@oracle.com> +1 > On Jun 9, 2015, at 7:15 AM, A. Sundararajan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8086032/ for https://bugs.openjdk.java.net/browse/JDK-8086032 > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Tue Jun 9 08:43:22 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 09 Jun 2015 14:13:22 +0530 Subject: RFR 8086032: Add compiler error tests when syntax extensions are used with --no-syntax-extensions option In-Reply-To: <5576A07B.2040406@oracle.com> References: <55767669.8000600@oracle.com> <5576A07B.2040406@oracle.com> Message-ID: <5576A72A.4000402@oracle.com> Fixed that sample: http://cr.openjdk.java.net/~sundar/8086032/webrev.01/ PS. slightly different pattern of string for static vs instance methods.. Thanks, -Sundar On Tuesday 09 June 2015 01:44 PM, Hannes Wallnoefer wrote: > The "methods" function in javahelp.js should use str.lastIndexOf(']') > to get the end of the string, otherwise an array return value or > parameter will trip it up. > > I'm wondering why the terminating "undefined" is necessary. The load() > function should really always return undefined, it does so in all > other JavaScript shells. Even so, I'm not sure it is it correct that > load returns the last declared function? Going to consult the spec > about this. > > Otherwise +1, nice addition to the tests! > > Hannes > > > Am 2015-06-09 um 07:15 schrieb A. Sundararajan: >> Please review http://cr.openjdk.java.net/~sundar/8086032/ for >> https://bugs.openjdk.java.net/browse/JDK-8086032 >> >> Thanks, >> -Sundar > From hannes.wallnoefer at oracle.com Tue Jun 9 08:48:22 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 09 Jun 2015 10:48:22 +0200 Subject: RFR 8086032: Add compiler error tests when syntax extensions are used with --no-syntax-extensions option In-Reply-To: <5576A72A.4000402@oracle.com> References: <55767669.8000600@oracle.com> <5576A07B.2040406@oracle.com> <5576A72A.4000402@oracle.com> Message-ID: <5576A856.9000607@oracle.com> I didn't realize static methods use a different pattern. Looks good now. Hannes Am 2015-06-09 um 10:43 schrieb A. Sundararajan: > Fixed that sample: http://cr.openjdk.java.net/~sundar/8086032/webrev.01/ > > PS. slightly different pattern of string for static vs instance methods.. > > Thanks, > -Sundar > > On Tuesday 09 June 2015 01:44 PM, Hannes Wallnoefer wrote: >> The "methods" function in javahelp.js should use str.lastIndexOf(']') >> to get the end of the string, otherwise an array return value or >> parameter will trip it up. >> >> I'm wondering why the terminating "undefined" is necessary. The >> load() function should really always return undefined, it does so in >> all other JavaScript shells. Even so, I'm not sure it is it correct >> that load returns the last declared function? Going to consult the >> spec about this. >> >> Otherwise +1, nice addition to the tests! >> >> Hannes >> >> >> Am 2015-06-09 um 07:15 schrieb A. Sundararajan: >>> Please review http://cr.openjdk.java.net/~sundar/8086032/ for >>> https://bugs.openjdk.java.net/browse/JDK-8086032 >>> >>> Thanks, >>> -Sundar >> > From attila.szegedi at oracle.com Tue Jun 9 08:49:15 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 9 Jun 2015 10:49:15 +0200 Subject: RFR 8086032: Add compiler error tests when syntax extensions are used with --no-syntax-extensions option In-Reply-To: <5576A72A.4000402@oracle.com> References: <55767669.8000600@oracle.com> <5576A07B.2040406@oracle.com> <5576A72A.4000402@oracle.com> Message-ID: +1 on the .01 webrev. > On Jun 9, 2015, at 10:43 AM, A. Sundararajan wrote: > > Fixed that sample: http://cr.openjdk.java.net/~sundar/8086032/webrev.01/ > > PS. slightly different pattern of string for static vs instance methods.. > > Thanks, > -Sundar > > On Tuesday 09 June 2015 01:44 PM, Hannes Wallnoefer wrote: >> The "methods" function in javahelp.js should use str.lastIndexOf(']') to get the end of the string, otherwise an array return value or parameter will trip it up. >> >> I'm wondering why the terminating "undefined" is necessary. The load() function should really always return undefined, it does so in all other JavaScript shells. Even so, I'm not sure it is it correct that load returns the last declared function? Going to consult the spec about this. >> >> Otherwise +1, nice addition to the tests! >> >> Hannes >> >> >> Am 2015-06-09 um 07:15 schrieb A. Sundararajan: >>> Please review http://cr.openjdk.java.net/~sundar/8086032/ for https://bugs.openjdk.java.net/browse/JDK-8086032 >>> >>> Thanks, >>> -Sundar >> > From attila.szegedi at oracle.com Tue Jun 9 09:02:06 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 9 Jun 2015 11:02:06 +0200 Subject: RFR(S): 8080490: add $EXECV command to Nashorn scripting mode In-Reply-To: <5066542A-B790-4409-9DD8-31716140D2AD@oracle.com> References: <5066542A-B790-4409-9DD8-31716140D2AD@oracle.com> Message-ID: <5149CB41-AB17-42F5-98C4-A5834ECF63A6@oracle.com> +1 > On Jun 8, 2015, at 4:54 PM, Michael Haupt wrote: > > Dear all, > > please review and sponsor this change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8080490 > Webrev: http://cr.openjdk.java.net/~mhaupt/8080490/webrev.00 > > The $EXEC command now accepts, in addition to the command and stdin strings, more arguments that can be passed as varargs or as an array. These are appended to the command line. > > Tested with test/test262parallel. > > Thanks, > > Michael > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | HotSpot Compiler Team > Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany > Oracle is committed to developing practices and products that help protect the environment > From hannes.wallnoefer at oracle.com Tue Jun 9 09:09:33 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 09 Jun 2015 11:09:33 +0200 Subject: RFR(S): 8080490: add $EXECV command to Nashorn scripting mode In-Reply-To: <5066542A-B790-4409-9DD8-31716140D2AD@oracle.com> References: <5066542A-B790-4409-9DD8-31716140D2AD@oracle.com> Message-ID: <5576AD4D.8090007@oracle.com> +1 Am 2015-06-08 um 16:54 schrieb Michael Haupt: > Dear all, > > please review and sponsor this change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8080490 > Webrev: http://cr.openjdk.java.net/~mhaupt/8080490/webrev.00 > > The $EXEC command now accepts, in addition to the command and stdin strings, more arguments that can be passed as varargs or as an array. These are appended to the command line. > > Tested with test/test262parallel. > > Thanks, > > Michael > From mattk at meetup.com Fri Jun 5 15:08:11 2015 From: mattk at meetup.com (Matt Kime) Date: Fri, 5 Jun 2015 11:08:11 -0400 Subject: Data corruption with Nashorn + Handlebars and concurrent requests Message-ID: I'm curious if any progress has been made on isolating whatever isn't thread safe about handlebars template execution. I'm also working on using Handlebars.js inside nashorn however i'm doing a number of things different. i'm precompiling my templates using https://github.com/gruntjs/grunt-contrib-handlebars and then compile the js functions into cached bytecode. I haven't checked for threading issues yet but I'm glad i found this discussion so i know that i should. From daniel.daugherty at oracle.com Mon Jun 8 23:31:20 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 08 Jun 2015 17:31:20 -0600 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5571AD18.7080701@oracle.com> References: <5571AD18.7080701@oracle.com> Message-ID: <557625C8.5050200@oracle.com> > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 General comment: Not all copyright years were updated. General comment: It looks like support for the 'patch' value is not completely implemented through all the Makefiles. I didn't audit for this, but it's just my impression. common/autoconf/configure.ac No comments. common/autoconf/flags.m4 No comments. common/autoconf/generated-configure.sh There are multiple Copyright notices in this file. Why? L4076: # Verify that a given string represent a valid version number, and assing it to L4077: # a variable. Fixed two typos and reformat a bit: # Verify that a given string represents a valid version number, and # assigning it to a variable. L20186-20189: indent for the block is off L20256-20259: indent for the block is off L20262: as_fn_error $? "--with--version-string must have a value" "$LINENO" 5 The '--with--version...' part doesn't match previous usages where '--with-version...' is used L20275: # Unspecified numerical fields is interpreted as 0. Grammar: 'is interpreted' -> 'are interpreted' L20286: as_fn_error $? "Version string contains + but both 'BUILD' and 'OPT' is missing" "$LINENO" 5 Grammar: 'is missing' -> 'are missing' L20292: as_fn_error $? "--with--version-string fails to parse The '--with--version...' part doesn't match previous usages where '--with-version...' is used L20297-L20302: indent for the block is off L20307: as_fn_error $? "--with--version-pre-base must have a value" "$LINENO" 5 L20315: { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: --with--version-pre-base value... L20316: $as_echo "$as_me: WARNING: --with--version-pre-base value... The '--with--version...' part doesn't match previous usages where '--with-version...' is used L20327-20332: indent for the block is off L20337: as_fn_error $? "--with--version-pre-debuglevel must have... L20345: { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: --with--version-pre-debuglevel value... L20346: $as_echo "$as_me: WARNING: --with--version-pre-debuglevel value The '--with--version...' part doesn't match previous usages where '--with-version...' is used L20361-20366: indent for the block is off L20371: as_fn_error $? "--with--version-opt must have... L20379: { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: --with--version-opt value L20380: $as_echo "$as_me: WARNING: --with--version-opt value has been The '--with--version...' part doesn't match previous usages where '--with-version...' is used At this point, I'm going to stop pointing out the '--with-version...' and '--with--version...' differences; don't know which usage is right. L20388-L20388: indent is off by one L20388: username=`$ECHO "$USER" | $TR -d -c '[a-z][A-Z][0-9]'` This assumes that the "USER" variable is set. Should there be a check for "" and perhaps use "no_user_specified" or something like that? Perhaps the build setup always makes sure that "USER" is set to something. Don't know. L20395-L20400: indent for the block is off L20413-L20431: indent of all blocks in this range are off L20444-L20449: indent for the block is off L20457-L20475: indent of all blocks in this range are off L20486-L20491: indent for the block is off L20504-L20522: indent of all blocks in this range are off L20533-L20538: indent for the block is off L20551-L20569: indent of all blocks in this range are off L20580-L20585: indent for the block is off L20598-L20616: indent of all blocks in this range are off common/autoconf/help.m4 No comments. common/autoconf/jdk-options.m4 Don't know why the 'elliptic curve crypto implementation' support is relocated as part of this changeset, but ... No comments. common/autoconf/spec.gmk.in No comments. common/autoconf/version-numbers No comments. common/nb_native/nbproject/configurations.xml No comments. make/Images.gmk No comments. make/Install.gmk No comments. make/Javadoc.gmk Did you mean to remove the 'clean' target? make/JrtfsJar.gmk No comments. make/MacBundles.gmk No comments. make/jprt.properties No comments. hotspot/make/Makefile No comments. hotspot/make/aix/Makefile No comments. hotspot/make/aix/makefiles/buildtree.make No comments. hotspot/make/aix/makefiles/defs.make No comments. hotspot/make/aix/makefiles/vm.make No comments. hotspot/make/bsd/Makefile No comments. hotspot/make/bsd/makefiles/buildtree.make No comments. hotspot/make/bsd/makefiles/defs.make No comments. hotspot/make/bsd/makefiles/vm.make No comments. hotspot/make/defs.make No comments. hotspot/make/jdk_version No comments. hotspot/make/linux/Makefile No comments. hotspot/make/linux/makefiles/buildtree.make No comments. hotspot/make/linux/makefiles/defs.make No comments. hotspot/make/linux/makefiles/vm.make No comments. hotspot/make/solaris/Makefile No comments. hotspot/make/solaris/makefiles/buildtree.make No comments. hotspot/make/solaris/makefiles/defs.make No comments. hotspot/make/solaris/makefiles/sparcWorks.make No comments. hotspot/make/solaris/makefiles/vm.make No comments. hotspot/make/windows/build.make No comments. hotspot/make/windows/makefiles/compile.make No changes in the frames view. Update: udiff view shows a blank line deleted at the end of the file. hotspot/make/windows/makefiles/debug.make No comments. hotspot/make/windows/makefiles/defs.make No comments. hotspot/make/windows/makefiles/fastdebug.make No comments. hotspot/make/windows/makefiles/product.make No comments. hotspot/make/windows/makefiles/vm.make No comments. hotspot/make/windows/projectfiles/common/Makefile No comments. hotspot/src/share/vm/prims/jvm.h No comments. hotspot/src/share/vm/runtime/arguments.cpp No comments. hotspot/src/share/vm/runtime/java.cpp L661: void JDK_Version::fully_initialize( L662: uint8_t major, uint8_t minor, uint8_t security, uint8_t update) { L663: // This is only called when current is less than 1.6 and we've gotten Since you're ripping out vestigial version support, I think this function can go away since this is version 9 and newer. Don't really know for sure, but based on that comment... hotspot/src/share/vm/runtime/java.hpp No comments. hotspot/src/share/vm/runtime/vmStructs.cpp L1240: please make the 'int' parameter align like the rest. hotspot/src/share/vm/runtime/vm_version.cpp L84: void Abstract_VM_Version::initialize() { L85: // FIXME: Initialization can probably be removed now. I agree, but that would entail also removing the _initialized and the uses of it... Follow on bug fix? hotspot/src/share/vm/runtime/vm_version.hpp No comments. hotspot/test/runtime/6981737/Test6981737.java No comments. jdk/make/CompileDemos.gmk No comments. jdk/make/data/mainmanifest/manifest.mf No comments. jdk/make/gensrc/GensrcMisc.gmk No comments. jdk/make/launcher/Launcher-jdk.accessibility.gmk No comments. jdk/make/launcher/Launcher-jdk.pack200.gmk No comments. jdk/make/launcher/LauncherCommon.gmk No comments. jdk/make/lib/CoreLibraries.gmk No comments. jdk/src/java.base/share/classes/sun/misc/Version.java.template L149: * Returns the security version of the running JVM if it's 1.6 or newer This JavaDoc update is wrong, but it might not be important if sun.misc.Version class is going away. jdk/src/java.base/share/native/include/jvm.h No comments. jdk/src/java.base/share/native/launcher/defines.h No comments. jdk/src/java.base/share/native/launcher/main.c No comments. jdk/src/java.base/share/native/libjava/System.c No comments. jdk/src/java.base/share/native/libjava/Version.c No comments. jdk/src/java.base/share/native/libjava/jdk_util.c No comments. jdk/src/java.base/windows/native/common/version.rc No comments. jdk/src/java.desktop/windows/native/libawt/windows/awt.rc No comments. jdk/src/jdk.accessibility/windows/native/common/AccessBridgeStatusWindow.RC No comments. jdk/test/sun/misc/Version/Version.java No comments. langtools/make/gensrc/GensrcCommon.gmk No comments. langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java old L171: case "1.9": new L171: case "9": Should this logic support both versions? Will dropping "1.9" here prevent a pre-version changeset JVM from being dropped into a JDK for triage purposes? Granted we don't often triage 'javac' with different JVMs, but... langtools/test/tools/javac/options/modes/InfoOptsTest.java No comments. langtools/test/tools/javac/options/modes/SourceTargetTest.java No comments. nashorn/make/BuildNashorn.gmk No comments. nashorn/make/build.xml No comments. nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Version.java No comments. common/autoconf/jdk-version.m4 No comments. nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties.template nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties-template No comments. common/bin/test_builds.sh hotspot/make/jdk6_hotspot_distro No comments. Dan On 6/5/15 8:07 AM, Magnus Ihse Bursie wrote: > This review request covers the main part of the work for JEP-223, the > new version string format [1]. Basically, we'll call this release Java > "9", instead of Java "1.9.0". > > This patch is a folding of all work that has been done so far in the > branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly > covers build changes, with some code changes in hotspot, jdk, nashorn > and langtools that either are corresponding changes in the product > code due to the compiler define flags changing from the build, or > follow-up changes to handle the new format. > > The JEP-223 work is not finished by this patch. In fact, there are > known issues remaining even after this patch, typically by code that > reads the "java.version" property and tries to parse it. However, this > patch is not directly destined for jdk9/dev, but will go into the > special verona/stage forest. As for all patches destined for > verona/stage it will be code reviewed as if going to jdk9/dev. Once in > verona/stage it will bide its time, and it will be complemented with > follow-up patches to address remaining issues. When all such issues > are resolved and JEP-223 is fully implemented, all changes will be > pushed at once (without further code reviews) into jdk9/dev. > > This patch has been contributed by Magnus Ihse Bursie, Kumar > Srinivasan and Alejandro Murillo. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > > [1] http://openjdk.java.net/jeps/223 > From jan.lahoda at oracle.com Tue Jun 9 04:57:58 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 09 Jun 2015 06:57:58 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <557625C8.5050200@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> Message-ID: <55767256.3030802@oracle.com> On 9.6.2015 01:31, Daniel D. Daugherty wrote: > > > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java > > old L171: case "1.9": > new L171: case "9": > Should this logic support both versions? Will dropping > "1.9" here prevent a pre-version changeset JVM from > being dropped into a JDK for triage purposes? > > Granted we don't often triage 'javac' with different JVMs, but... > +1 on keeping both "1.9" and "9" here. javac can be used independently on the rest of JDK to some extent, so support for running it on older builds of JDK 9 seems reasonable to me. (I wonder if current JDK 9 javac should be prepared for the new version scheme in advance.) Jan From attila.szegedi at oracle.com Tue Jun 9 13:00:24 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 9 Jun 2015 15:00:24 +0200 Subject: Proposal for reworking Java adapters Message-ID: <3DC5D5AB-A91D-437C-B74A-6F0BACB36619@oracle.com> I?ve been thinking for a while about reworking the way our Java adapters work. Currently, Java adapters have a private final MethodHandle field for every function they might invoke from the object containing the implementation, and they populate those fields in their constructors by creating method handles for the script functions, bound to the implementation object. For smaller interfaces (e.g. SAMs) this is not a big deal, but for subclasses with many methods that could be overwritten, it can become O(n) costly to create and bind up to ?n? method handles whenever an instance is created. So, I was thinking of replacing this with a different scheme, where we only store the implementation object in a field. Initialization is O(1). We then emit the bodies of the adapter functions the same way we do a call from JS, e.g. for run(): ALOAD DUP INVOKEDYNAMIC dyn:getMethod|getProp|getElem:run INVOKEDYNAMIC dyn:call (with the proviso of also handling null/undefined from getMethod to either call super or throw an UnsupportedOperationException) Some of the benefits would include: smaller adapter classes (always just a single field for the object). FWIW, this'd also avoid absurdly extreme situations like this: > ability to invoke any callable that is member of the object, not just ScriptFunction ability to use type specialization. This is quite a big deal actually. A less known fact about Nashorn is that the way we're binding a function often includes another level of indirection, as we need to use a ?generic invoker? with its own call site that handles deoptimizing recompilation etc. So we actually box everything going into a ScriptFunction coming through a Java adapter. If we did this, we could ensure we emit dyn:call with relevant types (int/long/double/Object) and the linkage would also handle the deoptimizing recompilation as expected. However, there?s two possible drawbacks: we?ll be doing two dynamic operations on every invocation instead of one. Should not be a big deal, but we move the lookup from the constructor (one-time per constructor) to invocation. Of course, it isn?t any worse than doing the same thing from JS code, as JS code also always uses the lookup-then-call idiom anyway. we subtly change the behavior with regard to backwards compatibility. Namely, previously we had the functions bound to the instance at construction time and now we look them up at every invocation. Previously, changing the functions within the implementation object didn?t have any effect, while now reassigning a function will change the effect. That is, consider the small example program below: var impl = { run: function() { print("1") } }; var r = new java.lang.Runnable(impl); r.run(); impl.run = function() { print("2") }; r.run(); Currently, this prints 1 twice as the functions are bound into the adapter instance at its construction. If we implemented the change, it?ll print 1 then 2. That backwards incompatible change in the behavior is really the only reason why I feel we need to discuss this. I expect the vast majority of folks use object or function literals anyway, so the instance is effectively immutable and they wouldn?t be affected, e.g. new java.lang.Runnable(function() { print("1") }) or new java.lang.Runnable({ run: function() { print("1") } }) which are by far the most typical idioms, would be unaffected. What do people think? Attila. From magnus.ihse.bursie at oracle.com Tue Jun 9 13:12:19 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 09 Jun 2015 15:12:19 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <557625C8.5050200@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> Message-ID: <5576E633.9050503@oracle.com> Hi Daniel, Thank you for your thorough review! On 2015-06-09 01:31, Daniel D. Daugherty wrote: > > > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > > > General comment: Not all copyright years were updated. > General comment: It looks like support for the 'patch' value is not > completely > implemented through all the Makefiles. I didn't audit for this, > but it's > just my impression. You are basically correct. The makefiles all propagate the patch value where needed, but the actual source code changes in hotspot and jdk ignores the patch field as of now. This will be corrected in a later add-on patch, submitted by someone from the jdk and/or hotspot team rather than the build team. > > common/autoconf/generated-configure.sh > There are multiple Copyright notices in this file. Why? Oh dear, you've reviewed the generated file. :-& I'm really impressed by your effort! However, the generated-configure.sh file is automatically created by the autoconf framework from the rest of the files in common/autoconf/*, so we cannot direcly modify it's contents - only indirectly. The reason it's checked in, is that otherwise every user would need to generate it before being able to run configure. In build reviews, we usually either revert changes to generated-configure.sh before posting a review to hide it (and re-generate it before pushing), or we just ignore it during reviews. I should have done that, or pointed out that it was not needed nor possible to review when I cross-posted. I'm sorry. > > L4076: # Verify that a given string represent a valid version > number, and assing it to > L4077: # a variable. > Fixed two typos and reformat a bit: > # Verify that a given string represents a valid version > number, and > # assigning it to a variable. I'll put that fix in the source .m4 file instead. Thanks. > > L20262: as_fn_error $? "--with--version-string must have a > value" "$LINENO" 5 > The '--with--version...' part doesn't match previous usages where > '--with-version...' is used Yes, you're right. Erik pointed it out as well. It's a typo in the error message. It's all over the place due to copied code. I'll fix it in the source .m4 file. (As a side note, I have a half-finished follow-up patch that will reduce the amount of code duplication, but it requires some framework changes so it'll have to be a separate thing.) > > L20275: # Unspecified numerical fields is interpreted as 0. > Grammar: 'is interpreted' -> 'are interpreted' > > L20286: as_fn_error $? "Version string contains + but both > 'BUILD' and 'OPT' is missing" "$LINENO" 5 > Grammar: 'is missing' -> 'are missing' Those darn English plural forms! Why can't you all do as we sensible Swedes and get rid of them? ;-) (I'll fix) > > L20388: username=`$ECHO "$USER" | $TR -d -c '[a-z][A-Z][0-9]'` > This assumes that the "USER" variable is set. Should there > be a check for "" and perhaps use "no_user_specified" or > something like that? Perhaps the build setup always makes > sure that "USER" is set to something. Don't know. Hm. I think the worst thing that'll happen is that the username part of the opt string gets empty. This part is basically copied right off the old build, where we have relied on the $USER variable being present for all the time with no problems, so I think it's quite safe to assume. > > common/autoconf/jdk-options.m4 > Don't know why the 'elliptic curve crypto implementation' support > is relocated as part of this changeset, but ... It was incorrectly placed not at the top indentation level, but in the middle of the function definition where the old versioning code were handled. (Which, mostly by chance, happens to work in autoconf, but is really bad style). > make/Javadoc.gmk > Did you mean to remove the 'clean' target? Yep. Cleaning is done by the top-level Main.gmk makefile nowadays, that's just some dead code. > > hotspot/make/windows/makefiles/compile.make > No changes in the frames view. > Update: udiff view shows a blank line deleted at the end of the file. That's probably the result of some change going forth and then back again during development. But then again, removing extra blank linkes is not a bad thing. (jcheck unfortunately does not enforce any style checks for make files :-( so they tend to detoriate over time.) > > hotspot/src/share/vm/runtime/java.cpp > L661: void JDK_Version::fully_initialize( > L662: uint8_t major, uint8_t minor, uint8_t security, uint8_t > update) { > L663: // This is only called when current is less than 1.6 and > we've gotten > > Since you're ripping out vestigial version support, I think this > function can go away since this is version 9 and newer. Don't > really > know for sure, but based on that comment... It probably can, yes. This and other core changes to the actual .cpp/.java files will be addressed in a follow-up patch. > > hotspot/src/share/vm/runtime/java.hpp > No comments. > > hotspot/src/share/vm/runtime/vmStructs.cpp > L1240: please make the 'int' parameter align like the rest. Are you okay with defering such a change to a follow-up patch? It's likely the entire struct will need changes to be able to handle a theoretically arbitrarily long version number. > > hotspot/src/share/vm/runtime/vm_version.cpp > L84: void Abstract_VM_Version::initialize() { > L85: // FIXME: Initialization can probably be removed now. > I agree, but that would entail also removing the > _initialized and the uses of it... Follow on bug fix? Definitely follow on. > jdk/src/java.base/share/classes/sun/misc/Version.java.template > L149: * Returns the security version of the running JVM if > it's 1.6 or newer > This JavaDoc update is wrong, but it might not be important > if sun.misc.Version class is going away. I'm not sure if it's going to be replaced by, or just complemented by java.util.Version, but in any case it will need a follow-up patch to clean up this and other issues. > langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java > > old L171: case "1.9": > new L171: case "9": > Should this logic support both versions? Will dropping > "1.9" here prevent a pre-version changeset JVM from > being dropped into a JDK for triage purposes? > > Granted we don't often triage 'javac' with different JVMs, but... I'll defer that question to Kumar, who wrote that piece of code. My guess is that when Hotspot express was dropped, the ability to use a JVM from another JDK release bit rotteded away. /Magnus From daniel.daugherty at oracle.com Tue Jun 9 13:20:27 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 09 Jun 2015 07:20:27 -0600 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576E633.9050503@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> Message-ID: <5576E81B.8050703@oracle.com> On 6/9/15 7:12 AM, Magnus Ihse Bursie wrote: > Hi Daniel, > > Thank you for your thorough review! This was my (failing) attempt at a "fast pass" review... :-) > > On 2015-06-09 01:31, Daniel D. Daugherty wrote: >> > >> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >> >> >> General comment: Not all copyright years were updated. >> General comment: It looks like support for the 'patch' value is not >> completely >> implemented through all the Makefiles. I didn't audit for this, >> but it's >> just my impression. > > You are basically correct. The makefiles all propagate the patch value > where needed, but the actual source code changes in hotspot and jdk > ignores the patch field as of now. This will be corrected in a later > add-on patch, submitted by someone from the jdk and/or hotspot team > rather than the build team. > >> >> common/autoconf/generated-configure.sh >> There are multiple Copyright notices in this file. Why? > Oh dear, you've reviewed the generated file. :-& I'm really impressed > by your effort! Ahhh... now that you say it... it sounds familiar... I may have made this same mistake before. I'll try to remember next time. > However, the generated-configure.sh file is automatically created by > the autoconf framework from the rest of the files in > common/autoconf/*, so we cannot direcly modify it's contents - only > indirectly. The reason it's checked in, is that otherwise every user > would need to generate it before being able to run configure. In build > reviews, we usually either revert changes to generated-configure.sh > before posting a review to hide it (and re-generate it before > pushing), or we just ignore it during reviews. I should have done > that, or pointed out that it was not needed nor possible to review > when I cross-posted. I'm sorry. > >> >> L4076: # Verify that a given string represent a valid version >> number, and assing it to >> L4077: # a variable. >> Fixed two typos and reformat a bit: >> # Verify that a given string represents a valid version >> number, and >> # assigning it to a variable. > I'll put that fix in the source .m4 file instead. Thanks. >> >> L20262: as_fn_error $? "--with--version-string must have a >> value" "$LINENO" 5 >> The '--with--version...' part doesn't match previous usages >> where >> '--with-version...' is used > Yes, you're right. Erik pointed it out as well. It's a typo in the > error message. It's all over the place due to copied code. I'll fix it > in the source .m4 file. > > (As a side note, I have a half-finished follow-up patch that will > reduce the amount of code duplication, but it requires some framework > changes so it'll have to be a separate thing.) > >> >> L20275: # Unspecified numerical fields is interpreted as 0. >> Grammar: 'is interpreted' -> 'are interpreted' >> >> L20286: as_fn_error $? "Version string contains + but >> both 'BUILD' and 'OPT' is missing" "$LINENO" 5 >> Grammar: 'is missing' -> 'are missing' > Those darn English plural forms! Why can't you all do as we sensible > Swedes and get rid of them? ;-) > > (I'll fix) > >> >> L20388: username=`$ECHO "$USER" | $TR -d -c >> '[a-z][A-Z][0-9]'` >> This assumes that the "USER" variable is set. Should there >> be a check for "" and perhaps use "no_user_specified" or >> something like that? Perhaps the build setup always makes >> sure that "USER" is set to something. Don't know. > Hm. I think the worst thing that'll happen is that the username part > of the opt string gets empty. This part is basically copied right off > the old build, where we have relied on the $USER variable being > present for all the time with no problems, so I think it's quite safe > to assume. >> >> common/autoconf/jdk-options.m4 >> Don't know why the 'elliptic curve crypto implementation' support >> is relocated as part of this changeset, but ... > It was incorrectly placed not at the top indentation level, but in the > middle of the function definition where the old versioning code were > handled. (Which, mostly by chance, happens to work in autoconf, but is > really bad style). > >> make/Javadoc.gmk >> Did you mean to remove the 'clean' target? > Yep. Cleaning is done by the top-level Main.gmk makefile nowadays, > that's just some dead code. > >> >> hotspot/make/windows/makefiles/compile.make >> No changes in the frames view. >> Update: udiff view shows a blank line deleted at the end of the >> file. > > That's probably the result of some change going forth and then back > again during development. But then again, removing extra blank linkes > is not a bad thing. (jcheck unfortunately does not enforce any style > checks for make files :-( so they tend to detoriate over time.) > >> >> hotspot/src/share/vm/runtime/java.cpp >> L661: void JDK_Version::fully_initialize( >> L662: uint8_t major, uint8_t minor, uint8_t security, uint8_t >> update) { >> L663: // This is only called when current is less than 1.6 and >> we've gotten >> >> Since you're ripping out vestigial version support, I think this >> function can go away since this is version 9 and newer. Don't >> really >> know for sure, but based on that comment... > It probably can, yes. This and other core changes to the actual > .cpp/.java files will be addressed in a follow-up patch. >> >> hotspot/src/share/vm/runtime/java.hpp >> No comments. >> >> hotspot/src/share/vm/runtime/vmStructs.cpp >> L1240: please make the 'int' parameter align like the rest. > Are you okay with defering such a change to a follow-up patch? Yes. > It's likely the entire struct will need changes to be able to handle a > theoretically arbitrarily long version number. > >> >> hotspot/src/share/vm/runtime/vm_version.cpp >> L84: void Abstract_VM_Version::initialize() { >> L85: // FIXME: Initialization can probably be removed now. >> I agree, but that would entail also removing the >> _initialized and the uses of it... Follow on bug fix? > Definitely follow on. > >> jdk/src/java.base/share/classes/sun/misc/Version.java.template >> L149: * Returns the security version of the running JVM if >> it's 1.6 or newer >> This JavaDoc update is wrong, but it might not be important >> if sun.misc.Version class is going away. > I'm not sure if it's going to be replaced by, or just complemented by > java.util.Version, but in any case it will need a follow-up patch to > clean up this and other issues. >> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >> >> old L171: case "1.9": >> new L171: case "9": >> Should this logic support both versions? Will dropping >> "1.9" here prevent a pre-version changeset JVM from >> being dropped into a JDK for triage purposes? >> >> Granted we don't often triage 'javac' with different JVMs, >> but... > I'll defer that question to Kumar, who wrote that piece of code. My > guess is that when Hotspot express was dropped, the ability to use a > JVM from another JDK release bit rotteded away. > > /Magnus Dan From claes.redestad at oracle.com Tue Jun 9 13:26:27 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 09 Jun 2015 15:26:27 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576E633.9050503@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> Message-ID: <5576E983.5020902@oracle.com> On 2015-06-09 15:12, Magnus Ihse Bursie wrote: >> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >> >> old L171: case "1.9": >> new L171: case "9": >> Should this logic support both versions? Will dropping >> "1.9" here prevent a pre-version changeset JVM from >> being dropped into a JDK for triage purposes? >> >> Granted we don't often triage 'javac' with different JVMs, >> but... > I'll defer that question to Kumar, who wrote that piece of code. My > guess is that when Hotspot express was dropped, the ability to use a > JVM from another JDK release bit rotteded away. > > /Magnus While we know there's no guarantee that swapping in an older VM will work, in the face of a regression in a promoted build we still routinely (automatically, even) swap out the VM with a recent VM to get a rough estimate of whether the regression was caused by a HotSpot or JDK/tools change, mostly since this currently saves us time in narrowing down the changes to bisect over/investigate. So, there's at least some value in not intentionally breaking build-to-build backwards compatibility, but we don't expect it to always work and wouldn't make much fuss about it breaking. If an extra case "1.9" is all it takes to make it work with last week's VM, however... /Claes From magnus.ihse.bursie at oracle.com Tue Jun 9 13:36:55 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 09 Jun 2015 15:36:55 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576E983.5020902@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E983.5020902@oracle.com> Message-ID: <5576EBF7.40607@oracle.com> On 2015-06-09 15:26, Claes Redestad wrote: > On 2015-06-09 15:12, Magnus Ihse Bursie wrote: >>> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >>> >>> old L171: case "1.9": >>> new L171: case "9": >>> Should this logic support both versions? Will dropping >>> "1.9" here prevent a pre-version changeset JVM from >>> being dropped into a JDK for triage purposes? >>> >>> Granted we don't often triage 'javac' with different JVMs, >>> but... >> I'll defer that question to Kumar, who wrote that piece of code. My >> guess is that when Hotspot express was dropped, the ability to use a >> JVM from another JDK release bit rotteded away. >> >> /Magnus > > While we know there's no guarantee that swapping in an older VM will > work, in the face of a regression in a promoted build we still > routinely (automatically, even) swap out the VM with a recent VM to > get a rough estimate of whether the regression was caused by a HotSpot > or JDK/tools change, mostly since this currently saves us time in > narrowing down the changes to bisect over/investigate. So, there's at > least some value in not intentionally breaking build-to-build > backwards compatibility, but we don't expect it to always work and > wouldn't make much fuss about it breaking. If an extra case "1.9" is > all it takes to make it work with last week's VM, however... Actually, I think I messed up a bit there. I believe the real question here was not about mixing different versions of Hotspot and the JDK, but mixing different versions of javac and the JDK. I think. :) /Magnus From magnus.ihse.bursie at oracle.com Tue Jun 9 13:52:20 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 09 Jun 2015 15:52:20 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576E81B.8050703@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> Message-ID: <5576EF94.3010500@oracle.com> Here's an updated webrev, which fixes the typos that were pointed out by reviewers: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ And here's a (much simpler) delta webrev which shows just these changes: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch-delta-01/webrev.01/ /Magnus On 2015-06-09 15:20, Daniel D. Daugherty wrote: > On 6/9/15 7:12 AM, Magnus Ihse Bursie wrote: >> Hi Daniel, >> >> Thank you for your thorough review! > > This was my (failing) attempt at a "fast pass" review... :-) > > >> >> On 2015-06-09 01:31, Daniel D. Daugherty wrote: >>> > >>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >>> >>> >>> General comment: Not all copyright years were updated. >>> General comment: It looks like support for the 'patch' value is not >>> completely >>> implemented through all the Makefiles. I didn't audit for this, >>> but it's >>> just my impression. >> >> You are basically correct. The makefiles all propagate the patch >> value where needed, but the actual source code changes in hotspot and >> jdk ignores the patch field as of now. This will be corrected in a >> later add-on patch, submitted by someone from the jdk and/or hotspot >> team rather than the build team. >> >>> >>> common/autoconf/generated-configure.sh >>> There are multiple Copyright notices in this file. Why? >> Oh dear, you've reviewed the generated file. :-& I'm really impressed >> by your effort! > > Ahhh... now that you say it... it sounds familiar... I may have > made this same mistake before. I'll try to remember next time. > > >> However, the generated-configure.sh file is automatically created by >> the autoconf framework from the rest of the files in >> common/autoconf/*, so we cannot direcly modify it's contents - only >> indirectly. The reason it's checked in, is that otherwise every user >> would need to generate it before being able to run configure. In >> build reviews, we usually either revert changes to >> generated-configure.sh before posting a review to hide it (and >> re-generate it before pushing), or we just ignore it during reviews. >> I should have done that, or pointed out that it was not needed nor >> possible to review when I cross-posted. I'm sorry. >> >>> >>> L4076: # Verify that a given string represent a valid version >>> number, and assing it to >>> L4077: # a variable. >>> Fixed two typos and reformat a bit: >>> # Verify that a given string represents a valid version >>> number, and >>> # assigning it to a variable. >> I'll put that fix in the source .m4 file instead. Thanks. >>> >>> L20262: as_fn_error $? "--with--version-string must have a >>> value" "$LINENO" 5 >>> The '--with--version...' part doesn't match previous usages >>> where >>> '--with-version...' is used >> Yes, you're right. Erik pointed it out as well. It's a typo in the >> error message. It's all over the place due to copied code. I'll fix >> it in the source .m4 file. >> >> (As a side note, I have a half-finished follow-up patch that will >> reduce the amount of code duplication, but it requires some framework >> changes so it'll have to be a separate thing.) >> >>> >>> L20275: # Unspecified numerical fields is interpreted as 0. >>> Grammar: 'is interpreted' -> 'are interpreted' >>> >>> L20286: as_fn_error $? "Version string contains + but >>> both 'BUILD' and 'OPT' is missing" "$LINENO" 5 >>> Grammar: 'is missing' -> 'are missing' >> Those darn English plural forms! Why can't you all do as we sensible >> Swedes and get rid of them? ;-) >> >> (I'll fix) >> >>> >>> L20388: username=`$ECHO "$USER" | $TR -d -c >>> '[a-z][A-Z][0-9]'` >>> This assumes that the "USER" variable is set. Should there >>> be a check for "" and perhaps use "no_user_specified" or >>> something like that? Perhaps the build setup always makes >>> sure that "USER" is set to something. Don't know. >> Hm. I think the worst thing that'll happen is that the username part >> of the opt string gets empty. This part is basically copied right off >> the old build, where we have relied on the $USER variable being >> present for all the time with no problems, so I think it's quite safe >> to assume. >>> >>> common/autoconf/jdk-options.m4 >>> Don't know why the 'elliptic curve crypto implementation' support >>> is relocated as part of this changeset, but ... >> It was incorrectly placed not at the top indentation level, but in >> the middle of the function definition where the old versioning code >> were handled. (Which, mostly by chance, happens to work in autoconf, >> but is really bad style). >> >>> make/Javadoc.gmk >>> Did you mean to remove the 'clean' target? >> Yep. Cleaning is done by the top-level Main.gmk makefile nowadays, >> that's just some dead code. >> >>> >>> hotspot/make/windows/makefiles/compile.make >>> No changes in the frames view. >>> Update: udiff view shows a blank line deleted at the end of the >>> file. >> >> That's probably the result of some change going forth and then back >> again during development. But then again, removing extra blank linkes >> is not a bad thing. (jcheck unfortunately does not enforce any style >> checks for make files :-( so they tend to detoriate over time.) >> >>> >>> hotspot/src/share/vm/runtime/java.cpp >>> L661: void JDK_Version::fully_initialize( >>> L662: uint8_t major, uint8_t minor, uint8_t security, >>> uint8_t update) { >>> L663: // This is only called when current is less than 1.6 and >>> we've gotten >>> >>> Since you're ripping out vestigial version support, I think >>> this >>> function can go away since this is version 9 and newer. >>> Don't really >>> know for sure, but based on that comment... >> It probably can, yes. This and other core changes to the actual >> .cpp/.java files will be addressed in a follow-up patch. >>> >>> hotspot/src/share/vm/runtime/java.hpp >>> No comments. >>> >>> hotspot/src/share/vm/runtime/vmStructs.cpp >>> L1240: please make the 'int' parameter align like the rest. >> Are you okay with defering such a change to a follow-up patch? > > Yes. > > >> It's likely the entire struct will need changes to be able to handle >> a theoretically arbitrarily long version number. >> >>> >>> hotspot/src/share/vm/runtime/vm_version.cpp >>> L84: void Abstract_VM_Version::initialize() { >>> L85: // FIXME: Initialization can probably be removed now. >>> I agree, but that would entail also removing the >>> _initialized and the uses of it... Follow on bug fix? >> Definitely follow on. >> >>> jdk/src/java.base/share/classes/sun/misc/Version.java.template >>> L149: * Returns the security version of the running JVM if >>> it's 1.6 or newer >>> This JavaDoc update is wrong, but it might not be important >>> if sun.misc.Version class is going away. >> I'm not sure if it's going to be replaced by, or just complemented by >> java.util.Version, but in any case it will need a follow-up patch to >> clean up this and other issues. >>> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >>> >>> old L171: case "1.9": >>> new L171: case "9": >>> Should this logic support both versions? Will dropping >>> "1.9" here prevent a pre-version changeset JVM from >>> being dropped into a JDK for triage purposes? >>> >>> Granted we don't often triage 'javac' with different JVMs, >>> but... >> I'll defer that question to Kumar, who wrote that piece of code. My >> guess is that when Hotspot express was dropped, the ability to use a >> JVM from another JDK release bit rotteded away. >> >> /Magnus > > Dan From kumar.x.srinivasan at oracle.com Tue Jun 9 14:25:45 2015 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 09 Jun 2015 07:25:45 -0700 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <55767256.3030802@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <55767256.3030802@oracle.com> Message-ID: <5576F769.3060002@oracle.com> On 6/8/2015 9:57 PM, Jan Lahoda wrote: > On 9.6.2015 01:31, Daniel D. Daugherty wrote: >> > >> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >> >> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >> >> >> old L171: case "1.9": >> new L171: case "9": >> Should this logic support both versions? Will dropping >> "1.9" here prevent a pre-version changeset JVM from >> being dropped into a JDK for triage purposes? >> >> Granted we don't often triage 'javac' with different JVMs, >> but... >> > > +1 on keeping both "1.9" and "9" here. javac can be used independently > on the rest of JDK to some extent, so support for running it on older > builds of JDK 9 seems reasonable to me. (I wonder if current JDK 9 > javac should be prepared for the new version scheme in advance.) Yes, I think for the most part langtools seems to be working in the sandbox repo, with these changes, the remaining work is to align the version and fullversion of langtools/test to be compliant to the JDK version. Kumar > > Jan From cnewland at chrisnewland.com Tue Jun 9 21:25:26 2015 From: cnewland at chrisnewland.com (Chris Newland) Date: Tue, 9 Jun 2015 22:25:26 +0100 Subject: Has --dump-debug-dir behaviour changed in JDK9? Message-ID: Hi, Has Nashorn's behaviour for dumping bytecode changed in JDK9? Given this JavaScript: https://gist.github.com/chriswhocodes/bfe139592adb846967d8 Executed using $JAVA_HOME/bin/jjs -co --dump-debug-dir=. run.js Under 8u60b18 the bytecode is produced as expected: https://gist.github.com/chriswhocodes/e3a85c3613b084e45356 This visualises correctly in JITWatch[1] and the bytecode maps back to the source as expected. But under 9b67 only a small amount of bytecode is output that doesn't represent the source program: https://gist.github.com/chriswhocodes/c6c6e33e7994c98d4975 The correct program output is produced under both executions so I don't think the difference is down to dead code elimination. Possible regression? Thanks, Chris @chriswhocodes [1] https://github.com/AdoptOpenJDK/jitwatch From sundararajan.athijegannathan at oracle.com Wed Jun 10 04:22:47 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 10 Jun 2015 09:52:47 +0530 Subject: Has --dump-debug-dir behaviour changed in JDK9? In-Reply-To: References: Message-ID: <5577BB97.20400@oracle.com> Hi, Filed a bug to track for future reference: https://bugs.openjdk.java.net/browse/JDK-8087102 Actually, this is not a bug. Two things: 1) --compile-only / -co option is no longer mandatory to use --debug-dump-dir option/ 2) optimistic types is off by default in jdk8u and it is on by default with jdk9. With optimistic types, code generation is lazier & optimistic -- code is generated/re-generated as you run the code. With jdk9, you can either 1) Turn off optimistic types with jdk9 (using -ot=false option) and dump similar code as in jdk8u 2) or run the code (i.e., remove -co / --compile-only option) and get all generated (and regenerated) code dumped. PS. I've resolved the bug as "not an issue". Hope this explains, -Sundar On Wednesday 10 June 2015 02:55 AM, Chris Newland wrote: > Hi, > > Has Nashorn's behaviour for dumping bytecode changed in JDK9? > > Given this JavaScript: > https://gist.github.com/chriswhocodes/bfe139592adb846967d8 > > Executed using > $JAVA_HOME/bin/jjs -co --dump-debug-dir=. run.js > > Under 8u60b18 the bytecode is produced as expected: > > https://gist.github.com/chriswhocodes/e3a85c3613b084e45356 > > This visualises correctly in JITWatch[1] and the bytecode maps back to the > source as expected. > > But under 9b67 only a small amount of bytecode is output that doesn't > represent the source program: > > https://gist.github.com/chriswhocodes/c6c6e33e7994c98d4975 > > The correct program output is produced under both executions so I don't > think the difference is down to dead code elimination. > > Possible regression? > > Thanks, > > Chris > @chriswhocodes > > [1] https://github.com/AdoptOpenJDK/jitwatch > > From erik.joelsson at oracle.com Wed Jun 10 07:18:03 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 10 Jun 2015 09:18:03 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576EF94.3010500@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> Message-ID: <5577E4AB.4090305@oracle.com> Looks good. /Erik On 2015-06-09 15:52, Magnus Ihse Bursie wrote: > Here's an updated webrev, which fixes the typos that were pointed out > by reviewers: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ > > > And here's a (much simpler) delta webrev which shows just these changes: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch-delta-01/webrev.01/ > > > /Magnus > > On 2015-06-09 15:20, Daniel D. Daugherty wrote: >> On 6/9/15 7:12 AM, Magnus Ihse Bursie wrote: >>> Hi Daniel, >>> >>> Thank you for your thorough review! >> >> This was my (failing) attempt at a "fast pass" review... :-) >> >> >>> >>> On 2015-06-09 01:31, Daniel D. Daugherty wrote: >>>> > >>>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >>>> >>>> >>>> General comment: Not all copyright years were updated. >>>> General comment: It looks like support for the 'patch' value is not >>>> completely >>>> implemented through all the Makefiles. I didn't audit for this, >>>> but it's >>>> just my impression. >>> >>> You are basically correct. The makefiles all propagate the patch >>> value where needed, but the actual source code changes in hotspot >>> and jdk ignores the patch field as of now. This will be corrected in >>> a later add-on patch, submitted by someone from the jdk and/or >>> hotspot team rather than the build team. >>> >>>> >>>> common/autoconf/generated-configure.sh >>>> There are multiple Copyright notices in this file. Why? >>> Oh dear, you've reviewed the generated file. :-& I'm really >>> impressed by your effort! >> >> Ahhh... now that you say it... it sounds familiar... I may have >> made this same mistake before. I'll try to remember next time. >> >> >>> However, the generated-configure.sh file is automatically created by >>> the autoconf framework from the rest of the files in >>> common/autoconf/*, so we cannot direcly modify it's contents - only >>> indirectly. The reason it's checked in, is that otherwise every user >>> would need to generate it before being able to run configure. In >>> build reviews, we usually either revert changes to >>> generated-configure.sh before posting a review to hide it (and >>> re-generate it before pushing), or we just ignore it during reviews. >>> I should have done that, or pointed out that it was not needed nor >>> possible to review when I cross-posted. I'm sorry. >>> >>>> >>>> L4076: # Verify that a given string represent a valid version >>>> number, and assing it to >>>> L4077: # a variable. >>>> Fixed two typos and reformat a bit: >>>> # Verify that a given string represents a valid version >>>> number, and >>>> # assigning it to a variable. >>> I'll put that fix in the source .m4 file instead. Thanks. >>>> >>>> L20262: as_fn_error $? "--with--version-string must have a >>>> value" "$LINENO" 5 >>>> The '--with--version...' part doesn't match previous usages >>>> where >>>> '--with-version...' is used >>> Yes, you're right. Erik pointed it out as well. It's a typo in the >>> error message. It's all over the place due to copied code. I'll fix >>> it in the source .m4 file. >>> >>> (As a side note, I have a half-finished follow-up patch that will >>> reduce the amount of code duplication, but it requires some >>> framework changes so it'll have to be a separate thing.) >>> >>>> >>>> L20275: # Unspecified numerical fields is interpreted as 0. >>>> Grammar: 'is interpreted' -> 'are interpreted' >>>> >>>> L20286: as_fn_error $? "Version string contains + but >>>> both 'BUILD' and 'OPT' is missing" "$LINENO" 5 >>>> Grammar: 'is missing' -> 'are missing' >>> Those darn English plural forms! Why can't you all do as we sensible >>> Swedes and get rid of them? ;-) >>> >>> (I'll fix) >>> >>>> >>>> L20388: username=`$ECHO "$USER" | $TR -d -c >>>> '[a-z][A-Z][0-9]'` >>>> This assumes that the "USER" variable is set. Should there >>>> be a check for "" and perhaps use "no_user_specified" or >>>> something like that? Perhaps the build setup always makes >>>> sure that "USER" is set to something. Don't know. >>> Hm. I think the worst thing that'll happen is that the username part >>> of the opt string gets empty. This part is basically copied right >>> off the old build, where we have relied on the $USER variable being >>> present for all the time with no problems, so I think it's quite >>> safe to assume. >>>> >>>> common/autoconf/jdk-options.m4 >>>> Don't know why the 'elliptic curve crypto implementation' support >>>> is relocated as part of this changeset, but ... >>> It was incorrectly placed not at the top indentation level, but in >>> the middle of the function definition where the old versioning code >>> were handled. (Which, mostly by chance, happens to work in autoconf, >>> but is really bad style). >>> >>>> make/Javadoc.gmk >>>> Did you mean to remove the 'clean' target? >>> Yep. Cleaning is done by the top-level Main.gmk makefile nowadays, >>> that's just some dead code. >>> >>>> >>>> hotspot/make/windows/makefiles/compile.make >>>> No changes in the frames view. >>>> Update: udiff view shows a blank line deleted at the end of the >>>> file. >>> >>> That's probably the result of some change going forth and then back >>> again during development. But then again, removing extra blank >>> linkes is not a bad thing. (jcheck unfortunately does not enforce >>> any style checks for make files :-( so they tend to detoriate over >>> time.) >>> >>>> >>>> hotspot/src/share/vm/runtime/java.cpp >>>> L661: void JDK_Version::fully_initialize( >>>> L662: uint8_t major, uint8_t minor, uint8_t security, >>>> uint8_t update) { >>>> L663: // This is only called when current is less than 1.6 >>>> and we've gotten >>>> >>>> Since you're ripping out vestigial version support, I think >>>> this >>>> function can go away since this is version 9 and newer. >>>> Don't really >>>> know for sure, but based on that comment... >>> It probably can, yes. This and other core changes to the actual >>> .cpp/.java files will be addressed in a follow-up patch. >>>> >>>> hotspot/src/share/vm/runtime/java.hpp >>>> No comments. >>>> >>>> hotspot/src/share/vm/runtime/vmStructs.cpp >>>> L1240: please make the 'int' parameter align like the rest. >>> Are you okay with defering such a change to a follow-up patch? >> >> Yes. >> >> >>> It's likely the entire struct will need changes to be able to handle >>> a theoretically arbitrarily long version number. >>> >>>> >>>> hotspot/src/share/vm/runtime/vm_version.cpp >>>> L84: void Abstract_VM_Version::initialize() { >>>> L85: // FIXME: Initialization can probably be removed now. >>>> I agree, but that would entail also removing the >>>> _initialized and the uses of it... Follow on bug fix? >>> Definitely follow on. >>> >>>> jdk/src/java.base/share/classes/sun/misc/Version.java.template >>>> L149: * Returns the security version of the running JVM if >>>> it's 1.6 or newer >>>> This JavaDoc update is wrong, but it might not be important >>>> if sun.misc.Version class is going away. >>> I'm not sure if it's going to be replaced by, or just complemented >>> by java.util.Version, but in any case it will need a follow-up patch >>> to clean up this and other issues. >>>> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >>>> >>>> old L171: case "1.9": >>>> new L171: case "9": >>>> Should this logic support both versions? Will dropping >>>> "1.9" here prevent a pre-version changeset JVM from >>>> being dropped into a JDK for triage purposes? >>>> >>>> Granted we don't often triage 'javac' with different JVMs, >>>> but... >>> I'll defer that question to Kumar, who wrote that piece of code. My >>> guess is that when Hotspot express was dropped, the ability to use a >>> JVM from another JDK release bit rotteded away. >>> >>> /Magnus >> >> Dan > From magnus.ihse.bursie at oracle.com Wed Jun 10 12:13:16 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 10 Jun 2015 14:13:16 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <55780A33.1010302@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> <55780A33.1010302@oracle.com> Message-ID: <557829DC.8000405@oracle.com> On 2015-06-10 11:58, David Holmes wrote: > Hi Magnus, > > Generally looks good - a few comments/queries below. In general, I believe most issues you found are valid. :-) However, as I said before in this thread, I'd like to see them resolved in the needed follow-up patches. The source code changes in Hotspot and JDK are inadequate to fully implement JEP-223, so these areas will need to be rewritten anyhow. Are you okay with resolving these issues later? > > On 9/06/2015 11:52 PM, Magnus Ihse Bursie wrote: >> Here's an updated webrev, which fixes the typos that were pointed out by >> reviewers: >> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ >> > > common/autoconf/version-numbers > > Shouldn't there be a DEFAULT_VERSION_XXX for each of the XXX parts of > the version info? (Even if all zeroes presently.) So that's a tricky one. :-& The question here is, I think, does it make sense to update version-numbers when we do a security (9.0.1) or minor (9.1.0) release? Looking historically, the version-numbers file have not been changed for the 8u family. The only change was going from 8 to 9 when creating the new jdk9 forest. That was what I based my decition to only have the major number in the file. (The rest of the version string is set by configure flags when building, in Oracle case by the RE team.) If it makes sense to put the minor/security/patch numbers here, I won't oppose it, but I guess we have until the first such release to figure out what's best, and that likely includes discussion with RE and possibly other consumers in the community (RedHat etc). > > --- > > Looking at hotspot changes I can't convince myself that the new > streamlined "version" variables will capture things like "fastdebug". > Will that filter through via configure variables? The "fastdebug" label has been handled as a less valued token in the JEP-223 process. Right now there's no mention of it at all in the version string proposal in the JEP. As I understand it, Iris is about to propose an amendment which will just make fastdebug be a part of the OPT string. I'm not entirely happy with that myself, but that's the way it's decided. So wherever you can see the OPT string, you'll see the debug level tag. Currently, however, that's not how it is implemented in this patch. Since no decision was made on this (and it's still not formally decided), I had to pick a route to go forward. The current patch will instead put the "fastdebug" label as part of the PRE string (that's the reason for the pre-base and pre-debuglevel arguments to configure). If the planned changes goes into the JEP, this'll change to make the debuglevel tag a part of the OPT string instead. > --- > > make/*/makefiles/vm.make > > Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from the > VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a > stand-alone hotspot build?) The hotspot JEP-223 work initially made by Alejandro kept support for stand-alone hotspot builds. I made additional changes on top of that, which still tried to cater for stand-alone builds. At this very moment I'm not sure if stand-alone hotspot builds are supposed to work or not, but I've tried to not change the situation with this patch. There are two future changes coming down the pipe: One is the additional JEP-223 work needed for Hotspot. I know Alejandro had plans for redesigning the API between Hotspot and the JDK, so no JDK version strings should be compiled into the JVM, but all of it extracted during an API in runtime. That would make most (all?) of the makefile changes in hotspot irrelevant. However, that implementation is not even started, so it's needed for the time being. The second change is the build-infra hotspot makefile rewrite. When that happens, stand-alone builds will definitely disappear, and if Hotspot still needs make support for version strings, then the logical choice is to use VERSION_CFLAGS. Ok? > > --- > > hotspot/src/share/vm/prims/jvm.h > jdk/src/java.base/share/native/include/jvm.h > > I think this comment is way out of date: > > /* Build number is available only for RE build (i.e. JDK_BUILD_NUMBER > is set to bNN) > * It will be zero for internal builds. > */ > > and can be completely removed. Even if still true, mention of an "RE > build" has no place in OpenJDK sources. Yep, agree. Follow-up patch, right? > > --- > > hotspot/src/share/vm/runtime/java.cpp > > I think a lot of the modified code is obsolete post Hotspot Express - > which makes it hard to determine if the changes make sense. Yep, agree. Follow-up patch, right? > > --- > > hotspot/src/share/vm/runtime/vmStructs.cpp > > Please fix the alignment (3 extra spaces on modified line): > > 1239 static_field(Abstract_VM_Version, _vm_minor_version, > int) \ > 1240 static_field(Abstract_VM_Version, > _vm_security_version, int) \ I was about to say "follow-up patch", but ugly indentation really sucks so I can fix this. Ok if I skip redoing the review for that? > > --- > > hotspot/test/runtime/6981737/Test6981737.java > > This test is really only valid for the new version scheme now, so it > should probably be rewritten - and in that case it really isn't > testing 6981737 but should be replaced by a new test for the new > version format. Yep, agree. Follow-up patch, right? > > --- > > jdk/src/java.base/share/classes/sun/misc/Version.java.template > > This comment is nonsensical: > > /** > ! * Returns the security version of the running JVM if it's 1.6 > or newer > * or any RE VM build. It will return 0 if it's an internal 1.5 or > * 1.4.x build. > * @since 1.6 > */ > > as security version does not exist pre 9. Normally you should be > adding a new method and deprecating the old one. The new one is @since 9. Yep, agree. Follow-up patch, right? > > /** > ! * Returns the security version of the running JDK. > * @since 1.6 > */ > > Ditto: @since 9 (but again old should be deprecated and new method added) > > 253 /** > 254 * Returns the build number of the running JDK if it's a RE > build > 255 * It will return 0 if it's an internal build. > > As with jvm.h this seems obsolete commentary these days - not only RE > builds define a build number. Yep, agree. Follow-up patch, right? /Magnus > > Thanks, > David From david.holmes at oracle.com Wed Jun 10 09:58:11 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 Jun 2015 19:58:11 +1000 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576EF94.3010500@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> Message-ID: <55780A33.1010302@oracle.com> Hi Magnus, Generally looks good - a few comments/queries below. On 9/06/2015 11:52 PM, Magnus Ihse Bursie wrote: > Here's an updated webrev, which fixes the typos that were pointed out by > reviewers: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ common/autoconf/version-numbers Shouldn't there be a DEFAULT_VERSION_XXX for each of the XXX parts of the version info? (Even if all zeroes presently.) --- Looking at hotspot changes I can't convince myself that the new streamlined "version" variables will capture things like "fastdebug". Will that filter through via configure variables? --- make/*/makefiles/vm.make Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from the VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a stand-alone hotspot build?) --- hotspot/src/share/vm/prims/jvm.h jdk/src/java.base/share/native/include/jvm.h I think this comment is way out of date: /* Build number is available only for RE build (i.e. JDK_BUILD_NUMBER is set to bNN) * It will be zero for internal builds. */ and can be completely removed. Even if still true, mention of an "RE build" has no place in OpenJDK sources. --- hotspot/src/share/vm/runtime/java.cpp I think a lot of the modified code is obsolete post Hotspot Express - which makes it hard to determine if the changes make sense. --- hotspot/src/share/vm/runtime/vmStructs.cpp Please fix the alignment (3 extra spaces on modified line): 1239 static_field(Abstract_VM_Version, _vm_minor_version, int) \ 1240 static_field(Abstract_VM_Version, _vm_security_version, int) \ --- hotspot/test/runtime/6981737/Test6981737.java This test is really only valid for the new version scheme now, so it should probably be rewritten - and in that case it really isn't testing 6981737 but should be replaced by a new test for the new version format. --- jdk/src/java.base/share/classes/sun/misc/Version.java.template This comment is nonsensical: /** ! * Returns the security version of the running JVM if it's 1.6 or newer * or any RE VM build. It will return 0 if it's an internal 1.5 or * 1.4.x build. * @since 1.6 */ as security version does not exist pre 9. Normally you should be adding a new method and deprecating the old one. The new one is @since 9. /** ! * Returns the security version of the running JDK. * @since 1.6 */ Ditto: @since 9 (but again old should be deprecated and new method added) 253 /** 254 * Returns the build number of the running JDK if it's a RE build 255 * It will return 0 if it's an internal build. As with jvm.h this seems obsolete commentary these days - not only RE builds define a build number. Thanks, David > > And here's a (much simpler) delta webrev which shows just these changes: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch-delta-01/webrev.01/ > > > /Magnus > > On 2015-06-09 15:20, Daniel D. Daugherty wrote: >> On 6/9/15 7:12 AM, Magnus Ihse Bursie wrote: >>> Hi Daniel, >>> >>> Thank you for your thorough review! >> >> This was my (failing) attempt at a "fast pass" review... :-) >> >> >>> >>> On 2015-06-09 01:31, Daniel D. Daugherty wrote: >>>> > >>>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >>>> >>>> >>>> General comment: Not all copyright years were updated. >>>> General comment: It looks like support for the 'patch' value is not >>>> completely >>>> implemented through all the Makefiles. I didn't audit for this, >>>> but it's >>>> just my impression. >>> >>> You are basically correct. The makefiles all propagate the patch >>> value where needed, but the actual source code changes in hotspot and >>> jdk ignores the patch field as of now. This will be corrected in a >>> later add-on patch, submitted by someone from the jdk and/or hotspot >>> team rather than the build team. >>> >>>> >>>> common/autoconf/generated-configure.sh >>>> There are multiple Copyright notices in this file. Why? >>> Oh dear, you've reviewed the generated file. :-& I'm really impressed >>> by your effort! >> >> Ahhh... now that you say it... it sounds familiar... I may have >> made this same mistake before. I'll try to remember next time. >> >> >>> However, the generated-configure.sh file is automatically created by >>> the autoconf framework from the rest of the files in >>> common/autoconf/*, so we cannot direcly modify it's contents - only >>> indirectly. The reason it's checked in, is that otherwise every user >>> would need to generate it before being able to run configure. In >>> build reviews, we usually either revert changes to >>> generated-configure.sh before posting a review to hide it (and >>> re-generate it before pushing), or we just ignore it during reviews. >>> I should have done that, or pointed out that it was not needed nor >>> possible to review when I cross-posted. I'm sorry. >>> >>>> >>>> L4076: # Verify that a given string represent a valid version >>>> number, and assing it to >>>> L4077: # a variable. >>>> Fixed two typos and reformat a bit: >>>> # Verify that a given string represents a valid version >>>> number, and >>>> # assigning it to a variable. >>> I'll put that fix in the source .m4 file instead. Thanks. >>>> >>>> L20262: as_fn_error $? "--with--version-string must have a >>>> value" "$LINENO" 5 >>>> The '--with--version...' part doesn't match previous usages >>>> where >>>> '--with-version...' is used >>> Yes, you're right. Erik pointed it out as well. It's a typo in the >>> error message. It's all over the place due to copied code. I'll fix >>> it in the source .m4 file. >>> >>> (As a side note, I have a half-finished follow-up patch that will >>> reduce the amount of code duplication, but it requires some framework >>> changes so it'll have to be a separate thing.) >>> >>>> >>>> L20275: # Unspecified numerical fields is interpreted as 0. >>>> Grammar: 'is interpreted' -> 'are interpreted' >>>> >>>> L20286: as_fn_error $? "Version string contains + but >>>> both 'BUILD' and 'OPT' is missing" "$LINENO" 5 >>>> Grammar: 'is missing' -> 'are missing' >>> Those darn English plural forms! Why can't you all do as we sensible >>> Swedes and get rid of them? ;-) >>> >>> (I'll fix) >>> >>>> >>>> L20388: username=`$ECHO "$USER" | $TR -d -c >>>> '[a-z][A-Z][0-9]'` >>>> This assumes that the "USER" variable is set. Should there >>>> be a check for "" and perhaps use "no_user_specified" or >>>> something like that? Perhaps the build setup always makes >>>> sure that "USER" is set to something. Don't know. >>> Hm. I think the worst thing that'll happen is that the username part >>> of the opt string gets empty. This part is basically copied right off >>> the old build, where we have relied on the $USER variable being >>> present for all the time with no problems, so I think it's quite safe >>> to assume. >>>> >>>> common/autoconf/jdk-options.m4 >>>> Don't know why the 'elliptic curve crypto implementation' support >>>> is relocated as part of this changeset, but ... >>> It was incorrectly placed not at the top indentation level, but in >>> the middle of the function definition where the old versioning code >>> were handled. (Which, mostly by chance, happens to work in autoconf, >>> but is really bad style). >>> >>>> make/Javadoc.gmk >>>> Did you mean to remove the 'clean' target? >>> Yep. Cleaning is done by the top-level Main.gmk makefile nowadays, >>> that's just some dead code. >>> >>>> >>>> hotspot/make/windows/makefiles/compile.make >>>> No changes in the frames view. >>>> Update: udiff view shows a blank line deleted at the end of the >>>> file. >>> >>> That's probably the result of some change going forth and then back >>> again during development. But then again, removing extra blank linkes >>> is not a bad thing. (jcheck unfortunately does not enforce any style >>> checks for make files :-( so they tend to detoriate over time.) >>> >>>> >>>> hotspot/src/share/vm/runtime/java.cpp >>>> L661: void JDK_Version::fully_initialize( >>>> L662: uint8_t major, uint8_t minor, uint8_t security, >>>> uint8_t update) { >>>> L663: // This is only called when current is less than 1.6 and >>>> we've gotten >>>> >>>> Since you're ripping out vestigial version support, I think >>>> this >>>> function can go away since this is version 9 and newer. >>>> Don't really >>>> know for sure, but based on that comment... >>> It probably can, yes. This and other core changes to the actual >>> .cpp/.java files will be addressed in a follow-up patch. >>>> >>>> hotspot/src/share/vm/runtime/java.hpp >>>> No comments. >>>> >>>> hotspot/src/share/vm/runtime/vmStructs.cpp >>>> L1240: please make the 'int' parameter align like the rest. >>> Are you okay with defering such a change to a follow-up patch? >> >> Yes. >> >> >>> It's likely the entire struct will need changes to be able to handle >>> a theoretically arbitrarily long version number. >>> >>>> >>>> hotspot/src/share/vm/runtime/vm_version.cpp >>>> L84: void Abstract_VM_Version::initialize() { >>>> L85: // FIXME: Initialization can probably be removed now. >>>> I agree, but that would entail also removing the >>>> _initialized and the uses of it... Follow on bug fix? >>> Definitely follow on. >>> >>>> jdk/src/java.base/share/classes/sun/misc/Version.java.template >>>> L149: * Returns the security version of the running JVM if >>>> it's 1.6 or newer >>>> This JavaDoc update is wrong, but it might not be important >>>> if sun.misc.Version class is going away. >>> I'm not sure if it's going to be replaced by, or just complemented by >>> java.util.Version, but in any case it will need a follow-up patch to >>> clean up this and other issues. >>>> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >>>> >>>> old L171: case "1.9": >>>> new L171: case "9": >>>> Should this logic support both versions? Will dropping >>>> "1.9" here prevent a pre-version changeset JVM from >>>> being dropped into a JDK for triage purposes? >>>> >>>> Granted we don't often triage 'javac' with different JVMs, >>>> but... >>> I'll defer that question to Kumar, who wrote that piece of code. My >>> guess is that when Hotspot express was dropped, the ability to use a >>> JVM from another JDK release bit rotteded away. >>> >>> /Magnus >> >> Dan > From magnus.ihse.bursie at oracle.com Wed Jun 10 13:44:41 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 10 Jun 2015 15:44:41 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <557625C8.5050200@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> Message-ID: <55783F49.6030906@oracle.com> On 2015-06-09 01:31, Daniel D. Daugherty wrote: > > > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > > > General comment: Not all copyright years were updated. I realize I missed that part of the review. :-( I have now updated the copyright years. Here's a delta review: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch-delta-02/webrev.01/ Here's the complete review once again: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.03 Hopefully this is now the final version to be pushed to verona, and that any additional problems can be resolved with follow-up patches. /Magnus From cnewland at chrisnewland.com Wed Jun 10 17:31:31 2015 From: cnewland at chrisnewland.com (Chris Newland) Date: Wed, 10 Jun 2015 18:31:31 +0100 Subject: Has --dump-debug-dir behaviour changed in JDK9? In-Reply-To: <5577BB97.20400@oracle.com> References: <5577BB97.20400@oracle.com> Message-ID: <19e92cc41b1497c661635ca219e12d89.squirrel@excalibur.xssl.net> Thank you Sundar, that explains it perfectly. JITWatch visualises JavaScript/bytecode/asm correctly with -ot=false on JDK9. I'll now try and make it work with optimistic typing enabled. Cheers, Chris @chriswhocodes On Wed, June 10, 2015 05:22, A. Sundararajan wrote: > Hi, > > > Filed a bug to track for future reference: > https://bugs.openjdk.java.net/browse/JDK-8087102 > > > Actually, this is not a bug. Two things: > > > 1) --compile-only / -co option is no longer mandatory to use > --debug-dump-dir option/ > 2) optimistic types is off by default in jdk8u and it is on by default > with jdk9. > > With optimistic types, code generation is lazier & optimistic -- code is > generated/re-generated as you run the code. With jdk9, you can either > > 1) Turn off optimistic types with jdk9 (using -ot=false option) and dump > similar code as in jdk8u 2) or run the code (i.e., remove -co / > --compile-only option) and get > all generated (and regenerated) code dumped. > > PS. I've resolved the bug as "not an issue". > > > Hope this explains, > -Sundar > > > On Wednesday 10 June 2015 02:55 AM, Chris Newland wrote: > >> Hi, >> >> >> Has Nashorn's behaviour for dumping bytecode changed in JDK9? >> >> >> Given this JavaScript: >> https://gist.github.com/chriswhocodes/bfe139592adb846967d8 >> >> >> Executed using >> $JAVA_HOME/bin/jjs -co --dump-debug-dir=. run.js >> >> >> Under 8u60b18 the bytecode is produced as expected: >> >> >> https://gist.github.com/chriswhocodes/e3a85c3613b084e45356 >> >> >> This visualises correctly in JITWatch[1] and the bytecode maps back to >> the source as expected. >> >> But under 9b67 only a small amount of bytecode is output that doesn't >> represent the source program: >> >> https://gist.github.com/chriswhocodes/c6c6e33e7994c98d4975 >> >> >> The correct program output is produced under both executions so I don't >> think the difference is down to dead code elimination. >> >> Possible regression? >> >> >> Thanks, >> >> >> Chris >> @chriswhocodes >> >> >> [1] https://github.com/AdoptOpenJDK/jitwatch >> >> >> > > From sundararajan.athijegannathan at oracle.com Wed Jun 10 18:13:47 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 10 Jun 2015 23:43:47 +0530 Subject: RFR 8087136: regression: apply on $EXEC fails with ClassCastException Message-ID: <55787E5B.4090004@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8087136/ for https://bugs.openjdk.java.net/browse/JDK-8087136 Thanks, -Sundar From sundararajan.athijegannathan at oracle.com Thu Jun 11 03:40:22 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 11 Jun 2015 09:10:22 +0530 Subject: Has --dump-debug-dir behaviour changed in JDK9? In-Reply-To: <19e92cc41b1497c661635ca219e12d89.squirrel@excalibur.xssl.net> References: <5577BB97.20400@oracle.com> <19e92cc41b1497c661635ca219e12d89.squirrel@excalibur.xssl.net> Message-ID: <55790326.4070708@oracle.com> Thanks for your reply! PS. Will play with newer versions of JITWatch. Cool tool, btw! Thanks, -Sundar On Wednesday 10 June 2015 11:01 PM, Chris Newland wrote: > Thank you Sundar, that explains it perfectly. > > JITWatch visualises JavaScript/bytecode/asm correctly with -ot=false on > JDK9. I'll now try and make it work with optimistic typing enabled. > > Cheers, > > Chris > @chriswhocodes > > On Wed, June 10, 2015 05:22, A. Sundararajan wrote: >> Hi, >> >> >> Filed a bug to track for future reference: >> https://bugs.openjdk.java.net/browse/JDK-8087102 >> >> >> Actually, this is not a bug. Two things: >> >> >> 1) --compile-only / -co option is no longer mandatory to use >> --debug-dump-dir option/ >> 2) optimistic types is off by default in jdk8u and it is on by default >> with jdk9. >> >> With optimistic types, code generation is lazier & optimistic -- code is >> generated/re-generated as you run the code. With jdk9, you can either >> >> 1) Turn off optimistic types with jdk9 (using -ot=false option) and dump >> similar code as in jdk8u 2) or run the code (i.e., remove -co / >> --compile-only option) and get >> all generated (and regenerated) code dumped. >> >> PS. I've resolved the bug as "not an issue". >> >> >> Hope this explains, >> -Sundar >> >> >> On Wednesday 10 June 2015 02:55 AM, Chris Newland wrote: >> >>> Hi, >>> >>> >>> Has Nashorn's behaviour for dumping bytecode changed in JDK9? >>> >>> >>> Given this JavaScript: >>> https://gist.github.com/chriswhocodes/bfe139592adb846967d8 >>> >>> >>> Executed using >>> $JAVA_HOME/bin/jjs -co --dump-debug-dir=. run.js >>> >>> >>> Under 8u60b18 the bytecode is produced as expected: >>> >>> >>> https://gist.github.com/chriswhocodes/e3a85c3613b084e45356 >>> >>> >>> This visualises correctly in JITWatch[1] and the bytecode maps back to >>> the source as expected. >>> >>> But under 9b67 only a small amount of bytecode is output that doesn't >>> represent the source program: >>> >>> https://gist.github.com/chriswhocodes/c6c6e33e7994c98d4975 >>> >>> >>> The correct program output is produced under both executions so I don't >>> think the difference is down to dead code elimination. >>> >>> Possible regression? >>> >>> >>> Thanks, >>> >>> >>> Chris >>> @chriswhocodes >>> >>> >>> [1] https://github.com/AdoptOpenJDK/jitwatch >>> >>> >>> >> > From david.holmes at oracle.com Thu Jun 11 04:52:53 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Jun 2015 14:52:53 +1000 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <557829DC.8000405@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> <55780A33.1010302@oracle.com> <557829DC.8000405@oracle.com> Message-ID: <55791425.8070709@oracle.com> Hi Magnus, On 10/06/2015 10:13 PM, Magnus Ihse Bursie wrote: > On 2015-06-10 11:58, David Holmes wrote: >> Hi Magnus, >> >> Generally looks good - a few comments/queries below. > > In general, I believe most issues you found are valid. :-) However, as I > said before in this thread, I'd like to see them resolved in the needed > follow-up patches. The source code changes in Hotspot and JDK are > inadequate to fully implement JEP-223, so these areas will need to be > rewritten anyhow. Are you okay with resolving these issues later? Given this is going to a staging repo I'm okay with deferring things - I just have a concern whether such things may be overlooked given that the integration with the staging repo will not be undergoing a final review. I would prefer to see the Version.java.template doc comments corrected, even if the issue of whether to add and deprecate is deferred, but again as this is to a staging area I can let it slide for now. I saw the fix to hotspot/src/share/vm/runtime/vmStructs.cpp. Thanks, David >> >> On 9/06/2015 11:52 PM, Magnus Ihse Bursie wrote: >>> Here's an updated webrev, which fixes the typos that were pointed out by >>> reviewers: >>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ >>> >> >> common/autoconf/version-numbers >> >> Shouldn't there be a DEFAULT_VERSION_XXX for each of the XXX parts of >> the version info? (Even if all zeroes presently.) > So that's a tricky one. :-& The question here is, I think, does it make > sense to update version-numbers when we do a security (9.0.1) or minor > (9.1.0) release? Looking historically, the version-numbers file have not > been changed for the 8u family. The only change was going from 8 to 9 > when creating the new jdk9 forest. That was what I based my decition to > only have the major number in the file. (The rest of the version string > is set by configure flags when building, in Oracle case by the RE team.) > > If it makes sense to put the minor/security/patch numbers here, I won't > oppose it, but I guess we have until the first such release to figure > out what's best, and that likely includes discussion with RE and > possibly other consumers in the community (RedHat etc). > >> >> --- >> >> Looking at hotspot changes I can't convince myself that the new >> streamlined "version" variables will capture things like "fastdebug". >> Will that filter through via configure variables? > > The "fastdebug" label has been handled as a less valued token in the > JEP-223 process. Right now there's no mention of it at all in the > version string proposal in the JEP. As I understand it, Iris is about to > propose an amendment which will just make fastdebug be a part of the OPT > string. I'm not entirely happy with that myself, but that's the way it's > decided. So wherever you can see the OPT string, you'll see the debug > level tag. > > Currently, however, that's not how it is implemented in this patch. > Since no decision was made on this (and it's still not formally > decided), I had to pick a route to go forward. The current patch will > instead put the "fastdebug" label as part of the PRE string (that's the > reason for the pre-base and pre-debuglevel arguments to configure). If > the planned changes goes into the JEP, this'll change to make the > debuglevel tag a part of the OPT string instead. > >> --- >> >> make/*/makefiles/vm.make >> >> Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from the >> VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a >> stand-alone hotspot build?) > The hotspot JEP-223 work initially made by Alejandro kept support for > stand-alone hotspot builds. I made additional changes on top of that, > which still tried to cater for stand-alone builds. At this very moment > I'm not sure if stand-alone hotspot builds are supposed to work or not, > but I've tried to not change the situation with this patch. > > There are two future changes coming down the pipe: One is the additional > JEP-223 work needed for Hotspot. I know Alejandro had plans for > redesigning the API between Hotspot and the JDK, so no JDK version > strings should be compiled into the JVM, but all of it extracted during > an API in runtime. That would make most (all?) of the makefile changes > in hotspot irrelevant. However, that implementation is not even started, > so it's needed for the time being. > > The second change is the build-infra hotspot makefile rewrite. When that > happens, stand-alone builds will definitely disappear, and if Hotspot > still needs make support for version strings, then the logical choice is > to use VERSION_CFLAGS. > > Ok? > >> >> --- >> >> hotspot/src/share/vm/prims/jvm.h >> jdk/src/java.base/share/native/include/jvm.h >> >> I think this comment is way out of date: >> >> /* Build number is available only for RE build (i.e. JDK_BUILD_NUMBER >> is set to bNN) >> * It will be zero for internal builds. >> */ >> >> and can be completely removed. Even if still true, mention of an "RE >> build" has no place in OpenJDK sources. > Yep, agree. Follow-up patch, right? > >> >> --- >> >> hotspot/src/share/vm/runtime/java.cpp >> >> I think a lot of the modified code is obsolete post Hotspot Express - >> which makes it hard to determine if the changes make sense. > Yep, agree. Follow-up patch, right? >> >> --- >> >> hotspot/src/share/vm/runtime/vmStructs.cpp >> >> Please fix the alignment (3 extra spaces on modified line): >> >> 1239 static_field(Abstract_VM_Version, _vm_minor_version, >> int) \ >> 1240 static_field(Abstract_VM_Version, >> _vm_security_version, int) \ > > I was about to say "follow-up patch", but ugly indentation really sucks > so I can fix this. Ok if I skip redoing the review for that? > >> >> --- >> >> hotspot/test/runtime/6981737/Test6981737.java >> >> This test is really only valid for the new version scheme now, so it >> should probably be rewritten - and in that case it really isn't >> testing 6981737 but should be replaced by a new test for the new >> version format. > Yep, agree. Follow-up patch, right? >> >> --- >> >> jdk/src/java.base/share/classes/sun/misc/Version.java.template >> >> This comment is nonsensical: >> >> /** >> ! * Returns the security version of the running JVM if it's 1.6 >> or newer >> * or any RE VM build. It will return 0 if it's an internal 1.5 or >> * 1.4.x build. >> * @since 1.6 >> */ >> >> as security version does not exist pre 9. Normally you should be >> adding a new method and deprecating the old one. The new one is @since 9. > Yep, agree. Follow-up patch, right? >> >> /** >> ! * Returns the security version of the running JDK. >> * @since 1.6 >> */ >> >> Ditto: @since 9 (but again old should be deprecated and new method added) >> >> 253 /** >> 254 * Returns the build number of the running JDK if it's a RE >> build >> 255 * It will return 0 if it's an internal build. >> >> As with jvm.h this seems obsolete commentary these days - not only RE >> builds define a build number. > Yep, agree. Follow-up patch, right? > > /Magnus > >> >> Thanks, >> David > From erik.joelsson at oracle.com Thu Jun 11 06:58:41 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 11 Jun 2015 08:58:41 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <55783F49.6030906@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <55783F49.6030906@oracle.com> Message-ID: <557931A1.6030406@oracle.com> Looks good. /Erik On 2015-06-10 15:44, Magnus Ihse Bursie wrote: > On 2015-06-09 01:31, Daniel D. Daugherty wrote: >> > >> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >> >> >> General comment: Not all copyright years were updated. > > I realize I missed that part of the review. :-( > > I have now updated the copyright years. Here's a delta review: > > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch-delta-02/webrev.01/ > > > Here's the complete review once again: > > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.03 > > > Hopefully this is now the final version to be pushed to verona, and > that any additional problems can be resolved with follow-up patches. > > /Magnus From hannes.wallnoefer at oracle.com Thu Jun 11 07:41:07 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 11 Jun 2015 09:41:07 +0200 Subject: RFR 8087136: regression: apply on $EXEC fails with ClassCastException In-Reply-To: <55787E5B.4090004@oracle.com> References: <55787E5B.4090004@oracle.com> Message-ID: <55793B93.9010601@oracle.com> It looks like the original commit requires changes in ScriptFunction.createApplyOrCallCall to make apply work with the changed rules. +1 for reverting given given the tight time line for 8u60. Hannes Am 2015-06-10 um 20:13 schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8087136/ for > https://bugs.openjdk.java.net/browse/JDK-8087136 > > Thanks, > -Sundar From marcus.lagergren at oracle.com Thu Jun 11 07:59:56 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 11 Jun 2015 09:59:56 +0200 Subject: RFR 8087136: regression: apply on $EXEC fails with ClassCastException In-Reply-To: <55787E5B.4090004@oracle.com> References: <55787E5B.4090004@oracle.com> Message-ID: +1 > On 10 Jun 2015, at 20:13, A. Sundararajan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8087136/ for https://bugs.openjdk.java.net/browse/JDK-8087136 > > Thanks, > -Sundar From marcus.lagergren at oracle.com Thu Jun 11 08:00:29 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 11 Jun 2015 10:00:29 +0200 Subject: Has --dump-debug-dir behaviour changed in JDK9? In-Reply-To: <19e92cc41b1497c661635ca219e12d89.squirrel@excalibur.xssl.net> References: <5577BB97.20400@oracle.com> <19e92cc41b1497c661635ca219e12d89.squirrel@excalibur.xssl.net> Message-ID: You are awesome, Chris! /M > On 10 Jun 2015, at 19:31, Chris Newland wrote: > > Thank you Sundar, that explains it perfectly. > > JITWatch visualises JavaScript/bytecode/asm correctly with -ot=false on > JDK9. I'll now try and make it work with optimistic typing enabled. > > Cheers, > > Chris > @chriswhocodes > > On Wed, June 10, 2015 05:22, A. Sundararajan wrote: >> Hi, >> >> >> Filed a bug to track for future reference: >> https://bugs.openjdk.java.net/browse/JDK-8087102 >> >> >> Actually, this is not a bug. Two things: >> >> >> 1) --compile-only / -co option is no longer mandatory to use >> --debug-dump-dir option/ >> 2) optimistic types is off by default in jdk8u and it is on by default >> with jdk9. >> >> With optimistic types, code generation is lazier & optimistic -- code is >> generated/re-generated as you run the code. With jdk9, you can either >> >> 1) Turn off optimistic types with jdk9 (using -ot=false option) and dump >> similar code as in jdk8u 2) or run the code (i.e., remove -co / >> --compile-only option) and get >> all generated (and regenerated) code dumped. >> >> PS. I've resolved the bug as "not an issue". >> >> >> Hope this explains, >> -Sundar >> >> >> On Wednesday 10 June 2015 02:55 AM, Chris Newland wrote: >> >>> Hi, >>> >>> >>> Has Nashorn's behaviour for dumping bytecode changed in JDK9? >>> >>> >>> Given this JavaScript: >>> https://gist.github.com/chriswhocodes/bfe139592adb846967d8 >>> >>> >>> Executed using >>> $JAVA_HOME/bin/jjs -co --dump-debug-dir=. run.js >>> >>> >>> Under 8u60b18 the bytecode is produced as expected: >>> >>> >>> https://gist.github.com/chriswhocodes/e3a85c3613b084e45356 >>> >>> >>> This visualises correctly in JITWatch[1] and the bytecode maps back to >>> the source as expected. >>> >>> But under 9b67 only a small amount of bytecode is output that doesn't >>> represent the source program: >>> >>> https://gist.github.com/chriswhocodes/c6c6e33e7994c98d4975 >>> >>> >>> The correct program output is produced under both executions so I don't >>> think the difference is down to dead code elimination. >>> >>> Possible regression? >>> >>> >>> Thanks, >>> >>> >>> Chris >>> @chriswhocodes >>> >>> >>> [1] https://github.com/AdoptOpenJDK/jitwatch >>> >>> >>> >> >> > > From magnus.ihse.bursie at oracle.com Thu Jun 11 12:14:59 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 11 Jun 2015 14:14:59 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <55791425.8070709@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> <55780A33.1010302@oracle.com> <557829DC.8000405@oracle.com> <55791425.8070709@oracle.com> Message-ID: <55797BC3.9080202@oracle.com> On 2015-06-11 06:52, David Holmes wrote: > Hi Magnus, > > On 10/06/2015 10:13 PM, Magnus Ihse Bursie wrote: >> On 2015-06-10 11:58, David Holmes wrote: >>> Hi Magnus, >>> >>> Generally looks good - a few comments/queries below. >> >> In general, I believe most issues you found are valid. :-) However, as I >> said before in this thread, I'd like to see them resolved in the needed >> follow-up patches. The source code changes in Hotspot and JDK are >> inadequate to fully implement JEP-223, so these areas will need to be >> rewritten anyhow. Are you okay with resolving these issues later? > > Given this is going to a staging repo I'm okay with deferring things - > I just have a concern whether such things may be overlooked given that > the integration with the staging repo will not be undergoing a final > review. I agree completely with your concern. I have summarized the issues that were raised but not addressed during this review, and created JBS bugs, one per component. I will do my best to make sure that fixing them does not get lost from the Verona project agenda. The three bugs are: https://bugs.openjdk.java.net/browse/JDK-8087202 https://bugs.openjdk.java.net/browse/JDK-8087203 https://bugs.openjdk.java.net/browse/JDK-8087205 Here's the core content of them. If I have missed something, please add it to the bug reports: HOTSPOT: Alan Bateman: Will the update_version and special_update_version fields eventually be dropped from the jvm_version_info structure? The webrev shows a change to this comment in jvm.h: "Third, this file contains various I/O and network operations needed by the standard Java I/O and network APIs." I think this comment can be removed because those JVM_* functions were removed some time ago. Daniel D. Daugherty: General comment: It looks like support for the 'patch' value is not completely implemented through all the Makefiles. I didn't audit for this, but it's just my impression. hotspot/src/share/vm/runtime/java.cpp L661: void JDK_Version::fully_initialize( L662: uint8_t major, uint8_t minor, uint8_t security, uint8_t update) { L663: // This is only called when current is less than 1.6 and we've gotten Since you're ripping out vestigial version support, I think this function can go away since this is version 9 and newer. Don't really know for sure, but based on that comment... hotspot/src/share/vm/runtime/vm_version.cpp L84: void Abstract_VM_Version::initialize() { L85: // FIXME: Initialization can probably be removed now. I agree, but that would entail also removing the _initialized and the uses of it... Follow on bug fix? David Holmes: make/*/makefiles/vm.make Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from the VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a stand-alone hotspot build?) hotspot/src/share/vm/prims/jvm.h I think this comment is way out of date: /* Build number is available only for RE build (i.e. JDK_BUILD_NUMBER is set to bNN) * It will be zero for internal builds. */ and can be completely removed. Even if still true, mention of an "RE build" has no place in OpenJDK sources. hotspot/src/share/vm/runtime/java.cpp I think a lot of the modified code is obsolete post Hotspot Express - which makes it hard to determine if the changes make sense. hotspot/test/runtime/6981737/Test6981737.java This test is really only valid for the new version scheme now, so it should probably be rewritten - and in that case it really isn't testing 6981737 but should be replaced by a new test for the new version format. JDK: Alan Bateman: Version.java.template - the comment in jvmSecurityVersion() still talks about 1.6 and newer. Can this be replaced to just say that it returns the security version? Daniel D. Daugherty: jdk/src/java.base/share/classes/sun/misc/Version.java.template L149: * Returns the security version of the running JVM if it's 1.6 or newer This JavaDoc update is wrong, but it might not be important if sun.misc.Version class is going away. David Holmes: jdk/src/java.base/share/classes/sun/misc/Version.java.template This comment is nonsensical: /** ! * Returns the security version of the running JVM if it's 1.6 or newer * or any RE VM build. It will return 0 if it's an internal 1.5 or * 1.4.x build. * @since 1.6 */ as security version does not exist pre 9. Normally you should be adding a new method and deprecating the old one. The new one is @since 9. /** ! * Returns the security version of the running JDK. * @since 1.6 */ Ditto: @since 9 (but again old should be deprecated and new method added) 253 /** 254 * Returns the build number of the running JDK if it's a RE build 255 * It will return 0 if it's an internal build. As with jvm.h this seems obsolete commentary these days - not only RE builds define a build number. LANGTOOLS: Daniel D. Daugherty: langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java old L171: case "1.9": new L171: case "9": Should this logic support both versions? Will dropping "1.9" here prevent a pre-version changeset JVM from being dropped into a JDK for triage purposes? Granted we don't often triage 'javac' with different JVMs, but... Jan Lahoda: +1 on keeping both "1.9" and "9" here. javac can be used independently on the rest of JDK to some extent, so support for running it on older builds of JDK 9 seems reasonable to me. (I wonder if current JDK 9 javac should be prepared for the new version scheme in advance.) /Magnus > > I would prefer to see the Version.java.template doc comments > corrected, even if the issue of whether to add and deprecate is > deferred, but again as this is to a staging area I can let it slide > for now. > > I saw the fix to hotspot/src/share/vm/runtime/vmStructs.cpp. > > Thanks, > David > >>> >>> On 9/06/2015 11:52 PM, Magnus Ihse Bursie wrote: >>>> Here's an updated webrev, which fixes the typos that were pointed >>>> out by >>>> reviewers: >>>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ >>>> >>>> >>> >>> common/autoconf/version-numbers >>> >>> Shouldn't there be a DEFAULT_VERSION_XXX for each of the XXX parts of >>> the version info? (Even if all zeroes presently.) >> So that's a tricky one. :-& The question here is, I think, does it make >> sense to update version-numbers when we do a security (9.0.1) or minor >> (9.1.0) release? Looking historically, the version-numbers file have not >> been changed for the 8u family. The only change was going from 8 to 9 >> when creating the new jdk9 forest. That was what I based my decition to >> only have the major number in the file. (The rest of the version string >> is set by configure flags when building, in Oracle case by the RE team.) >> >> If it makes sense to put the minor/security/patch numbers here, I won't >> oppose it, but I guess we have until the first such release to figure >> out what's best, and that likely includes discussion with RE and >> possibly other consumers in the community (RedHat etc). >> >>> >>> --- >>> >>> Looking at hotspot changes I can't convince myself that the new >>> streamlined "version" variables will capture things like "fastdebug". >>> Will that filter through via configure variables? >> >> The "fastdebug" label has been handled as a less valued token in the >> JEP-223 process. Right now there's no mention of it at all in the >> version string proposal in the JEP. As I understand it, Iris is about to >> propose an amendment which will just make fastdebug be a part of the OPT >> string. I'm not entirely happy with that myself, but that's the way it's >> decided. So wherever you can see the OPT string, you'll see the debug >> level tag. >> >> Currently, however, that's not how it is implemented in this patch. >> Since no decision was made on this (and it's still not formally >> decided), I had to pick a route to go forward. The current patch will >> instead put the "fastdebug" label as part of the PRE string (that's the >> reason for the pre-base and pre-debuglevel arguments to configure). If >> the planned changes goes into the JEP, this'll change to make the >> debuglevel tag a part of the OPT string instead. >> >>> --- >>> >>> make/*/makefiles/vm.make >>> >>> Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from the >>> VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a >>> stand-alone hotspot build?) >> The hotspot JEP-223 work initially made by Alejandro kept support for >> stand-alone hotspot builds. I made additional changes on top of that, >> which still tried to cater for stand-alone builds. At this very moment >> I'm not sure if stand-alone hotspot builds are supposed to work or not, >> but I've tried to not change the situation with this patch. >> >> There are two future changes coming down the pipe: One is the additional >> JEP-223 work needed for Hotspot. I know Alejandro had plans for >> redesigning the API between Hotspot and the JDK, so no JDK version >> strings should be compiled into the JVM, but all of it extracted during >> an API in runtime. That would make most (all?) of the makefile changes >> in hotspot irrelevant. However, that implementation is not even started, >> so it's needed for the time being. >> >> The second change is the build-infra hotspot makefile rewrite. When that >> happens, stand-alone builds will definitely disappear, and if Hotspot >> still needs make support for version strings, then the logical choice is >> to use VERSION_CFLAGS. >> >> Ok? >> >>> >>> --- >>> >>> hotspot/src/share/vm/prims/jvm.h >>> jdk/src/java.base/share/native/include/jvm.h >>> >>> I think this comment is way out of date: >>> >>> /* Build number is available only for RE build (i.e. JDK_BUILD_NUMBER >>> is set to bNN) >>> * It will be zero for internal builds. >>> */ >>> >>> and can be completely removed. Even if still true, mention of an "RE >>> build" has no place in OpenJDK sources. >> Yep, agree. Follow-up patch, right? >> >>> >>> --- >>> >>> hotspot/src/share/vm/runtime/java.cpp >>> >>> I think a lot of the modified code is obsolete post Hotspot Express - >>> which makes it hard to determine if the changes make sense. >> Yep, agree. Follow-up patch, right? >>> >>> --- >>> >>> hotspot/src/share/vm/runtime/vmStructs.cpp >>> >>> Please fix the alignment (3 extra spaces on modified line): >>> >>> 1239 static_field(Abstract_VM_Version, _vm_minor_version, >>> int) \ >>> 1240 static_field(Abstract_VM_Version, >>> _vm_security_version, int) \ >> >> I was about to say "follow-up patch", but ugly indentation really sucks >> so I can fix this. Ok if I skip redoing the review for that? >> >>> >>> --- >>> >>> hotspot/test/runtime/6981737/Test6981737.java >>> >>> This test is really only valid for the new version scheme now, so it >>> should probably be rewritten - and in that case it really isn't >>> testing 6981737 but should be replaced by a new test for the new >>> version format. >> Yep, agree. Follow-up patch, right? >>> >>> --- >>> >>> jdk/src/java.base/share/classes/sun/misc/Version.java.template >>> >>> This comment is nonsensical: >>> >>> /** >>> ! * Returns the security version of the running JVM if it's 1.6 >>> or newer >>> * or any RE VM build. It will return 0 if it's an internal >>> 1.5 or >>> * 1.4.x build. >>> * @since 1.6 >>> */ >>> >>> as security version does not exist pre 9. Normally you should be >>> adding a new method and deprecating the old one. The new one is >>> @since 9. >> Yep, agree. Follow-up patch, right? >>> >>> /** >>> ! * Returns the security version of the running JDK. >>> * @since 1.6 >>> */ >>> >>> Ditto: @since 9 (but again old should be deprecated and new method >>> added) >>> >>> 253 /** >>> 254 * Returns the build number of the running JDK if it's a RE >>> build >>> 255 * It will return 0 if it's an internal build. >>> >>> As with jvm.h this seems obsolete commentary these days - not only RE >>> builds define a build number. >> Yep, agree. Follow-up patch, right? >> >> /Magnus >> >>> >>> Thanks, >>> David >> From sundararajan.athijegannathan at oracle.com Fri Jun 12 10:56:55 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 12 Jun 2015 16:26:55 +0530 Subject: RFR 8087211: Indirect evals should be strict with -strict option Message-ID: <557ABAF7.80506@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8087211/ for https://bugs.openjdk.java.net/browse/JDK-8087211 Thanks, -Sundar From marcus.lagergren at oracle.com Fri Jun 12 10:59:52 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 12 Jun 2015 12:59:52 +0200 Subject: RFR 8087211: Indirect evals should be strict with -strict option In-Reply-To: <557ABAF7.80506@oracle.com> References: <557ABAF7.80506@oracle.com> Message-ID: <876ECD50-3A4C-468B-8B46-4DF6825DBE88@oracle.com> Looks good. /M > On 12 Jun 2015, at 12:56, A. Sundararajan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8087211/ for https://bugs.openjdk.java.net/browse/JDK-8087211 > > Thanks, > -Sundar From hannes.wallnoefer at oracle.com Fri Jun 12 11:13:49 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 12 Jun 2015 13:13:49 +0200 Subject: RFR 8087211: Indirect evals should be strict with -strict option In-Reply-To: <557ABAF7.80506@oracle.com> References: <557ABAF7.80506@oracle.com> Message-ID: <557ABEED.9080606@oracle.com> +1 Am 2015-06-12 um 12:56 schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8087211/ for > https://bugs.openjdk.java.net/browse/JDK-8087211 > > Thanks, > -Sundar From kajmagnus79 at gmail.com Mon Jun 15 03:55:32 2015 From: kajmagnus79 at gmail.com (Kaj Magnus Lindberg) Date: Mon, 15 Jun 2015 05:55:32 +0200 Subject: Nashorn caches compiled code? Can I clear the cache? Message-ID: Hi, Nashorn caches compiled scripts in-meomory somehow right? Is there any way to clear this cache? I'm wondering, because when Play Framework (that's a Scala web framework) reloads my Scala application after I've edited some source code files, all Scala and Java classes are properly reloaded. (Play Framework reloads classes "live", without terminating the process.) Except for Scala code that gets run after I've called back from Nashorn to Scala: when inside Nashorn, old code gets reused, Nashorn apparently doesn't know that Play Framework wants everyone to refresh all classes. So I think perhaps I can tell Nashorn to discard its compiled code cache so it starts using the new classes instead. Can I do that somehow? Like, `some.package.Nashorn.clearCompiledScriptsCodeCache()`. I'm not sure if what I'm asking is a good idea. If not, or if it's just not possible, then I suppose I'll have to kill my app instead of just "soft-reloading" it, if I've changed anything that Nashorn uses. (The effects of Nashorn using old classes, are for example that singletons get duplicated: when inside Nashorn, a singleton object resolves to an old instance with an old field value = 333, but when outside Nashorn, the singleton resolves to a new version of the class with newly added fields and the value that was previously 333 now instead correctly shows 444 (I edited it to 444).) jjs -v nashorn 1.8.0_45 I hope this is the right place to ask. Thanks for building Nashorn and best regards, KajMagnus From attila.szegedi at oracle.com Mon Jun 15 07:31:54 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 15 Jun 2015 09:31:54 +0200 Subject: Nashorn caches compiled code? Can I clear the cache? In-Reply-To: References: Message-ID: It is absolutely the right place to ask :-) If you?re programmatically using Nashorn, code is cached within a ScriptEngine instance, so discarding a ScriptEngine and creating a new one will get rid of cached code too. Hope that helps, Attila. > On Jun 15, 2015, at 5:55 AM, Kaj Magnus Lindberg wrote: > > Hi, > > Nashorn caches compiled scripts in-meomory somehow right? Is there any way > to clear this cache? > > I'm wondering, because when Play Framework (that's a Scala web framework) > reloads my Scala application after I've edited some source code files, all > Scala and Java classes are properly reloaded. (Play Framework reloads > classes "live", without terminating the process.) Except for Scala code > that gets run after I've called back from Nashorn to Scala: when inside > Nashorn, old code gets reused, Nashorn apparently doesn't know that Play > Framework wants everyone to refresh all classes. > > So I think perhaps I can tell Nashorn to discard its compiled code cache so > it starts using the new classes instead. Can I do that somehow? Like, > `some.package.Nashorn.clearCompiledScriptsCodeCache()`. > > I'm not sure if what I'm asking is a good idea. If not, or if it's just not > possible, then I suppose I'll have to kill my app instead of just > "soft-reloading" it, if I've changed anything that Nashorn uses. > > (The effects of Nashorn using old classes, are for example that singletons > get duplicated: when inside Nashorn, a singleton object resolves to an old > instance with an old field value = 333, but when outside Nashorn, the > singleton resolves to a new version of the class with newly added fields > and the value that was previously 333 now instead correctly shows 444 (I > edited it to 444).) > > jjs -v > nashorn 1.8.0_45 > > I hope this is the right place to ask. Thanks for building Nashorn and best > regards, > KajMagnus From radu at cotescu.com Mon Jun 15 12:12:58 2015 From: radu at cotescu.com (Radu Cotescu) Date: Mon, 15 Jun 2015 12:12:58 +0000 Subject: ability to inject custom properties into a JS object Message-ID: Hello, I've recently started looking into replacing Rhino with Nashorn as the JavaScript scripting engine for Apache Sling (see SLING-4801 [0]). Once nice Rhino feature that I don't seem to be able to easily map to something from Nashorn is the ability to provide my own object wrappers, such that the resulting JS object contains some custom properties. I did notice this thread [1] but I wasn't able to reach to a conclusion regarding this feature. Is there a way to easily implement this custom object translation layer without having to implement a JSObject? The problem with this approach is that Sling script developers will have to use these custom wrapper classes (JSObjects) instead of the APIs directly available through the Bindings, making scripts written for the Rhino implementation incompatible. Thanks, Radu [0] - https://issues.apache.org/jira/browse/SLING-4801 [1] - https://www.mail-archive.com/nashorn-dev%40openjdk.java.net/msg01485.html From hannes.wallnoefer at oracle.com Mon Jun 15 12:25:37 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 15 Jun 2015 14:25:37 +0200 Subject: Review request for JDK-8086052: Script evaluation should not return last function declaration Message-ID: <557EC441.3000802@oracle.com> Please review JDK-8086052: Script evaluation should not return last function declaration: http://cr.openjdk.java.net/~hannesw/8086052/ Thanks, Hannes From hannes.wallnoefer at oracle.com Mon Jun 15 12:27:00 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 15 Jun 2015 14:27:00 +0200 Subject: Review request for JDK-8087312: PropertyMapWrapper.equals should compare className Message-ID: <557EC494.1050005@oracle.com> Please review JDK-8087312: PropertyMapWrapper.equals should compare className: http://cr.openjdk.java.net/~hannesw/8087312/ Thanks, Hannes From sundararajan.athijegannathan at oracle.com Mon Jun 15 12:38:08 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 15 Jun 2015 18:08:08 +0530 Subject: Review request for JDK-8086052: Script evaluation should not return last function declaration In-Reply-To: <557EC441.3000802@oracle.com> References: <557EC441.3000802@oracle.com> Message-ID: <557EC730.1040101@oracle.com> +1 On Monday 15 June 2015 05:55 PM, Hannes Wallnoefer wrote: > Please review JDK-8086052: Script evaluation should not return last > function declaration: > > http://cr.openjdk.java.net/~hannesw/8086052/ > > Thanks, > Hannes From sundararajan.athijegannathan at oracle.com Mon Jun 15 12:38:20 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 15 Jun 2015 18:08:20 +0530 Subject: Review request for JDK-8087312: PropertyMapWrapper.equals should compare className In-Reply-To: <557EC494.1050005@oracle.com> References: <557EC494.1050005@oracle.com> Message-ID: <557EC73C.8030407@oracle.com> +1 On Monday 15 June 2015 05:57 PM, Hannes Wallnoefer wrote: > Please review JDK-8087312: PropertyMapWrapper.equals should compare > className: > > http://cr.openjdk.java.net/~hannesw/8087312/ > > Thanks, > Hannes > From hannes.wallnoefer at oracle.com Mon Jun 15 12:50:11 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 15 Jun 2015 14:50:11 +0200 Subject: Review request for JDK-8098546: eval within a 'with' leaks definitions into global scope Message-ID: <557ECA03.70700@oracle.com> Please review JDK-8098546: eval within a 'with' leaks definitions into global scope: http://cr.openjdk.java.net/~hannesw/8098546/ Thanks, Hannes From sundararajan.athijegannathan at oracle.com Mon Jun 15 12:53:09 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 15 Jun 2015 18:23:09 +0530 Subject: ability to inject custom properties into a JS object In-Reply-To: References: Message-ID: <557ECAB5.8010509@oracle.com> Please note that nashorn has support to handle Java objects with 'bean style' property support. And you could implement Java interfaces and extend Java abstract classes in script. java.util.Map objects are treated specially to provide key-value access as properties. java.util.ArrayList objects are treated like arrays (indexed element access, length property for size). These could be used provide script-friendly access to your existing Java classes. But, if you want to write script "proxies" to trap property access etc., then there are two ways: 1) JSAdapter - you'd write JSAdapter wrapper in script. Example: https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-JSAdapterconstructor 2) Implementing jdk.nashorn.api.scripting.JSObject. https://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/JSObject.html AbstractJSObject ( https://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/AbstractJSObject.html ) provides empty/null implementation for most methods and so you can extend it as well. In addition, any @FunctionalInterface object (java.util.functions.Function etc) can be called as a script function. So, your script functions could just be Java functional interface objects. Example: https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-Plugging-inyourownJSObject Hope this helps, -Sundar On Monday 15 June 2015 05:42 PM, Radu Cotescu wrote: > Hello, > > I've recently started looking into replacing Rhino with Nashorn as the > JavaScript scripting engine for Apache Sling (see SLING-4801 [0]). > > Once nice Rhino feature that I don't seem to be able to easily map to > something from Nashorn is the ability to provide my own object wrappers, > such that the resulting JS object contains some custom properties. I did > notice this thread [1] but I wasn't able to reach to a conclusion regarding > this feature. > > Is there a way to easily implement this custom object translation layer > without having to implement a JSObject? The problem with this approach is > that Sling script developers will have to use these custom wrapper classes > (JSObjects) instead of the APIs directly available through the Bindings, > making scripts written for the Rhino implementation incompatible. > > Thanks, > Radu > > [0] - https://issues.apache.org/jira/browse/SLING-4801 > [1] - > https://www.mail-archive.com/nashorn-dev%40openjdk.java.net/msg01485.html From hannes.wallnoefer at oracle.com Mon Jun 15 13:13:21 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 15 Jun 2015 15:13:21 +0200 Subject: Review request for JDK-8098546: eval within a 'with' leaks definitions into global scope In-Reply-To: <557ECA03.70700@oracle.com> References: <557ECA03.70700@oracle.com> Message-ID: <557ECF71.5070109@oracle.com> I uploaded a new webrev that overrides addBoundProperties(ScriptObject, Properties[]) in WithObject instead of adding code to ScriptRuntime.mergeScopes. This is a bit more elegant than the previous solution. http://cr.openjdk.java.net/~hannesw/8098546/webrev.01/ Hannes Am 2015-06-15 um 14:50 schrieb Hannes Wallnoefer: > Please review JDK-8098546: eval within a 'with' leaks definitions into > global scope: > > http://cr.openjdk.java.net/~hannesw/8098546/ > > Thanks, > Hannes From sundararajan.athijegannathan at oracle.com Mon Jun 15 13:14:01 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 15 Jun 2015 18:44:01 +0530 Subject: Review request for JDK-8098546: eval within a 'with' leaks definitions into global scope In-Reply-To: <557ECF71.5070109@oracle.com> References: <557ECA03.70700@oracle.com> <557ECF71.5070109@oracle.com> Message-ID: <557ECF99.1020105@oracle.com> +1 Nice fix! -Sundar On Monday 15 June 2015 06:43 PM, Hannes Wallnoefer wrote: > I uploaded a new webrev that overrides > addBoundProperties(ScriptObject, Properties[]) in WithObject instead > of adding code to ScriptRuntime.mergeScopes. This is a bit more > elegant than the previous solution. > > http://cr.openjdk.java.net/~hannesw/8098546/webrev.01/ > > Hannes > > > Am 2015-06-15 um 14:50 schrieb Hannes Wallnoefer: >> Please review JDK-8098546: eval within a 'with' leaks definitions >> into global scope: >> >> http://cr.openjdk.java.net/~hannesw/8098546/ >> >> Thanks, >> Hannes > From attila.szegedi at oracle.com Mon Jun 15 13:22:04 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 15 Jun 2015 15:22:04 +0200 Subject: Review request for JDK-8098546: eval within a 'with' leaks definitions into global scope In-Reply-To: <557ECF71.5070109@oracle.com> References: <557ECA03.70700@oracle.com> <557ECF71.5070109@oracle.com> Message-ID: +1 > On Jun 15, 2015, at 3:13 PM, Hannes Wallnoefer wrote: > > I uploaded a new webrev that overrides addBoundProperties(ScriptObject, Properties[]) in WithObject instead of adding code to ScriptRuntime.mergeScopes. This is a bit more elegant than the previous solution. > > http://cr.openjdk.java.net/~hannesw/8098546/webrev.01/ > > Hannes > > > Am 2015-06-15 um 14:50 schrieb Hannes Wallnoefer: >> Please review JDK-8098546: eval within a 'with' leaks definitions into global scope: >> >> http://cr.openjdk.java.net/~hannesw/8098546/ >> >> Thanks, >> Hannes > From attila.szegedi at oracle.com Mon Jun 15 13:22:15 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 15 Jun 2015 15:22:15 +0200 Subject: Review request for JDK-8087312: PropertyMapWrapper.equals should compare className In-Reply-To: <557EC494.1050005@oracle.com> References: <557EC494.1050005@oracle.com> Message-ID: <9EBFB90B-06C8-4E33-8D9D-A665621874B0@oracle.com> +1 > On Jun 15, 2015, at 2:27 PM, Hannes Wallnoefer wrote: > > Please review JDK-8087312: PropertyMapWrapper.equals should compare className: > > http://cr.openjdk.java.net/~hannesw/8087312/ > > Thanks, > Hannes > From attila.szegedi at oracle.com Mon Jun 15 13:22:24 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 15 Jun 2015 15:22:24 +0200 Subject: Review request for JDK-8086052: Script evaluation should not return last function declaration In-Reply-To: <557EC441.3000802@oracle.com> References: <557EC441.3000802@oracle.com> Message-ID: <64106F49-6237-4A92-BB47-4A45CC0DB073@oracle.com> +1 > On Jun 15, 2015, at 2:25 PM, Hannes Wallnoefer wrote: > > Please review JDK-8086052: Script evaluation should not return last function declaration: > > http://cr.openjdk.java.net/~hannesw/8086052/ > > Thanks, > Hannes From sundararajan.athijegannathan at oracle.com Tue Jun 16 07:11:01 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 16 Jun 2015 12:41:01 +0530 Subject: RFR 8098578: Global scope is not accessible with indirect load call Message-ID: <557FCC05.6060605@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8098578/ for https://bugs.openjdk.java.net/browse/JDK-8098578 -Sundar From radu at cotescu.com Tue Jun 16 08:01:03 2015 From: radu at cotescu.com (Radu Cotescu) Date: Tue, 16 Jun 2015 08:01:03 +0000 Subject: ability to inject custom properties into a JS object In-Reply-To: <557ECAB5.8010509@oracle.com> References: <557ECAB5.8010509@oracle.com> Message-ID: Hi Sundar, Thank you for your quick reply! I did read about JSAdapter and JSObject before my initial email but I don't think they actually do what I want. In my use-case I need to be able to interfere with object translation (from Java to JavaScript) for all instances of a certain Java class, not just for specific objects. Is there any way I could achieve this (something similar to Rhino's host objects [2])? Thanks, Radu [2] - https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino/Embedding_tutorial#JavaScript_host_objects On Mon, 15 Jun 2015 at 15:23 A. Sundararajan < sundararajan.athijegannathan at oracle.com> wrote: > Please note that nashorn has support to handle Java objects with 'bean > style' property support. And you could implement Java interfaces and > extend Java abstract classes in script. java.util.Map objects are > treated specially to provide key-value access as properties. > java.util.ArrayList objects are treated like arrays (indexed element > access, length property for size). These could be used provide > script-friendly access to your existing Java classes. > > But, if you want to write script "proxies" to trap property access etc., > then there are two ways: > > 1) JSAdapter - you'd write JSAdapter wrapper in script. > > Example: > > > https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-JSAdapterconstructor > > 2) Implementing jdk.nashorn.api.scripting.JSObject. > > > https://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/JSObject.html > > AbstractJSObject ( > > https://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/AbstractJSObject.html > ) provides empty/null implementation for most methods and so you can > extend it as well. > > In addition, any @FunctionalInterface object > (java.util.functions.Function etc) can be called as a script function. > So, your script functions could just be Java functional interface objects. > > Example: > > > https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-Plugging-inyourownJSObject > > Hope this helps, > -Sundar > > On Monday 15 June 2015 05:42 PM, Radu Cotescu wrote: > > Hello, > > > > I've recently started looking into replacing Rhino with Nashorn as the > > JavaScript scripting engine for Apache Sling (see SLING-4801 [0]). > > > > Once nice Rhino feature that I don't seem to be able to easily map to > > something from Nashorn is the ability to provide my own object wrappers, > > such that the resulting JS object contains some custom properties. I did > > notice this thread [1] but I wasn't able to reach to a conclusion > regarding > > this feature. > > > > Is there a way to easily implement this custom object translation layer > > without having to implement a JSObject? The problem with this approach is > > that Sling script developers will have to use these custom wrapper > classes > > (JSObjects) instead of the APIs directly available through the Bindings, > > making scripts written for the Rhino implementation incompatible. > > > > Thanks, > > Radu > > > > [0] - https://issues.apache.org/jira/browse/SLING-4801 > > [1] - > > > https://www.mail-archive.com/nashorn-dev%40openjdk.java.net/msg01485.html > > From hannes.wallnoefer at oracle.com Tue Jun 16 10:40:20 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 16 Jun 2015 12:40:20 +0200 Subject: Review request for JDK-8098807: Strict eval throws ClassCastException with large scripts Message-ID: <557FFD14.2020707@oracle.com> Please review JDK-8098807: Strict eval throws ClassCastException with large scripts: http://cr.openjdk.java.net/~hannesw/8098807/ Thanks, Hannes From sundararajan.athijegannathan at oracle.com Tue Jun 16 10:43:16 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 16 Jun 2015 16:13:16 +0530 Subject: Review request for JDK-8098807: Strict eval throws ClassCastException with large scripts In-Reply-To: <557FFD14.2020707@oracle.com> References: <557FFD14.2020707@oracle.com> Message-ID: <557FFDC4.1010801@oracle.com> payload script misses copyright. Other than that +1 -Sundar On Tuesday 16 June 2015 04:10 PM, Hannes Wallnoefer wrote: > Please review JDK-8098807: Strict eval throws ClassCastException with > large scripts: > > http://cr.openjdk.java.net/~hannesw/8098807/ > > Thanks, > Hannes From attila.szegedi at oracle.com Tue Jun 16 11:22:38 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 16 Jun 2015 13:22:38 +0200 Subject: Review request for JDK-8098807: Strict eval throws ClassCastException with large scripts In-Reply-To: <557FFD14.2020707@oracle.com> References: <557FFD14.2020707@oracle.com> Message-ID: <5671487A-A57D-4E9C-985E-F91AF500ADD3@oracle.com> +1 > On Jun 16, 2015, at 12:40 PM, Hannes Wallnoefer wrote: > > Please review JDK-8098807: Strict eval throws ClassCastException with large scripts: > > http://cr.openjdk.java.net/~hannesw/8098807/ > > Thanks, > Hannes From attila.szegedi at oracle.com Tue Jun 16 11:23:27 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 16 Jun 2015 13:23:27 +0200 Subject: RFR 8098578: Global scope is not accessible with indirect load call In-Reply-To: <557FCC05.6060605@oracle.com> References: <557FCC05.6060605@oracle.com> Message-ID: <83C3F87B-0261-49EF-B41E-A7E39A185452@oracle.com> +1 > On Jun 16, 2015, at 9:11 AM, A. Sundararajan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8098578/ for https://bugs.openjdk.java.net/browse/JDK-8098578 > > -Sundar From alejandro.murillo at oracle.com Wed Jun 10 17:21:59 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 10 Jun 2015 11:21:59 -0600 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <557829DC.8000405@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> <55780A33.1010302@oracle.com> <557829DC.8000405@oracle.com> Message-ID: <55787237.20802@oracle.com> On 6/10/2015 6:13 AM, Magnus Ihse Bursie wrote: > On 2015-06-10 11:58, David Holmes wrote: >> Hi Magnus, >> >> Generally looks good - a few comments/queries below. > > In general, I believe most issues you found are valid. :-) However, as > I said before in this thread, I'd like to see them resolved in the > needed follow-up patches. The source code changes in Hotspot and JDK > are inadequate to fully implement JEP-223, so these areas will need to > be rewritten anyhow. Are you okay with resolving these issues later? > >> >> On 9/06/2015 11:52 PM, Magnus Ihse Bursie wrote: >>> Here's an updated webrev, which fixes the typos that were pointed >>> out by >>> reviewers: >>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ >>> >> >> common/autoconf/version-numbers >> >> Shouldn't there be a DEFAULT_VERSION_XXX for each of the XXX parts of >> the version info? (Even if all zeroes presently.) > So that's a tricky one. :-& The question here is, I think, does it > make sense to update version-numbers when we do a security (9.0.1) or > minor (9.1.0) release? Looking historically, the version-numbers file > have not been changed for the 8u family. The only change was going > from 8 to 9 when creating the new jdk9 forest. That was what I based > my decition to only have the major number in the file. (The rest of > the version string is set by configure flags when building, in Oracle > case by the RE team.) > > If it makes sense to put the minor/security/patch numbers here, I > won't oppose it, but I guess we have until the first such release to > figure out what's best, and that likely includes discussion with RE > and possibly other consumers in the community (RedHat etc). > >> >> --- >> >> Looking at hotspot changes I can't convince myself that the new >> streamlined "version" variables will capture things like "fastdebug". >> Will that filter through via configure variables? > > The "fastdebug" label has been handled as a less valued token in the > JEP-223 process. Right now there's no mention of it at all in the > version string proposal in the JEP. As I understand it, Iris is about > to propose an amendment which will just make fastdebug be a part of > the OPT string. I'm not entirely happy with that myself, but that's > the way it's decided. So wherever you can see the OPT string, you'll > see the debug level tag. > > Currently, however, that's not how it is implemented in this patch. > Since no decision was made on this (and it's still not formally > decided), I had to pick a route to go forward. The current patch will > instead put the "fastdebug" label as part of the PRE string (that's > the reason for the pre-base and pre-debuglevel arguments to > configure). If the planned changes goes into the JEP, this'll change > to make the debuglevel tag a part of the OPT string instead. > >> --- >> >> make/*/makefiles/vm.make >> >> Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from >> the VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a >> stand-alone hotspot build?) > The hotspot JEP-223 work initially made by Alejandro kept support for > stand-alone hotspot builds. I made additional changes on top of that, > which still tried to cater for stand-alone builds. At this very moment > I'm not sure if stand-alone hotspot builds are supposed to work or > not, but I've tried to not change the situation with this patch. > > There are two future changes coming down the pipe: One is the > additional JEP-223 work needed for Hotspot. I know Alejandro had plans > for redesigning the API between Hotspot and the JDK, so no JDK version > strings should be compiled into the JVM, but all of it extracted > during an API in runtime. That would make most (all?) of the makefile > changes in hotspot irrelevant. However, that implementation is not > even started, so it's needed for the time being. There's already an API used by Hotspot to get JDK version values. I'm investigating using that and extend it if required. yes, there is a lot stuff in the hotspot code that should be removed (mostly in the makefiles) and I'm not against making those changes now, I just think they are somewhat out of the scope of this project. And should be done as individual RFEs or as part of the upcoming hotspot makefile refactoring. Alejandro > > The second change is the build-infra hotspot makefile rewrite. When > that happens, stand-alone builds will definitely disappear, and if > Hotspot still needs make support for version strings, then the logical > choice is to use VERSION_CFLAGS. > > Ok? > >> >> --- >> >> hotspot/src/share/vm/prims/jvm.h >> jdk/src/java.base/share/native/include/jvm.h >> >> I think this comment is way out of date: >> >> /* Build number is available only for RE build (i.e. >> JDK_BUILD_NUMBER is set to bNN) >> * It will be zero for internal builds. >> */ >> >> and can be completely removed. Even if still true, mention of an "RE >> build" has no place in OpenJDK sources. > Yep, agree. Follow-up patch, right? > >> >> --- >> >> hotspot/src/share/vm/runtime/java.cpp >> >> I think a lot of the modified code is obsolete post Hotspot Express - >> which makes it hard to determine if the changes make sense. > Yep, agree. Follow-up patch, right? >> >> --- >> >> hotspot/src/share/vm/runtime/vmStructs.cpp >> >> Please fix the alignment (3 extra spaces on modified line): >> >> 1239 static_field(Abstract_VM_Version, _vm_minor_version, >> int) \ >> 1240 static_field(Abstract_VM_Version, _vm_security_version, >> int) \ > > I was about to say "follow-up patch", but ugly indentation really > sucks so I can fix this. Ok if I skip redoing the review for that? > >> >> --- >> >> hotspot/test/runtime/6981737/Test6981737.java >> >> This test is really only valid for the new version scheme now, so it >> should probably be rewritten - and in that case it really isn't >> testing 6981737 but should be replaced by a new test for the new >> version format. > Yep, agree. Follow-up patch, right? >> >> --- >> >> jdk/src/java.base/share/classes/sun/misc/Version.java.template >> >> This comment is nonsensical: >> >> /** >> ! * Returns the security version of the running JVM if it's 1.6 >> or newer >> * or any RE VM build. It will return 0 if it's an internal 1.5 or >> * 1.4.x build. >> * @since 1.6 >> */ >> >> as security version does not exist pre 9. Normally you should be >> adding a new method and deprecating the old one. The new one is >> @since 9. > Yep, agree. Follow-up patch, right? >> >> /** >> ! * Returns the security version of the running JDK. >> * @since 1.6 >> */ >> >> Ditto: @since 9 (but again old should be deprecated and new method >> added) >> >> 253 /** >> 254 * Returns the build number of the running JDK if it's a RE >> build >> 255 * It will return 0 if it's an internal build. >> >> As with jvm.h this seems obsolete commentary these days - not only RE >> builds define a build number. > Yep, agree. Follow-up patch, right? > > /Magnus > >> >> Thanks, >> David > -- Alejandro From sundararajan.athijegannathan at oracle.com Tue Jun 16 12:27:38 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 16 Jun 2015 17:57:38 +0530 Subject: RFR 8098578: Global scope is not accessible with indirect load call In-Reply-To: <557FCC05.6060605@oracle.com> References: <557FCC05.6060605@oracle.com> Message-ID: <5580163A.9030303@oracle.com> Please review updated http://cr.openjdk.java.net/~sundar/8098578/webrev.01/ Fixed comments per internal suggestions (updated in bug report) and also using newScope() to be able to handle large script with indirect load call. Thanks, -Sundar On Tuesday 16 June 2015 12:41 PM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8098578/ for > https://bugs.openjdk.java.net/browse/JDK-8098578 > > -Sundar From hannes.wallnoefer at oracle.com Tue Jun 16 12:48:10 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 16 Jun 2015 14:48:10 +0200 Subject: RFR 8098578: Global scope is not accessible with indirect load call In-Reply-To: <5580163A.9030303@oracle.com> References: <557FCC05.6060605@oracle.com> <5580163A.9030303@oracle.com> Message-ID: <55801B0A.4010001@oracle.com> Looks good. Hannes Am 2015-06-16 um 14:27 schrieb A. Sundararajan: > Please review updated > http://cr.openjdk.java.net/~sundar/8098578/webrev.01/ > > Fixed comments per internal suggestions (updated in bug report) and > also using newScope() to be able to handle large script with indirect > load call. > > Thanks, > -Sundar > > On Tuesday 16 June 2015 12:41 PM, A. Sundararajan wrote: >> Please review http://cr.openjdk.java.net/~sundar/8098578/ for >> https://bugs.openjdk.java.net/browse/JDK-8098578 >> >> -Sundar > From attila.szegedi at oracle.com Tue Jun 16 12:49:42 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 16 Jun 2015 14:49:42 +0200 Subject: RFR 8098578: Global scope is not accessible with indirect load call In-Reply-To: <5580163A.9030303@oracle.com> References: <557FCC05.6060605@oracle.com> <5580163A.9030303@oracle.com> Message-ID: <47DFD4A5-5D2B-4757-9013-43DC159F8E56@oracle.com> + assert ((ScriptObject)scope).isGlobal() : "non-Global scope object!!"; + final ScriptObject sobj = (ScriptObject)scope; You could swap these two lines and use "sobj" in assert. +1 otherwise; it?s okay from me to push after these changes. Attila. > On Jun 16, 2015, at 2:27 PM, A. Sundararajan wrote: > > Please review updated http://cr.openjdk.java.net/~sundar/8098578/webrev.01/ > > Fixed comments per internal suggestions (updated in bug report) and also using newScope() to be able to handle large script with indirect load call. > > Thanks, > -Sundar > > On Tuesday 16 June 2015 12:41 PM, A. Sundararajan wrote: >> Please review http://cr.openjdk.java.net/~sundar/8098578/ for https://bugs.openjdk.java.net/browse/JDK-8098578 >> >> -Sundar > From sundararajan.athijegannathan at oracle.com Tue Jun 16 12:53:15 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 16 Jun 2015 18:23:15 +0530 Subject: RFR 8098578: Global scope is not accessible with indirect load call In-Reply-To: <47DFD4A5-5D2B-4757-9013-43DC159F8E56@oracle.com> References: <557FCC05.6060605@oracle.com> <5580163A.9030303@oracle.com> <47DFD4A5-5D2B-4757-9013-43DC159F8E56@oracle.com> Message-ID: <55801C3B.8060408@oracle.com> Thanks. PS. Uploaded updated webrev : http://cr.openjdk.java.net/~sundar/8098578/webrev.02/ of changes that I'll push. -Sundar On Tuesday 16 June 2015 06:19 PM, Attila Szegedi wrote: > + assert ((ScriptObject)scope).isGlobal() : "non-Global scope object!!"; > + final ScriptObject sobj = (ScriptObject)scope; > > You could swap these two lines and use "sobj" in assert. > > +1 otherwise; it?s okay from me to push after these changes. > > Attila. > >> On Jun 16, 2015, at 2:27 PM, A. Sundararajan wrote: >> >> Please review updated http://cr.openjdk.java.net/~sundar/8098578/webrev.01/ >> >> Fixed comments per internal suggestions (updated in bug report) and also using newScope() to be able to handle large script with indirect load call. >> >> Thanks, >> -Sundar >> >> On Tuesday 16 June 2015 12:41 PM, A. Sundararajan wrote: >>> Please review http://cr.openjdk.java.net/~sundar/8098578/ for https://bugs.openjdk.java.net/browse/JDK-8098578 >>> >>> -Sundar From hannes.wallnoefer at oracle.com Tue Jun 16 14:05:07 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 16 Jun 2015 16:05:07 +0200 Subject: Review request for JDK-8098808: Convert Scope from interface to class Message-ID: <55802D13.9050707@oracle.com> Please review JDK-8098808: Convert Scope from interface to class: http://cr.openjdk.java.net/~hannesw/8098808/ Thanks, Hannes From sundararajan.athijegannathan at oracle.com Tue Jun 16 14:46:35 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 16 Jun 2015 20:16:35 +0530 Subject: Review request for JDK-8098808: Convert Scope from interface to class In-Reply-To: <55802D13.9050707@oracle.com> References: <55802D13.9050707@oracle.com> Message-ID: <558036CB.5070408@oracle.com> +1 On Tuesday 16 June 2015 07:35 PM, Hannes Wallnoefer wrote: > Please review JDK-8098808: Convert Scope from interface to class: > > http://cr.openjdk.java.net/~hannesw/8098808/ > > Thanks, > Hannes From andreas.woess at oracle.com Tue Jun 16 15:56:42 2015 From: andreas.woess at oracle.com (Andreas Woess) Date: Tue, 16 Jun 2015 17:56:42 +0200 Subject: a few minor bugs Message-ID: <5580473A.7080002@oracle.com> Dear Nashorn team, I'd like to bring a few very minor implementation bugs to your attention (proper JS programs are not affected). > obj."prop" > obj.'prop' should be a SyntaxError, but is not in Nashorn. (even with -nse) > Parser.java:719 #program > final Block programBody = new Block(functionToken, functionLine, > body.getFlags() | Block.IS_SYNTHETIC, body.getStatements()); s/functionLine/finish/ > Parser.java:497 #createFunctionNode > Token.descPosition(body.getToken()), Supplied finish parameter to new FunctionNode is Token.descPosition(body.getToken()). I'd have expected the finish of the body to be passed here. > ScriptObject.java:402 > public final boolean isGenericDescriptor() { > return isAccessorDescriptor() || isDataDescriptor(); > } This method returns the opposite of what the standard describes. Actually it's unused. A follow-up bug on JDK-8056123: > with({}){ /*force vars into scope*/ > function () { /*line 2*/ > print("hello from nashorn"); > } > } > > print(this["L:2"]); // print function on line 2 expected: undefined actual: function ... I wonder if there's a particular reason for having the assignment (var L:2 = function ...) in the AST in the first place. and finally, BooleanType.java: duplicate license header Version: some recent jdk9/dev/nashorn revision. - andreas From sundararajan.athijegannathan at oracle.com Tue Jun 16 17:45:51 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 16 Jun 2015 23:15:51 +0530 Subject: RFR 8098847: obj."prop" and obj.'prop' should result in SyntaxError Message-ID: <558060CF.80209@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8098847/ for https://bugs.openjdk.java.net/browse/JDK-8098847 PS. This is one of the issues reported in http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-June/004776.html Thanks, -Sundar From hannes.wallnoefer at oracle.com Wed Jun 17 07:22:51 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 17 Jun 2015 09:22:51 +0200 Subject: RFR 8098847: obj."prop" and obj.'prop' should result in SyntaxError In-Reply-To: <558060CF.80209@oracle.com> References: <558060CF.80209@oracle.com> Message-ID: <5581204B.2050501@oracle.com> +1 Am 2015-06-16 um 19:45 schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8098847/ for > https://bugs.openjdk.java.net/browse/JDK-8098847 > > PS. This is one of the issues reported in > http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-June/004776.html > > Thanks, > -Sundar From attila.szegedi at oracle.com Wed Jun 17 07:42:04 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 17 Jun 2015 09:42:04 +0200 Subject: Review request for JDK-8098808: Convert Scope from interface to class In-Reply-To: <55802D13.9050707@oracle.com> References: <55802D13.9050707@oracle.com> Message-ID: <9F7F2E7F-8E35-4268-A336-66E10FD69491@oracle.com> +1 > On Jun 16, 2015, at 4:05 PM, Hannes Wallnoefer wrote: > > Please review JDK-8098808: Convert Scope from interface to class: > > http://cr.openjdk.java.net/~hannesw/8098808/ > > Thanks, > Hannes From attila.szegedi at oracle.com Wed Jun 17 07:47:39 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 17 Jun 2015 09:47:39 +0200 Subject: RFR 8098847: obj."prop" and obj.'prop' should result in SyntaxError In-Reply-To: <558060CF.80209@oracle.com> References: <558060CF.80209@oracle.com> Message-ID: <94C03E55-3C2F-4086-9217-65E658E5DE32@oracle.com> +1 > On Jun 16, 2015, at 7:45 PM, A. Sundararajan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8098847/ for https://bugs.openjdk.java.net/browse/JDK-8098847 > > PS. This is one of the issues reported in http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-June/004776.html > > Thanks, > -Sundar From attila.szegedi at oracle.com Wed Jun 17 09:06:40 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 17 Jun 2015 11:06:40 +0200 Subject: Review request for JDK-8098808: Convert Scope from interface to class In-Reply-To: <9F7F2E7F-8E35-4268-A336-66E10FD69491@oracle.com> References: <55802D13.9050707@oracle.com> <9F7F2E7F-8E35-4268-A336-66E10FD69491@oracle.com> Message-ID: <4D8ED3B3-B972-4306-9A9C-42EFABDDF0D9@oracle.com> One minor nitpick I have is that the order of arguments in the constructor for Scope is the opposite of what it was in FunctionScope; you might want to fix that before the push, but in any case it?s +1. > On Jun 17, 2015, at 9:42 AM, Attila Szegedi wrote: > > +1 > >> On Jun 16, 2015, at 4:05 PM, Hannes Wallnoefer wrote: >> >> Please review JDK-8098808: Convert Scope from interface to class: >> >> http://cr.openjdk.java.net/~hannesw/8098808/ >> >> Thanks, >> Hannes > From sundararajan.athijegannathan at oracle.com Wed Jun 17 10:31:30 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 17 Jun 2015 16:01:30 +0530 Subject: a few minor bugs In-Reply-To: <5580473A.7080002@oracle.com> References: <5580473A.7080002@oracle.com> Message-ID: <55814C82.5030003@oracle.com> Hi, Thanks for reporting these issues. Filed a bug and fix for obj."prop" http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/7e06231229fd Filed a bug for anon-func-inside-with issue https://bugs.openjdk.java.net/browse/JDK-8114838 Rest being code clean up issues, we'll piggyback with other fixes. Thanks again! -Sundar On Tuesday 16 June 2015 09:26 PM, Andreas Woess wrote: > Dear Nashorn team, > > I'd like to bring a few very minor implementation bugs to your > attention (proper JS programs are not affected). > >> obj."prop" >> obj.'prop' > should be a SyntaxError, but is not in Nashorn. (even with -nse) >> Parser.java:719 #program >> final Block programBody = new Block(functionToken, functionLine, >> body.getFlags() | Block.IS_SYNTHETIC, body.getStatements()); > s/functionLine/finish/ >> Parser.java:497 #createFunctionNode >> Token.descPosition(body.getToken()), > Supplied finish parameter to new FunctionNode is > Token.descPosition(body.getToken()). I'd have expected the finish of > the body to be passed here. >> ScriptObject.java:402 >> public final boolean isGenericDescriptor() { >> return isAccessorDescriptor() || isDataDescriptor(); >> } > This method returns the opposite of what the standard describes. > Actually it's unused. > > A follow-up bug on JDK-8056123: >> with({}){ /*force vars into scope*/ >> function () { /*line 2*/ >> print("hello from nashorn"); >> } >> } >> >> print(this["L:2"]); // print function on line 2 > expected: undefined > actual: function ... > I wonder if there's a particular reason for having the assignment (var > L:2 = function ...) in the AST in the first place. > > and finally, BooleanType.java: duplicate license header > > Version: some recent jdk9/dev/nashorn revision. > > - andreas From hannes.wallnoefer at oracle.com Wed Jun 17 10:47:12 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 17 Jun 2015 12:47:12 +0200 Subject: Review request for JDK-8098808: Convert Scope from interface to class In-Reply-To: <4D8ED3B3-B972-4306-9A9C-42EFABDDF0D9@oracle.com> References: <55802D13.9050707@oracle.com> <9F7F2E7F-8E35-4268-A336-66E10FD69491@oracle.com> <4D8ED3B3-B972-4306-9A9C-42EFABDDF0D9@oracle.com> Message-ID: <55815030.60504@oracle.com> Yes, I noticed that as well. I decided to follow the ScriptObject (super class) parameter order in Scope. I could have changed order in FunctionScope as well, but that class is only used in generated code, so it didn't seem worth it. Thanks for the review. Hannes Am 2015-06-17 um 11:06 schrieb Attila Szegedi: > One minor nitpick I have is that the order of arguments in the constructor for Scope is the opposite of what it was in FunctionScope; you might want to fix that before the push, but in any case it?s +1. > >> On Jun 17, 2015, at 9:42 AM, Attila Szegedi wrote: >> >> +1 >> >>> On Jun 16, 2015, at 4:05 PM, Hannes Wallnoefer wrote: >>> >>> Please review JDK-8098808: Convert Scope from interface to class: >>> >>> http://cr.openjdk.java.net/~hannesw/8098808/ >>> >>> Thanks, >>> Hannes From asashour at yahoo.com Wed Jun 17 13:46:11 2015 From: asashour at yahoo.com (Ahmed Ashour) Date: Wed, 17 Jun 2015 13:46:11 +0000 (UTC) Subject: Nasgen: static initializer prefix: member count is sometimes 1 more than what is needed In-Reply-To: References: Message-ID: <1295260846.466776.1434548771217.JavaMail.yahoo@mail.yahoo.com> Hi all, During digging a little into the bytecode generated by Nasgen, there is a pattern of "new ArrayList(memberCount)", but that member count is 1 more that what is needed, this is not always the case, as it depends on the members. This doesn't have functional impact, but every single byte counts ;) The root cause for Prototype, is that Constructor are included in the total count, but it is not added. To give example: NativeArrayBuffer$Prototype: ? ?{? ? ? ArrayList list = new ArrayList(2); ? ? ? list.add(AccessorProperty.create("slice", 2, "G$slice", "S$slice"));? ? ? $nasgenmap$ = PropertyMap.newMap(list);? ?} although the list will contain a single entry, ArrayList was initialized by 2. This also happens in the ScriptClass, e.g.: NativeArray:? ?{? ? ? ArrayList list = new ArrayList(2); ? ? ? list.add(AccessorProperty.create("length", 6, "length", "length"));? ? ? $nasgenmap$ = PropertyMap.newMap(list);? ?} But it is fine in, e.g.: ArrayBufferView:? ?{? ? ? ArrayList list = new ArrayList(4);? ? ??list.add(AccessorProperty.create("buffer", 7, "buffer", (MethodHandle)null));? ? ??list.add(AccessorProperty.create("byteOffset", 7, "byteOffset", (MethodHandle)null));? ? ??list.add(AccessorProperty.create("byteLength", 7, "byteLength", (MethodHandle)null));? ? ??list.add(AccessorProperty.create("length", 7, "length", (MethodHandle)null));? ? ? $nasgenmap$ = PropertyMap.newMap(list);? ?} Thanks,Ahmed From sundararajan.athijegannathan at oracle.com Wed Jun 17 16:53:07 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 17 Jun 2015 22:23:07 +0530 Subject: Nasgen: static initializer prefix: member count is sometimes 1 more than what is needed In-Reply-To: <1295260846.466776.1434548771217.JavaMail.yahoo@mail.yahoo.com> References: <1295260846.466776.1434548771217.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5581A5F3.9070604@oracle.com> Hi, Good find! Filed a bug: https://bugs.openjdk.java.net/browse/JDK-8117883 Thanks, -Sundar On Wednesday 17 June 2015 07:16 PM, Ahmed Ashour wrote: > Hi all, > During digging a little into the bytecode generated by Nasgen, there is a pattern of "new ArrayList(memberCount)", but that member count is 1 more that what is needed, this is not always the case, as it depends on the members. > This doesn't have functional impact, but every single byte counts;) > The root cause for Prototype, is that Constructor are included in the total count, but it is not added. > > To give example: > NativeArrayBuffer$Prototype: > > { ArrayList list = new ArrayList(2); > list.add(AccessorProperty.create("slice", 2, "G$slice", "S$slice")); $nasgenmap$ = PropertyMap.newMap(list); } > although the list will contain a single entry, ArrayList was initialized by 2. > This also happens in the ScriptClass, e.g.: > NativeArray: { ArrayList list = new ArrayList(2); > list.add(AccessorProperty.create("length", 6, "length", "length")); $nasgenmap$ = PropertyMap.newMap(list); } > But it is fine in, e.g.: > ArrayBufferView: { ArrayList list = new ArrayList(4); list.add(AccessorProperty.create("buffer", 7, "buffer", (MethodHandle)null)); list.add(AccessorProperty.create("byteOffset", 7, "byteOffset", (MethodHandle)null)); list.add(AccessorProperty.create("byteLength", 7, "byteLength", (MethodHandle)null)); list.add(AccessorProperty.create("length", 7, "length", (MethodHandle)null)); $nasgenmap$ = PropertyMap.newMap(list); } > Thanks,Ahmed From sundararajan.athijegannathan at oracle.com Wed Jun 17 17:20:32 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 17 Jun 2015 22:50:32 +0530 Subject: RFR 8117883: nasgen prototype, instance member count calculation is wrong Message-ID: <5581AC60.8070401@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8117883/ for https://bugs.openjdk.java.net/browse/JDK-8117883 Thanks, -Sundar From asashour at yahoo.com Wed Jun 17 19:41:41 2015 From: asashour at yahoo.com (Ahmed Ashour) Date: Wed, 17 Jun 2015 19:41:41 +0000 (UTC) Subject: RFR 8117883: nasgen prototype, instance member count calculation is wrong In-Reply-To: <5581AC60.8070401@oracle.com> References: <5581AC60.8070401@oracle.com> Message-ID: <920045894.810339.1434570101542.JavaMail.yahoo@mail.yahoo.com> Hi Sundar, Works great, thanks for the quick response. I don't fully understand the removal of?ScriptObject.isGenericDescriptor I guess users are not allowed to be created in bugs.openjdk.java.net. Thanks again,Ahmed From: A. Sundararajan To: "nashorn-dev at openjdk.java.net" Sent: Wednesday, June 17, 2015 7:20 PM Subject: RFR 8117883: nasgen prototype, instance member count calculation is wrong Please review http://cr.openjdk.java.net/~sundar/8117883/ for https://bugs.openjdk.java.net/browse/JDK-8117883 Thanks, -Sundar From sundararajan.athijegannathan at oracle.com Thu Jun 18 03:46:53 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 18 Jun 2015 09:16:53 +0530 Subject: RFR 8117883: nasgen prototype, instance member count calculation is wrong In-Reply-To: <920045894.810339.1434570101542.JavaMail.yahoo@mail.yahoo.com> References: <5581AC60.8070401@oracle.com> <920045894.810339.1434570101542.JavaMail.yahoo@mail.yahoo.com> Message-ID: <55823F2D.9020901@oracle.com> Hi, That one is a code clean up that I piggybacked :) ScriptObject.isGenericDescriptor is an unused method - so I deleted it. -Sundar On Thursday 18 June 2015 01:11 AM, Ahmed Ashour wrote: > Hi Sundar, > Works great, thanks for the quick response. > I don't fully understand the removal of ScriptObject.isGenericDescriptor > I guess users are not allowed to be created in bugs.openjdk.java.net. > Thanks again,Ahmed From: A. Sundararajan > To: "nashorn-dev at openjdk.java.net" > Sent: Wednesday, June 17, 2015 7:20 PM > Subject: RFR 8117883: nasgen prototype, instance member count calculation is wrong > > Please review http://cr.openjdk.java.net/~sundar/8117883/ for > https://bugs.openjdk.java.net/browse/JDK-8117883 > > Thanks, > -Sundar > > > From asashour at yahoo.com Thu Jun 18 06:27:41 2015 From: asashour at yahoo.com (Ahmed Ashour) Date: Thu, 18 Jun 2015 06:27:41 +0000 (UTC) Subject: RFR 8117883: nasgen prototype, instance member count calculation is wrong In-Reply-To: <920045894.810339.1434570101542.JavaMail.yahoo@mail.yahoo.com> References: <5581AC60.8070401@oracle.com> <920045894.810339.1434570101542.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1081901499.1163288.1434608861771.JavaMail.yahoo@mail.yahoo.com> Hi Sundar, PropertyGenerator is ok, but ConstructorGenerator still has the issue. For example: NativeArray: ? ?static {? ? ? ArrayList list = new ArrayList(7);? ? ? list.add(AccessorProperty.create("isArray", 2, "G$isArray", "S$isArray"));? ? ? $nasgenmap$ = PropertyMap.newMap(list);? ?} because ScriptClassInfo.getConstructorMemberCount() returns also Kind.CONSTRUCTOR and .SPECIALIZED_FUNCTION, which are not 'added'. Thanks a lot,Ahmed From: Ahmed Ashour To: A. Sundararajan ; "nashorn-dev at openjdk.java.net" Sent: Wednesday, June 17, 2015 9:41 PM Subject: Re: RFR 8117883: nasgen prototype, instance member count calculation is wrong Hi Sundar, Works great, thanks for the quick response. I don't fully understand the removal of?ScriptObject.isGenericDescriptor I guess users are not allowed to be created in bugs.openjdk.java.net. Thanks again,Ahmed From: A. Sundararajan To: "nashorn-dev at openjdk.java.net" Sent: Wednesday, June 17, 2015 7:20 PM Subject: RFR 8117883: nasgen prototype, instance member count calculation is wrong Please review http://cr.openjdk.java.net/~sundar/8117883/ for https://bugs.openjdk.java.net/browse/JDK-8117883 Thanks, -Sundar From sundararajan.athijegannathan at oracle.com Thu Jun 18 12:57:25 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 18 Jun 2015 18:27:25 +0530 Subject: RFR 8117883: nasgen prototype, instance member count calculation is wrong In-Reply-To: <1081901499.1163288.1434608861771.JavaMail.yahoo@mail.yahoo.com> References: <5581AC60.8070401@oracle.com> <920045894.810339.1434570101542.JavaMail.yahoo@mail.yahoo.com> <1081901499.1163288.1434608861771.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5582C035.100@oracle.com> Hi, Please review updated review http://cr.openjdk.java.net/~sundar/8117883/webrev.01/ PS. Fixed for what Ahmed found in his previous email as well as cleanup other things (like not adding CONSTRUCTOR, SPECIALIZED_FUNCTION (constructor) as members for Constructor class) etc. Thanks, -Sundar On Thursday 18 June 2015 11:57 AM, Ahmed Ashour wrote: > Hi Sundar, > PropertyGenerator is ok, but ConstructorGenerator still has the issue. > For example: > NativeArray: > static { ArrayList list = new ArrayList(7); list.add(AccessorProperty.create("isArray", 2, "G$isArray", "S$isArray")); $nasgenmap$ = PropertyMap.newMap(list); } > because ScriptClassInfo.getConstructorMemberCount() returns also Kind.CONSTRUCTOR and .SPECIALIZED_FUNCTION, which are not 'added'. > Thanks a lot,Ahmed From: Ahmed Ashour > To: A. Sundararajan ; "nashorn-dev at openjdk.java.net" > Sent: Wednesday, June 17, 2015 9:41 PM > Subject: Re: RFR 8117883: nasgen prototype, instance member count calculation is wrong > > Hi Sundar, > Works great, thanks for the quick response. > I don't fully understand the removal of ScriptObject.isGenericDescriptor > I guess users are not allowed to be created in bugs.openjdk.java.net. > Thanks again,Ahmed > > From: A. Sundararajan > To: "nashorn-dev at openjdk.java.net" > Sent: Wednesday, June 17, 2015 7:20 PM > Subject: RFR 8117883: nasgen prototype, instance member count calculation is wrong > > Please review http://cr.openjdk.java.net/~sundar/8117883/ for > https://bugs.openjdk.java.net/browse/JDK-8117883 > > Thanks, > -Sundar > > > > > From hannes.wallnoefer at oracle.com Thu Jun 18 13:18:30 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 18 Jun 2015 15:18:30 +0200 Subject: RFR 8117883: nasgen prototype, instance member count calculation is wrong In-Reply-To: <5582C035.100@oracle.com> References: <5581AC60.8070401@oracle.com> <920045894.810339.1434570101542.JavaMail.yahoo@mail.yahoo.com> <1081901499.1163288.1434608861771.JavaMail.yahoo@mail.yahoo.com> <5582C035.100@oracle.com> Message-ID: <5582C526.7080301@oracle.com> Looks good. Am 2015-06-18 um 14:57 schrieb A. Sundararajan: > Hi, > > Please review updated review > http://cr.openjdk.java.net/~sundar/8117883/webrev.01/ > > PS. Fixed for what Ahmed found in his previous email as well as > cleanup other things (like not adding CONSTRUCTOR, > SPECIALIZED_FUNCTION (constructor) as members for Constructor class) etc. > > Thanks, > -Sundar > > On Thursday 18 June 2015 11:57 AM, Ahmed Ashour wrote: >> Hi Sundar, >> PropertyGenerator is ok, but ConstructorGenerator still has the issue. >> For example: >> NativeArray: >> static { ArrayList list = new ArrayList(7); >> list.add(AccessorProperty.create("isArray", 2, "G$isArray", >> "S$isArray")); $nasgenmap$ = PropertyMap.newMap(list); } >> because ScriptClassInfo.getConstructorMemberCount() returns also >> Kind.CONSTRUCTOR and .SPECIALIZED_FUNCTION, which are not 'added'. >> Thanks a lot,Ahmed From: Ahmed Ashour >> To: A. Sundararajan ; >> "nashorn-dev at openjdk.java.net" >> Sent: Wednesday, June 17, 2015 9:41 PM >> Subject: Re: RFR 8117883: nasgen prototype, instance member count >> calculation is wrong >> Hi Sundar, >> Works great, thanks for the quick response. >> I don't fully understand the removal of ScriptObject.isGenericDescriptor >> I guess users are not allowed to be created in bugs.openjdk.java.net. >> Thanks again,Ahmed >> >> From: A. Sundararajan >> To: "nashorn-dev at openjdk.java.net" >> Sent: Wednesday, June 17, 2015 7:20 PM >> Subject: RFR 8117883: nasgen prototype, instance member count >> calculation is wrong >> Please review http://cr.openjdk.java.net/~sundar/8117883/ for >> https://bugs.openjdk.java.net/browse/JDK-8117883 >> >> Thanks, >> -Sundar >> >> >> > From attila.szegedi at oracle.com Thu Jun 18 13:28:04 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 18 Jun 2015 15:28:04 +0200 Subject: RFR 8117883: nasgen prototype, instance member count calculation is wrong In-Reply-To: <5582C035.100@oracle.com> References: <5581AC60.8070401@oracle.com> <920045894.810339.1434570101542.JavaMail.yahoo@mail.yahoo.com> <1081901499.1163288.1434608861771.JavaMail.yahoo@mail.yahoo.com> <5582C035.100@oracle.com> Message-ID: Looks good, +1 > On Jun 18, 2015, at 2:57 PM, A. Sundararajan wrote: > > Hi, > > Please review updated review http://cr.openjdk.java.net/~sundar/8117883/webrev.01/ > > PS. Fixed for what Ahmed found in his previous email as well as cleanup other things (like not adding CONSTRUCTOR, SPECIALIZED_FUNCTION (constructor) as members for Constructor class) etc. > > Thanks, > -Sundar > > On Thursday 18 June 2015 11:57 AM, Ahmed Ashour wrote: >> Hi Sundar, >> PropertyGenerator is ok, but ConstructorGenerator still has the issue. >> For example: >> NativeArray: >> static { ArrayList list = new ArrayList(7); list.add(AccessorProperty.create("isArray", 2, "G$isArray", "S$isArray")); $nasgenmap$ = PropertyMap.newMap(list); } >> because ScriptClassInfo.getConstructorMemberCount() returns also Kind.CONSTRUCTOR and .SPECIALIZED_FUNCTION, which are not 'added'. >> Thanks a lot,Ahmed From: Ahmed Ashour >> To: A. Sundararajan ; "nashorn-dev at openjdk.java.net" >> Sent: Wednesday, June 17, 2015 9:41 PM >> Subject: Re: RFR 8117883: nasgen prototype, instance member count calculation is wrong >> Hi Sundar, >> Works great, thanks for the quick response. >> I don't fully understand the removal of ScriptObject.isGenericDescriptor >> I guess users are not allowed to be created in bugs.openjdk.java.net. >> Thanks again,Ahmed >> >> From: A. Sundararajan >> To: "nashorn-dev at openjdk.java.net" >> Sent: Wednesday, June 17, 2015 7:20 PM >> Subject: RFR 8117883: nasgen prototype, instance member count calculation is wrong >> Please review http://cr.openjdk.java.net/~sundar/8117883/ for >> https://bugs.openjdk.java.net/browse/JDK-8117883 >> >> Thanks, >> -Sundar >> >> >> >> > From jan.lahoda at oracle.com Thu Jun 18 14:25:15 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 18 Jun 2015 16:25:15 +0200 Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs Message-ID: <5582D4CB.9090109@oracle.com> Hello, I am proposing to add JLine 2.12.1 into the jdk repository for use by the Java and Nashorn REPLs. Full patch is available here: http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/full/ To aid the review, I've split this patch into to smaller patches: -a patch that only adds unmodified jline sources at appropriate places in the jdk repository: http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/clean-jline/ -a patch that shows the additional changes I've done: http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/additional/ This split is intended solely to simplify reviewing, my plan is to integrate this as a single patch. The main additional changes are: -plugging the new module, jdk.jline, into the JDK build. Currently, the JLine packages are exported only to jdk.scripting.nashorn (the plan is to also export them to the future jdk.jshell module). (The patch is not adding the dependency from jdk.scripting.nashorn to jdk.jline, though - I expect that to be added when needed.) -the sources are re-packaged from package "jline" to "jdk.internal.jline" -removing trailing whitespace, adding newlines at the end of the files, encoding characters that are not ASCII -avoiding the dependency on another library, jansi, by reimplementing two elements that were used from the other library. These are mainly the changes in WindowsTerminal and ConsoleReader.java. This also includes the WindowsTerminal.cpp native library. The native part is heavily inspired by: http://cr.openjdk.java.net/~sherman/rl/src/java.base/windows/native/libjava/Console_md.c.html As I am not experienced in native programming, comments to the native part would be particularly useful. -changes to resolve javac warnings in JLine. -tests for some of the added functionality. Any comments are welcome! Thanks, Jan From sundararajan.athijegannathan at oracle.com Thu Jun 18 14:40:54 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 18 Jun 2015 20:10:54 +0530 Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs In-Reply-To: <5582D4CB.9090109@oracle.com> References: <5582D4CB.9090109@oracle.com> Message-ID: <5582D876.4050406@oracle.com> * jdk/make/lib/Lib-jdk.jline.gmk has copyright year 2011, 2015 despite being a new file. Any specific reason? * jdk.jline depends on java.desktop. Is that needed by the code by jline code? I am asking because Nashorn requires only "compact 1" profile so far and so can be used on compact1 embedded platforms. If desktop dependency is needed, I guess nashorn has to use it reflectively... +1 from nashorn point of view. Thanks, -Sundar On Thursday 18 June 2015 07:55 PM, Jan Lahoda wrote: > Hello, > > I am proposing to add JLine 2.12.1 into the jdk repository for use by > the Java and Nashorn REPLs. Full patch is available here: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/full/ > > To aid the review, I've split this patch into to smaller patches: > -a patch that only adds unmodified jline sources at appropriate places > in the jdk repository: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/clean-jline/ > > -a patch that shows the additional changes I've done: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/additional/ > > This split is intended solely to simplify reviewing, my plan is to > integrate this as a single patch. > > The main additional changes are: > -plugging the new module, jdk.jline, into the JDK build. Currently, > the JLine packages are exported only to jdk.scripting.nashorn (the > plan is to also export them to the future jdk.jshell module). (The > patch is not adding the dependency from jdk.scripting.nashorn to > jdk.jline, though - I expect that to be added when needed.) > -the sources are re-packaged from package "jline" to "jdk.internal.jline" > -removing trailing whitespace, adding newlines at the end of the > files, encoding characters that are not ASCII > -avoiding the dependency on another library, jansi, by reimplementing > two elements that were used from the other library. These are mainly > the changes in WindowsTerminal and ConsoleReader.java. This also > includes the WindowsTerminal.cpp native library. The native part is > heavily inspired by: > http://cr.openjdk.java.net/~sherman/rl/src/java.base/windows/native/libjava/Console_md.c.html > > As I am not experienced in native programming, comments to the native > part would be particularly useful. > -changes to resolve javac warnings in JLine. > -tests for some of the added functionality. > > Any comments are welcome! > > Thanks, > Jan From sundararajan.athijegannathan at oracle.com Thu Jun 18 15:35:36 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 18 Jun 2015 21:05:36 +0530 Subject: ability to inject custom properties into a JS object In-Reply-To: References: <557ECAB5.8010509@oracle.com> Message-ID: <5582E548.1080209@oracle.com> Hi, I think you've to use one of these: POJO/bean-style property support, JSAdapter or JSObject. BTW, JSObject does not have to be per object. You could accept any Java type value in your AbstractJSObject subclass and delegate the calls/property accesses to it. For example, you could use reflection to look for specific name pattern in that given Java object and forward property/method access accordingly. Or you could have your own annotations and forward JS property/method access based on annotations (from your JSObject implementation). Yes, this means that you've to write a bit of glue layer code. Other thing to consider is Object.bindProperties function (another nashorn extension). This lets you to "bind" properties of one object to another object. You could write customer wrapper function that binds your Java object's properties and then add/remove properties. https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-Object.bindProperties Thanks, -Sundar On Tuesday 16 June 2015 01:31 PM, Radu Cotescu wrote: > Hi Sundar, > > Thank you for your quick reply! I did read about JSAdapter and JSObject > before my initial email but I don't think they actually do what I want. > > In my use-case I need to be able to interfere with object translation (from > Java to JavaScript) for all instances of a certain Java class, not just for > specific objects. Is there any way I could achieve this (something similar > to Rhino's host objects [2])? > > Thanks, > Radu > > [2] - > https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino/Embedding_tutorial#JavaScript_host_objects > > On Mon, 15 Jun 2015 at 15:23 A. Sundararajan < > sundararajan.athijegannathan at oracle.com> wrote: > >> Please note that nashorn has support to handle Java objects with 'bean >> style' property support. And you could implement Java interfaces and >> extend Java abstract classes in script. java.util.Map objects are >> treated specially to provide key-value access as properties. >> java.util.ArrayList objects are treated like arrays (indexed element >> access, length property for size). These could be used provide >> script-friendly access to your existing Java classes. >> >> But, if you want to write script "proxies" to trap property access etc., >> then there are two ways: >> >> 1) JSAdapter - you'd write JSAdapter wrapper in script. >> >> Example: >> >> >> https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-JSAdapterconstructor >> >> 2) Implementing jdk.nashorn.api.scripting.JSObject. >> >> >> https://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/JSObject.html >> >> AbstractJSObject ( >> >> https://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/AbstractJSObject.html >> ) provides empty/null implementation for most methods and so you can >> extend it as well. >> >> In addition, any @FunctionalInterface object >> (java.util.functions.Function etc) can be called as a script function. >> So, your script functions could just be Java functional interface objects. >> >> Example: >> >> >> https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-Plugging-inyourownJSObject >> >> Hope this helps, >> -Sundar >> >> On Monday 15 June 2015 05:42 PM, Radu Cotescu wrote: >>> Hello, >>> >>> I've recently started looking into replacing Rhino with Nashorn as the >>> JavaScript scripting engine for Apache Sling (see SLING-4801 [0]). >>> >>> Once nice Rhino feature that I don't seem to be able to easily map to >>> something from Nashorn is the ability to provide my own object wrappers, >>> such that the resulting JS object contains some custom properties. I did >>> notice this thread [1] but I wasn't able to reach to a conclusion >> regarding >>> this feature. >>> >>> Is there a way to easily implement this custom object translation layer >>> without having to implement a JSObject? The problem with this approach is >>> that Sling script developers will have to use these custom wrapper >> classes >>> (JSObjects) instead of the APIs directly available through the Bindings, >>> making scripts written for the Rhino implementation incompatible. >>> >>> Thanks, >>> Radu >>> >>> [0] - https://issues.apache.org/jira/browse/SLING-4801 >>> [1] - >>> >> https://www.mail-archive.com/nashorn-dev%40openjdk.java.net/msg01485.html >> >> From jan.lahoda at oracle.com Thu Jun 18 15:50:37 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 18 Jun 2015 17:50:37 +0200 Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs In-Reply-To: <5582D876.4050406@oracle.com> References: <5582D4CB.9090109@oracle.com> <5582D876.4050406@oracle.com> Message-ID: <5582E8CD.2040104@oracle.com> On 18.6.2015 16:40, A. Sundararajan wrote: > * jdk/make/lib/Lib-jdk.jline.gmk > > has copyright year 2011, 2015 despite being a new file. Any > specific reason? I copied one of the existing files in the directory to just adjusted it for jdk.jline. So I kept the copyright years there - what is the right thing to do here? > > * jdk.jline depends on java.desktop. Is that needed by the code by jline > code? I am asking because Nashorn requires only "compact 1" profile so > far and so can be used on compact1 embedded platforms. If desktop > dependency is needed, I guess nashorn has to use it reflectively... JLine uses java.awt.event.ActionListener (which can be registered as callbacks - this could be somewhat tricky), java.awt.datatransfer (to implement paste), and java.awt.Toolkit (to get the Clipboard). I can take a look what could be done about that if needed. Thanks for the comments! Jan > > +1 from nashorn point of view. > > Thanks, > -Sundar > > > On Thursday 18 June 2015 07:55 PM, Jan Lahoda wrote: >> Hello, >> >> I am proposing to add JLine 2.12.1 into the jdk repository for use by >> the Java and Nashorn REPLs. Full patch is available here: >> http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/full/ >> >> To aid the review, I've split this patch into to smaller patches: >> -a patch that only adds unmodified jline sources at appropriate places >> in the jdk repository: >> http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/clean-jline/ >> >> -a patch that shows the additional changes I've done: >> http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/additional/ >> >> This split is intended solely to simplify reviewing, my plan is to >> integrate this as a single patch. >> >> The main additional changes are: >> -plugging the new module, jdk.jline, into the JDK build. Currently, >> the JLine packages are exported only to jdk.scripting.nashorn (the >> plan is to also export them to the future jdk.jshell module). (The >> patch is not adding the dependency from jdk.scripting.nashorn to >> jdk.jline, though - I expect that to be added when needed.) >> -the sources are re-packaged from package "jline" to "jdk.internal.jline" >> -removing trailing whitespace, adding newlines at the end of the >> files, encoding characters that are not ASCII >> -avoiding the dependency on another library, jansi, by reimplementing >> two elements that were used from the other library. These are mainly >> the changes in WindowsTerminal and ConsoleReader.java. This also >> includes the WindowsTerminal.cpp native library. The native part is >> heavily inspired by: >> http://cr.openjdk.java.net/~sherman/rl/src/java.base/windows/native/libjava/Console_md.c.html >> >> As I am not experienced in native programming, comments to the native >> part would be particularly useful. >> -changes to resolve javac warnings in JLine. >> -tests for some of the added functionality. >> >> Any comments are welcome! >> >> Thanks, >> Jan > From sundararajan.athijegannathan at oracle.com Thu Jun 18 15:59:24 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 18 Jun 2015 21:29:24 +0530 Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs In-Reply-To: <5582E8CD.2040104@oracle.com> References: <5582D4CB.9090109@oracle.com> <5582D876.4050406@oracle.com> <5582E8CD.2040104@oracle.com> Message-ID: <5582EADC.4080401@oracle.com> My understanding is that the new file won't have old copyright year (2011 in this case). -Sundar On Thursday 18 June 2015 09:20 PM, Jan Lahoda wrote: > On 18.6.2015 16:40, A. Sundararajan wrote: >> * jdk/make/lib/Lib-jdk.jline.gmk >> >> has copyright year 2011, 2015 despite being a new file. Any >> specific reason? > > I copied one of the existing files in the directory to just adjusted > it for jdk.jline. So I kept the copyright years there - what is the > right thing to do here? > >> >> * jdk.jline depends on java.desktop. Is that needed by the code by jline >> code? I am asking because Nashorn requires only "compact 1" profile so >> far and so can be used on compact1 embedded platforms. If desktop >> dependency is needed, I guess nashorn has to use it reflectively... > > JLine uses java.awt.event.ActionListener (which can be registered as > callbacks - this could be somewhat tricky), java.awt.datatransfer (to > implement paste), and java.awt.Toolkit (to get the Clipboard). I can > take a look what could be done about that if needed. > > Thanks for the comments! > > Jan > >> >> +1 from nashorn point of view. >> >> Thanks, >> -Sundar >> >> >> On Thursday 18 June 2015 07:55 PM, Jan Lahoda wrote: >>> Hello, >>> >>> I am proposing to add JLine 2.12.1 into the jdk repository for use by >>> the Java and Nashorn REPLs. Full patch is available here: >>> http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/full/ >>> >>> To aid the review, I've split this patch into to smaller patches: >>> -a patch that only adds unmodified jline sources at appropriate places >>> in the jdk repository: >>> http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/clean-jline/ >>> >>> -a patch that shows the additional changes I've done: >>> http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/additional/ >>> >>> This split is intended solely to simplify reviewing, my plan is to >>> integrate this as a single patch. >>> >>> The main additional changes are: >>> -plugging the new module, jdk.jline, into the JDK build. Currently, >>> the JLine packages are exported only to jdk.scripting.nashorn (the >>> plan is to also export them to the future jdk.jshell module). (The >>> patch is not adding the dependency from jdk.scripting.nashorn to >>> jdk.jline, though - I expect that to be added when needed.) >>> -the sources are re-packaged from package "jline" to >>> "jdk.internal.jline" >>> -removing trailing whitespace, adding newlines at the end of the >>> files, encoding characters that are not ASCII >>> -avoiding the dependency on another library, jansi, by reimplementing >>> two elements that were used from the other library. These are mainly >>> the changes in WindowsTerminal and ConsoleReader.java. This also >>> includes the WindowsTerminal.cpp native library. The native part is >>> heavily inspired by: >>> http://cr.openjdk.java.net/~sherman/rl/src/java.base/windows/native/libjava/Console_md.c.html >>> >>> >>> As I am not experienced in native programming, comments to the native >>> part would be particularly useful. >>> -changes to resolve javac warnings in JLine. >>> -tests for some of the added functionality. >>> >>> Any comments are welcome! >>> >>> Thanks, >>> Jan >> From benjamin.john.evans at gmail.com Thu Jun 18 20:01:35 2015 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Thu, 18 Jun 2015 21:01:35 +0100 Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs In-Reply-To: <5582D4CB.9090109@oracle.com> References: <5582D4CB.9090109@oracle.com> Message-ID: Hi, Has this been tested with a JDK 9 compiler? The last time I checked JLine wouldn't build with an OpenJDK 9 javac. Thanks, Ben On 18 Jun 2015 3:26 pm, "Jan Lahoda" wrote: > Hello, > > I am proposing to add JLine 2.12.1 into the jdk repository for use by the > Java and Nashorn REPLs. Full patch is available here: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/full/ > > To aid the review, I've split this patch into to smaller patches: > -a patch that only adds unmodified jline sources at appropriate places in > the jdk repository: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/clean-jline/ > > -a patch that shows the additional changes I've done: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/additional/ > > This split is intended solely to simplify reviewing, my plan is to > integrate this as a single patch. > > The main additional changes are: > -plugging the new module, jdk.jline, into the JDK build. Currently, the > JLine packages are exported only to jdk.scripting.nashorn (the plan is to > also export them to the future jdk.jshell module). (The patch is not adding > the dependency from jdk.scripting.nashorn to jdk.jline, though - I expect > that to be added when needed.) > -the sources are re-packaged from package "jline" to "jdk.internal.jline" > -removing trailing whitespace, adding newlines at the end of the files, > encoding characters that are not ASCII > -avoiding the dependency on another library, jansi, by reimplementing two > elements that were used from the other library. These are mainly the > changes in WindowsTerminal and ConsoleReader.java. This also includes the > WindowsTerminal.cpp native library. The native part is heavily inspired by: > > http://cr.openjdk.java.net/~sherman/rl/src/java.base/windows/native/libjava/Console_md.c.html > As I am not experienced in native programming, comments to the native part > would be particularly useful. > -changes to resolve javac warnings in JLine. > -tests for some of the added functionality. > > Any comments are welcome! > > Thanks, > Jan > From asashour at yahoo.com Fri Jun 19 06:37:41 2015 From: asashour at yahoo.com (Ahmed Ashour) Date: Fri, 19 Jun 2015 06:37:41 +0000 (UTC) Subject: Nasgen: typos patch Message-ID: <1890569119.2031537.1434695861925.JavaMail.yahoo@mail.yahoo.com> Hi all, Please find attached a proposed patch to fix typos in Nasgen. Thanks,Ahmed From sundararajan.athijegannathan at oracle.com Fri Jun 19 06:45:56 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 19 Jun 2015 12:15:56 +0530 Subject: Nasgen: typos patch In-Reply-To: <1890569119.2031537.1434695861925.JavaMail.yahoo@mail.yahoo.com> References: <1890569119.2031537.1434695861925.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5583BAA4.1010100@oracle.com> Hi, Two things: 1) To be able to contribute fixes to openjdk projects, you've to follow process steps documented here: http://openjdk.java.net/contribute/ 2) Attachments are removed when posting to openjdk aliases. Once you complete the process steps above, let us know. -Sundar On Friday 19 June 2015 12:07 PM, Ahmed Ashour wrote: > Hi all, > Please find attached a proposed patch to fix typos in Nasgen. > Thanks,Ahmed From iris.clark at oracle.com Thu Jun 18 17:05:19 2015 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 18 Jun 2015 10:05:19 -0700 (PDT) Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs In-Reply-To: <5582EADC.4080401@oracle.com> References: <5582D4CB.9090109@oracle.com> <5582D876.4050406@oracle.com> <5582E8CD.2040104@oracle.com> <5582EADC.4080401@oracle.com> Message-ID: <3d62ede9-50c2-4dd5-adae-1d98b752a281@default> > My understanding is that the new file won't have old copyright year > (2011 in this case). Agreed. Thanks, iris From asashour at yahoo.com Sun Jun 21 09:41:26 2015 From: asashour at yahoo.com (Ahmed Ashour) Date: Sun, 21 Jun 2015 09:41:26 +0000 (UTC) Subject: RFR 8117883: nasgen prototype, instance member count calculation is wrong In-Reply-To: <5582C035.100@oracle.com> References: <5582C035.100@oracle.com> Message-ID: <155134530.3170041.1434879686685.JavaMail.yahoo@mail.yahoo.com> Hi Sundar, I am not sure if this is an issue or not, but with manual applying of the patch to the jdk8u master, the constructor is not correctly calling the super class, now it is missing the PropertyMap parameter. Since the patch was against jdk9, I wan't able to copy/paste it into my working environment. I hope this is my mistake, but I am sending just in case it affects others. Currently:? ? jdk.nashorn.internal.objects.NativeFunction$Constructor(); ? ? Code:? ? ? ?0: aload_0? ? ? ?1: ldc ? ? ? ? ? #8 ? ? ? ? ? ? ? ? ?// String Function? ? ? ?3: ldc ? ? ? ? ? #15 ? ? ? ? ? ? ? ? // MethodHandle invokestatic jdk/nashorn/internal/objects/NativeFunction.function:(ZLjava/lang/Object;[Ljava/lang/Object;)Ljdk/nashorn/internal/runtime/ScriptFunction;? ? ? ?5: aconst_null? ? ? ?6: invokespecial #18 ? ? ? ? ? ? ? ? // Method jdk/nashorn/internal/objects/ScriptFunctionImpl."":(Ljava/lang/String;Ljava/lang/invoke/MethodHandle;[Ljdk/nashorn/internal/runtime/Specialization;)V ?? ??Previously it was: ??? jdk.nashorn.internal.objects.NativeFunction$Constructor();? ? Code:? ? ? ?0: aload_0? ? ? ?1: ldc ? ? ? ? ? #24 ? ? ? ? ? ? ? ? // String Function? ? ? ?3: ldc ? ? ? ? ? #31 ? ? ? ? ? ? ? ? // MethodHandle invokestatic jdk/nashorn/internal/objects/NativeFunction.function:(ZLjava/lang/Object;[Ljava/lang/Object;)Ljdk/nashorn/internal/runtime/ScriptFunction;? ? ? ?5: getstatic ? ? #22 ? ? ? ? ? ? ? ? // Field $nasgenmap$:Ljdk/nashorn/internal/runtime/PropertyMap;? ? ? ?8: aconst_null? ? ? ?9: invokespecial #34 ? ? ? ? ? ? ? ? // Method jdk/nashorn/internal/objects/ScriptFunctionImpl."":(Ljava/lang/String;Ljava/lang/invoke/MethodHandle;Ljdk/nashorn/internal/runtime/PropertyMap;[Ljdk/nashorn/internal/runtime/Specialization;)V Thanks,Ahmed From: A. Sundararajan To: nashorn-dev at openjdk.java.net Sent: Thursday, June 18, 2015 2:57 PM Subject: Re: RFR 8117883: nasgen prototype, instance member count calculation is wrong Hi, Please review updated review http://cr.openjdk.java.net/~sundar/8117883/webrev.01/ PS. Fixed for what Ahmed found in his previous email as well as cleanup other things (like not adding CONSTRUCTOR, SPECIALIZED_FUNCTION (constructor) as members for Constructor class) etc. Thanks, -Sundar On Thursday 18 June 2015 11:57 AM, Ahmed Ashour wrote: > Hi Sundar, > PropertyGenerator is ok, but ConstructorGenerator still has the issue. > For example: > NativeArray: >? ? static {? ? ? ArrayList list = new ArrayList(7);? ? ? list.add(AccessorProperty.create("isArray", 2, "G$isArray", "S$isArray"));? ? ? $nasgenmap$ = PropertyMap.newMap(list);? } > because ScriptClassInfo.getConstructorMemberCount() returns also Kind.CONSTRUCTOR and .SPECIALIZED_FUNCTION, which are not 'added'. > Thanks a lot,Ahmed? ? ? From: Ahmed Ashour >? To: A. Sundararajan ; "nashorn-dev at openjdk.java.net" >? Sent: Wednesday, June 17, 2015 9:41 PM >? Subject: Re: RFR 8117883: nasgen prototype, instance member count calculation is wrong >? ? > Hi Sundar, > Works great, thanks for the quick response. > I don't fully understand the removal of ScriptObject.isGenericDescriptor > I guess users are not allowed to be created in bugs.openjdk.java.net. > Thanks again,Ahmed > >? ? ? From: A. Sundararajan >? To: "nashorn-dev at openjdk.java.net" >? Sent: Wednesday, June 17, 2015 7:20 PM >? Subject: RFR 8117883: nasgen prototype, instance member count calculation is wrong >? ? > Please review http://cr.openjdk.java.net/~sundar/8117883/ for > https://bugs.openjdk.java.net/browse/JDK-8117883 > > Thanks, > -Sundar > > >? ? > >? ? From erik.joelsson at oracle.com Mon Jun 22 08:25:21 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 22 Jun 2015 10:25:21 +0200 Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs In-Reply-To: <5582D4CB.9090109@oracle.com> References: <5582D4CB.9090109@oracle.com> Message-ID: <5587C671.1040508@oracle.com> Hello Jan, Build changes look mostly ok. Some notes: * "$(CFLAGS_WARNINGS_ARE_ERRORS)", which should not be used anymore. Warnings are already treated as errors globally. * There should not be a need to add "-I$(INCLUDEDIR) -I$(JDK_OUTPUTDIR)/include/$(OPENJDK_TARGET_OS)" to cflags. INCLUDEDIR is undefined AFAIK, and the other dir is already in CFLAGS_JDKLIB. I'm guessing that you copied Lib-jdk.jdi.gmk as a template. Is the -DUSE_MMAP just an artifact of that copy or do you know that it is needed? /Erik On 2015-06-18 16:25, Jan Lahoda wrote: > Hello, > > I am proposing to add JLine 2.12.1 into the jdk repository for use by > the Java and Nashorn REPLs. Full patch is available here: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/full/ > > To aid the review, I've split this patch into to smaller patches: > -a patch that only adds unmodified jline sources at appropriate places > in the jdk repository: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/clean-jline/ > > -a patch that shows the additional changes I've done: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/additional/ > > This split is intended solely to simplify reviewing, my plan is to > integrate this as a single patch. > > The main additional changes are: > -plugging the new module, jdk.jline, into the JDK build. Currently, > the JLine packages are exported only to jdk.scripting.nashorn (the > plan is to also export them to the future jdk.jshell module). (The > patch is not adding the dependency from jdk.scripting.nashorn to > jdk.jline, though - I expect that to be added when needed.) > -the sources are re-packaged from package "jline" to "jdk.internal.jline" > -removing trailing whitespace, adding newlines at the end of the > files, encoding characters that are not ASCII > -avoiding the dependency on another library, jansi, by reimplementing > two elements that were used from the other library. These are mainly > the changes in WindowsTerminal and ConsoleReader.java. This also > includes the WindowsTerminal.cpp native library. The native part is > heavily inspired by: > http://cr.openjdk.java.net/~sherman/rl/src/java.base/windows/native/libjava/Console_md.c.html > > As I am not experienced in native programming, comments to the native > part would be particularly useful. > -changes to resolve javac warnings in JLine. > -tests for some of the added functionality. > > Any comments are welcome! > > Thanks, > Jan From sundararajan.athijegannathan at oracle.com Mon Jun 22 09:34:58 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 22 Jun 2015 15:04:58 +0530 Subject: RFR 8117883: nasgen prototype, instance member count calculation is wrong In-Reply-To: <155134530.3170041.1434879686685.JavaMail.yahoo@mail.yahoo.com> References: <5582C035.100@oracle.com> <155134530.3170041.1434879686685.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5587D6C2.9090706@oracle.com> Hi Ahmed, This is not a problem. When there are no properties, property count is zero now (previously miscalculated!). Where there are zero properties, no need to create a new PropertyMap - PropertyMap in ScriptFunctionImpl can be reused for such cases and hence you see the variant without PropertyMap being invoked (as it should be). -Sundar On Sunday 21 June 2015 03:11 PM, Ahmed Ashour wrote: > Hi Sundar, > I am not sure if this is an issue or not, but with manual applying of the patch to the jdk8u master, the constructor is not correctly calling the super class, now it is missing the PropertyMap parameter. > Since the patch was against jdk9, I wan't able to copy/paste it into my working environment. > I hope this is my mistake, but I am sending just in case it affects others. > Currently: > > jdk.nashorn.internal.objects.NativeFunction$Constructor(); > Code: 0: aload_0 1: ldc #8 // String Function 3: ldc #15 // MethodHandle invokestatic jdk/nashorn/internal/objects/NativeFunction.function:(ZLjava/lang/Object;[Ljava/lang/Object;)Ljdk/nashorn/internal/runtime/ScriptFunction; 5: aconst_null 6: invokespecial #18 // Method jdk/nashorn/internal/objects/ScriptFunctionImpl."":(Ljava/lang/String;Ljava/lang/invoke/MethodHandle;[Ljdk/nashorn/internal/runtime/Specialization;)V Previously it was: jdk.nashorn.internal.objects.NativeFunction$Constructor(); Code: 0: aload_0 1: ldc #24 // String Function 3: ldc #31 // MethodHandle invokestatic jdk/nashorn/internal/objects/NativeFunction.function:(ZLjava/lang/Object;[Ljava/lang/Object;)Ljdk/nashorn/internal/runtime/ScriptFunction; 5: getstatic #22 // Field $nasgenmap$:Ljdk/nashorn/internal/runtime/PropertyMap; 8: aconst_null 9: invokespecial #34 // Method jdk/nashorn/internal/objects/ScriptFunctionImpl."":(Ljava/lang/String;Ljava/lang/invoke/MethodHandle;Ljdk/nashorn/internal/runtime/PropertyMap;[Ljdk/nashorn/internal/runtime/Specialization;)V > Thanks,Ahmed > From: A. Sundararajan > To: nashorn-dev at openjdk.java.net > Sent: Thursday, June 18, 2015 2:57 PM > Subject: Re: RFR 8117883: nasgen prototype, instance member count calculation is wrong > > Hi, > > Please review updated review > http://cr.openjdk.java.net/~sundar/8117883/webrev.01/ > > PS. Fixed for what Ahmed found in his previous email as well as cleanup > other things (like not adding CONSTRUCTOR, SPECIALIZED_FUNCTION > (constructor) as members for Constructor class) etc. > > Thanks, > -Sundar > > > > On Thursday 18 June 2015 11:57 AM, Ahmed Ashour wrote: >> Hi Sundar, >> PropertyGenerator is ok, but ConstructorGenerator still has the issue. >> For example: >> NativeArray: >> static { ArrayList list = new ArrayList(7); list.add(AccessorProperty.create("isArray", 2, "G$isArray", "S$isArray")); $nasgenmap$ = PropertyMap.newMap(list); } >> because ScriptClassInfo.getConstructorMemberCount() returns also Kind.CONSTRUCTOR and .SPECIALIZED_FUNCTION, which are not 'added'. >> Thanks a lot,Ahmed From: Ahmed Ashour >> To: A. Sundararajan ; "nashorn-dev at openjdk.java.net" >> Sent: Wednesday, June 17, 2015 9:41 PM >> Subject: Re: RFR 8117883: nasgen prototype, instance member count calculation is wrong >> >> Hi Sundar, >> Works great, thanks for the quick response. >> I don't fully understand the removal of ScriptObject.isGenericDescriptor >> I guess users are not allowed to be created in bugs.openjdk.java.net. >> Thanks again,Ahmed >> >> From: A. Sundararajan >> To: "nashorn-dev at openjdk.java.net" >> Sent: Wednesday, June 17, 2015 7:20 PM >> Subject: RFR 8117883: nasgen prototype, instance member count calculation is wrong >> >> Please review http://cr.openjdk.java.net/~sundar/8117883/ for >> https://bugs.openjdk.java.net/browse/JDK-8117883 >> >> Thanks, >> -Sundar >> >> >> >> >> > > > From jan.lahoda at oracle.com Mon Jun 22 11:23:39 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 22 Jun 2015 13:23:39 +0200 Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs In-Reply-To: <5587C671.1040508@oracle.com> References: <5582D4CB.9090109@oracle.com> <5587C671.1040508@oracle.com> Message-ID: <5587F03B.8000505@oracle.com> Hi Erik, Thanks for the comments. Yes, I copied an existing file, and -DUSE_MMAP seems unnecessary. I'll implement your suggestions. Thanks, Jan On 22.6.2015 10:25, Erik Joelsson wrote: > Hello Jan, > > Build changes look mostly ok. Some notes: > > * "$(CFLAGS_WARNINGS_ARE_ERRORS)", which should not be used anymore. > Warnings are already treated as errors globally. > > * There should not be a need to add "-I$(INCLUDEDIR) > -I$(JDK_OUTPUTDIR)/include/$(OPENJDK_TARGET_OS)" to cflags. INCLUDEDIR > is undefined AFAIK, and the other dir is already in CFLAGS_JDKLIB. > > I'm guessing that you copied Lib-jdk.jdi.gmk as a template. Is the > -DUSE_MMAP just an artifact of that copy or do you know that it is needed? > > /Erik > > On 2015-06-18 16:25, Jan Lahoda wrote: >> Hello, >> >> I am proposing to add JLine 2.12.1 into the jdk repository for use by >> the Java and Nashorn REPLs. Full patch is available here: >> http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/full/ >> >> To aid the review, I've split this patch into to smaller patches: >> -a patch that only adds unmodified jline sources at appropriate places >> in the jdk repository: >> http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/clean-jline/ >> >> -a patch that shows the additional changes I've done: >> http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/additional/ >> >> This split is intended solely to simplify reviewing, my plan is to >> integrate this as a single patch. >> >> The main additional changes are: >> -plugging the new module, jdk.jline, into the JDK build. Currently, >> the JLine packages are exported only to jdk.scripting.nashorn (the >> plan is to also export them to the future jdk.jshell module). (The >> patch is not adding the dependency from jdk.scripting.nashorn to >> jdk.jline, though - I expect that to be added when needed.) >> -the sources are re-packaged from package "jline" to "jdk.internal.jline" >> -removing trailing whitespace, adding newlines at the end of the >> files, encoding characters that are not ASCII >> -avoiding the dependency on another library, jansi, by reimplementing >> two elements that were used from the other library. These are mainly >> the changes in WindowsTerminal and ConsoleReader.java. This also >> includes the WindowsTerminal.cpp native library. The native part is >> heavily inspired by: >> http://cr.openjdk.java.net/~sherman/rl/src/java.base/windows/native/libjava/Console_md.c.html >> >> As I am not experienced in native programming, comments to the native >> part would be particularly useful. >> -changes to resolve javac warnings in JLine. >> -tests for some of the added functionality. >> >> Any comments are welcome! >> >> Thanks, >> Jan > From attila.szegedi at oracle.com Mon Jun 22 13:49:07 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 22 Jun 2015 15:49:07 +0200 Subject: Review request for JDK-8129410: Java adapters with class-level overrides should preserve variable arity constructors Message-ID: Please review JDK-8129410 "Java adapters with class-level overrides should preserve variable arity constructors" at for Thanks, Attila. From sundararajan.athijegannathan at oracle.com Mon Jun 22 13:50:17 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 22 Jun 2015 19:20:17 +0530 Subject: Review request for JDK-8129410: Java adapters with class-level overrides should preserve variable arity constructors In-Reply-To: References: Message-ID: <55881299.4040207@oracle.com> +1 On Monday 22 June 2015 07:19 PM, Attila Szegedi wrote: > Please review JDK-8129410 "Java adapters with class-level overrides should preserve variable arity constructors" at for > > Thanks, > Attila. From marcus.lagergren at oracle.com Tue Jun 23 09:04:44 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 23 Jun 2015 11:04:44 +0200 Subject: Review request for JDK-8129410: Java adapters with class-level overrides should preserve variable arity constructors In-Reply-To: References: Message-ID: +1 > On 22 Jun 2015, at 15:49, Attila Szegedi wrote: > > Please review JDK-8129410 "Java adapters with class-level overrides should preserve variable arity constructors" at for > > Thanks, > Attila. From volker.simonis at gmail.com Wed Jun 24 14:41:44 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 24 Jun 2015 16:41:44 +0200 Subject: Nashorn Octane JMH code publicly available? In-Reply-To: References: <44d8657fa857d44be1301f0b0c8cd225.squirrel@excalibur.xssl.net> <935E1B44-954F-4001-BFC2-72CDCE22991C@oracle.com> Message-ID: I just had the same question and couldn't find any answer with Google except this mail thread. So I'll just as again: is the Octane benchmark as part of JMH as described in the Nashorn Wiki [1] publicly available somewhere? Thanks, Volker [1] https://wiki.openjdk.java.net/display/Nashorn/Monitoring+Nashorn+Performance On Thu, Apr 30, 2015 at 9:18 AM, Marcus Lagergren wrote: > >> On 29 Apr 2015, at 09:08, Marcus Lagergren wrote: >> >> The benchmark code itself is public, but I don?t know if the benchmarks as part of JMH are. CC Aleksey >> /M >> >>> On 28 Apr 2015, at 19:24, Chris Newland wrote: >>> >>> Hi, >>> >>> https://wiki.openjdk.java.net/display/Nashorn/Monitoring+Nashorn+Performance >>> indicates the JMH microbenchmarks for octane are internal to Oracle (VPN >>> needed). >>> >>> I can't see them elsewhere in the OpenJDK repos, are they public? >>> >>> Asking because the results I'm getting from >>> >>> nashorn/test/script/external/octane$ jjs run.js >>> >>> are wildly variable (as per above wiki page). >>> >>> Thanks, >>> >>> Chris >>> >> > From marcus.lagergren at oracle.com Wed Jun 24 15:00:34 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 24 Jun 2015 17:00:34 +0200 Subject: Nashorn Octane JMH code publicly available? In-Reply-To: References: <44d8657fa857d44be1301f0b0c8cd225.squirrel@excalibur.xssl.net> <935E1B44-954F-4001-BFC2-72CDCE22991C@oracle.com> Message-ID: Not sure if it?s available publically as part of JMH, but you can get the octane benchmark code itself from svn co http://octane-benchmark.googlecode.com/svn/trunk /M > On 24 Jun 2015, at 16:41, Volker Simonis wrote: > > I just had the same question and couldn't find any answer with Google > except this mail thread. > > So I'll just as again: is the Octane benchmark as part of JMH as > described in the Nashorn Wiki [1] publicly available somewhere? > > Thanks, > Volker > > [1] https://wiki.openjdk.java.net/display/Nashorn/Monitoring+Nashorn+Performance > > On Thu, Apr 30, 2015 at 9:18 AM, Marcus Lagergren > wrote: >> >>> On 29 Apr 2015, at 09:08, Marcus Lagergren wrote: >>> >>> The benchmark code itself is public, but I don?t know if the benchmarks as part of JMH are. CC Aleksey >>> /M >>> >>>> On 28 Apr 2015, at 19:24, Chris Newland wrote: >>>> >>>> Hi, >>>> >>>> https://wiki.openjdk.java.net/display/Nashorn/Monitoring+Nashorn+Performance >>>> indicates the JMH microbenchmarks for octane are internal to Oracle (VPN >>>> needed). >>>> >>>> I can't see them elsewhere in the OpenJDK repos, are they public? >>>> >>>> Asking because the results I'm getting from >>>> >>>> nashorn/test/script/external/octane$ jjs run.js >>>> >>>> are wildly variable (as per above wiki page). >>>> >>>> Thanks, >>>> >>>> Chris >>>> >>> >> From cnewland at chrisnewland.com Wed Jun 24 15:38:16 2015 From: cnewland at chrisnewland.com (Chris Newland) Date: Wed, 24 Jun 2015 16:38:16 +0100 Subject: Nashorn Octane JMH code publicly available? In-Reply-To: References: <44d8657fa857d44be1301f0b0c8cd225.squirrel@excalibur.xssl.net> <935E1B44-954F-4001-BFC2-72CDCE22991C@oracle.com> Message-ID: <441934b532df8acc01932d20fa8baf7d.squirrel@excalibur.xssl.net> Hi Volker, In the end I wrote my own JMH harness around octane but I can't get the results stable even with 3 day runs so my JMH code could be buggy. Will share later off list if you're interested. Regards, Chris @chriswhocodes On Wed, June 24, 2015 16:00, Marcus Lagergren wrote: > Not sure if it???s available publically as part of JMH, but you can get > the octane benchmark code itself from > > svn co http://octane-benchmark.googlecode.com/svn/trunk > > > > /M > > >> On 24 Jun 2015, at 16:41, Volker Simonis >> wrote: >> >> >> I just had the same question and couldn't find any answer with Google >> except this mail thread. >> >> So I'll just as again: is the Octane benchmark as part of JMH as >> described in the Nashorn Wiki [1] publicly available somewhere? >> >> Thanks, >> Volker >> >> >> [1] >> https://wiki.openjdk.java.net/display/Nashorn/Monitoring+Nashorn+Perfor >> mance >> >> On Thu, Apr 30, 2015 at 9:18 AM, Marcus Lagergren >> wrote: >> >>> >>>> On 29 Apr 2015, at 09:08, Marcus Lagergren >>>> wrote: >>>> >>>> >>>> The benchmark code itself is public, but I don???t know if the >>>> benchmarks as part of JMH are. CC Aleksey /M >>>> >>>> >>>>> On 28 Apr 2015, at 19:24, Chris Newland >>>>> wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> >>>>> https://wiki.openjdk.java.net/display/Nashorn/Monitoring+Nashorn+ >>>>> Performance >>>>> indicates the JMH microbenchmarks for octane are internal to >>>>> Oracle (VPN >>>>> needed). >>>>> >>>>> I can't see them elsewhere in the OpenJDK repos, are they public? >>>>> >>>>> >>>>> Asking because the results I'm getting from >>>>> >>>>> >>>>> nashorn/test/script/external/octane$ jjs run.js >>>>> >>>>> are wildly variable (as per above wiki page). >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> Chris >>>>> >>>>> >>>> >>> > > From volker.simonis at gmail.com Wed Jun 24 15:50:39 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 24 Jun 2015 17:50:39 +0200 Subject: Nashorn Octane JMH code publicly available? In-Reply-To: <441934b532df8acc01932d20fa8baf7d.squirrel@excalibur.xssl.net> References: <44d8657fa857d44be1301f0b0c8cd225.squirrel@excalibur.xssl.net> <935E1B44-954F-4001-BFC2-72CDCE22991C@oracle.com> <441934b532df8acc01932d20fa8baf7d.squirrel@excalibur.xssl.net> Message-ID: Hi Chris, Marcus, thanks for your responses. Some colleagues of mine who set up Octane in our environment complained about the test results being extremely unstable. And even more so if comparing two different JDK versions (like our internal build with an "official" Oracle-JDK build" which should "theoretically" behave the same). So I wanted to look at the differences and what I found was the quote from the Nashorn Wiki which says: "the octane base.js harness .. has a very primitive and deviation prone way of measuring benchmark time." That's why I thought to better use JMH harness as described on that page before starting to look at "real" problems. @Marcus: do you really see stable benchmark results when using your internal JMH Octane harness or is this a pointless undertaking anywhere? @Chris: if it isn't too much of an effort for you, I'd appreciate to have a look at your harness. Regards, Volker On Wed, Jun 24, 2015 at 5:38 PM, Chris Newland wrote: > Hi Volker, > > In the end I wrote my own JMH harness around octane but I can't get the > results stable even with 3 day runs so my JMH code could be buggy. > > Will share later off list if you're interested. > > Regards, > > Chris > @chriswhocodes > > On Wed, June 24, 2015 16:00, Marcus Lagergren wrote: >> Not sure if it?s available publically as part of JMH, but you can get >> the octane benchmark code itself from >> >> svn co http://octane-benchmark.googlecode.com/svn/trunk >> >> >> >> /M >> >> >>> On 24 Jun 2015, at 16:41, Volker Simonis >>> wrote: >>> >>> >>> I just had the same question and couldn't find any answer with Google >>> except this mail thread. >>> >>> So I'll just as again: is the Octane benchmark as part of JMH as >>> described in the Nashorn Wiki [1] publicly available somewhere? >>> >>> Thanks, >>> Volker >>> >>> >>> [1] >>> https://wiki.openjdk.java.net/display/Nashorn/Monitoring+Nashorn+Perfor >>> mance >>> >>> On Thu, Apr 30, 2015 at 9:18 AM, Marcus Lagergren >>> wrote: >>> >>>> >>>>> On 29 Apr 2015, at 09:08, Marcus Lagergren >>>>> wrote: >>>>> >>>>> >>>>> The benchmark code itself is public, but I don?t know if the >>>>> benchmarks as part of JMH are. CC Aleksey /M >>>>> >>>>> >>>>>> On 28 Apr 2015, at 19:24, Chris Newland >>>>>> wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> https://wiki.openjdk.java.net/display/Nashorn/Monitoring+Nashorn+ >>>>>> Performance >>>>>> indicates the JMH microbenchmarks for octane are internal to >>>>>> Oracle (VPN >>>>>> needed). >>>>>> >>>>>> I can't see them elsewhere in the OpenJDK repos, are they public? >>>>>> >>>>>> >>>>>> Asking because the results I'm getting from >>>>>> >>>>>> >>>>>> nashorn/test/script/external/octane$ jjs run.js >>>>>> >>>>>> are wildly variable (as per above wiki page). >>>>>> >>>>>> Thanks, >>>>>> >>>>>> >>>>>> Chris >>>>>> >>>>>> >>>>> >>>> >> >> > > From joe.darcy at oracle.com Wed Jun 24 17:19:24 2015 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 24 Jun 2015 10:19:24 -0700 Subject: JDK 9 RFR of JDK-8129597: Add tier 3 test definitions to the JDK 9 forest Message-ID: <558AE69C.7090905@oracle.com> Hello, Per the recent email to jdk9-dev, "Test policy follow-up, third testing tier," http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-June/002325.html please review the patch below to address JDK-8129597 : Add tier 3 test definitions to the JDK 9 forest http://cr.openjdk.java.net/~darcy/8129597.0/ (Tests will be added to tier 3 in subsequent changesets.) Thanks, -Joe --- old/jdk/test/TEST.groups 2015-06-23 09:47:53.929026307 -0700 +++ new/jdk/test/TEST.groups 2015-06-23 09:47:53.761110302 -0700 @@ -42,6 +42,9 @@ :jdk_other \ :jdk_svc +# Tier 3 is initially empty +tier3 = + ############################################################################### # # Other test definitions; generally smaller granularity than tiers --- old/langtools/test/TEST.groups 2015-06-23 09:47:54.296842319 -0700 +++ new/langtools/test/TEST.groups 2015-06-23 09:47:54.192894315 -0700 @@ -22,11 +22,14 @@ # Tiered testing definitions -# All langtools tests are tier 1 +# All langtools tests are tier 1. tier1 = \ tools \ com \ lib -# No langtools tests are tier 2 +# No langtools tests are tier 2. tier2 = + +# No langtools tests are tier 3 either. +tier3 = --- old/jaxp/test/TEST.groups 2015-06-23 09:47:54.616682328 -0700 +++ new/jaxp/test/TEST.groups 2015-06-23 09:47:54.528726325 -0700 @@ -29,5 +29,8 @@ tier2 = \ :jaxp_all +# No tier 3 tests. +tier3 = + jaxp_all = \ javax/xml/jaxp --- old/nashorn/test/TEST.groups 2015-06-23 09:47:54.936522337 -0700 +++ new/nashorn/test/TEST.groups 2015-06-23 09:47:54.848566335 -0700 @@ -27,3 +27,6 @@ # All nashorn tests are tier 2. tier2 = src + +# No nashorn tests are tier 3. +tier3 = From marcus.lagergren at oracle.com Thu Jun 25 08:04:35 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 25 Jun 2015 10:04:35 +0200 Subject: Nashorn Octane JMH code publicly available? In-Reply-To: References: <44d8657fa857d44be1301f0b0c8cd225.squirrel@excalibur.xssl.net> <935E1B44-954F-4001-BFC2-72CDCE22991C@oracle.com> <441934b532df8acc01932d20fa8baf7d.squirrel@excalibur.xssl.net> Message-ID: <59203574-527F-4A8F-A0C5-C29582952803@oracle.com> No results are very unstable - using JMH will bring significant stability to them, but you have to realize that in some cases HotSpot needs to do hundreds of runs before plateauing out because of LambdaForms etc. Aleksey knows more. /M > On 24 Jun 2015, at 17:50, Volker Simonis wrote: > > Hi Chris, Marcus, > > thanks for your responses. > > Some colleagues of mine who set up Octane in our environment > complained about the test results being extremely unstable. And even > more so if comparing two different JDK versions (like our internal > build with an "official" Oracle-JDK build" which should > "theoretically" behave the same). > > So I wanted to look at the differences and what I found was the quote > from the Nashorn Wiki which says: "the octane base.js harness .. has a > very primitive and deviation prone way of measuring benchmark time." > That's why I thought to better use JMH harness as described on that > page before starting to look at "real" problems. > > > @Marcus: do you really see stable benchmark results when using your > internal JMH Octane harness or is this a pointless undertaking > anywhere? > > @Chris: if it isn't too much of an effort for you, I'd appreciate to > have a look at your harness. > > Regards, > Volker > > On Wed, Jun 24, 2015 at 5:38 PM, Chris Newland > wrote: >> Hi Volker, >> >> In the end I wrote my own JMH harness around octane but I can't get the >> results stable even with 3 day runs so my JMH code could be buggy. >> >> Will share later off list if you're interested. >> >> Regards, >> >> Chris >> @chriswhocodes >> >> On Wed, June 24, 2015 16:00, Marcus Lagergren wrote: >>> Not sure if it?s available publically as part of JMH, but you can get >>> the octane benchmark code itself from >>> >>> svn co http://octane-benchmark.googlecode.com/svn/trunk >>> >>> >>> >>> /M >>> >>> >>>> On 24 Jun 2015, at 16:41, Volker Simonis >>>> wrote: >>>> >>>> >>>> I just had the same question and couldn't find any answer with Google >>>> except this mail thread. >>>> >>>> So I'll just as again: is the Octane benchmark as part of JMH as >>>> described in the Nashorn Wiki [1] publicly available somewhere? >>>> >>>> Thanks, >>>> Volker >>>> >>>> >>>> [1] >>>> https://wiki.openjdk.java.net/display/Nashorn/Monitoring+Nashorn+Perfor >>>> mance >>>> >>>> On Thu, Apr 30, 2015 at 9:18 AM, Marcus Lagergren >>>> wrote: >>>> >>>>> >>>>>> On 29 Apr 2015, at 09:08, Marcus Lagergren >>>>>> wrote: >>>>>> >>>>>> >>>>>> The benchmark code itself is public, but I don?t know if the >>>>>> benchmarks as part of JMH are. CC Aleksey /M >>>>>> >>>>>> >>>>>>> On 28 Apr 2015, at 19:24, Chris Newland >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> https://wiki.openjdk.java.net/display/Nashorn/Monitoring+Nashorn+ >>>>>>> Performance >>>>>>> indicates the JMH microbenchmarks for octane are internal to >>>>>>> Oracle (VPN >>>>>>> needed). >>>>>>> >>>>>>> I can't see them elsewhere in the OpenJDK repos, are they public? >>>>>>> >>>>>>> >>>>>>> Asking because the results I'm getting from >>>>>>> >>>>>>> >>>>>>> nashorn/test/script/external/octane$ jjs run.js >>>>>>> >>>>>>> are wildly variable (as per above wiki page). >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> >>>>>> >>>>> >>> >>> >> >> From attila.szegedi at oracle.com Thu Jun 25 08:05:42 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 25 Jun 2015 10:05:42 +0200 Subject: RFR: 8098547: (tz) Support tzdata2015e In-Reply-To: <558A8F06.5010803@oracle.com> References: <558A8F06.5010803@oracle.com> Message-ID: <4DFDE221-C843-4465-8A3F-7A658AD913C5@oracle.com> FWIW, he do have one new test failure in Nashorn now, it seems related. Can you confirm it is caused by your changes? [testng] Test test/script/basic/NASHORN-627.js failed at line 1 - [testng] expected: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CET) -954000000 1969-12-20T23:00:00.000Z' [testng] found: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CEST) -954000000 1969-12-20T23:00:00.000Z' Attila. > On Jun 24, 2015, at 1:05 PM, Aleksej Efimov wrote: > > Hello, > > Please, review the latest tzdata (2015e) [1] integration to JDK9: http://cr.openjdk.java.net/~aefimov/tzdata/2015e/9/0 > Testing shows no TZ related failures on all platforms. > > With Best Regards, > Aleksej > > [1] https://bugs.openjdk.java.net/browse/JDK-8098547 From sean.coffey at oracle.com Thu Jun 25 11:02:59 2015 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Thu, 25 Jun 2015 12:02:59 +0100 Subject: RFR: 8098547: (tz) Support tzdata2015e In-Reply-To: <4DFDE221-C843-4465-8A3F-7A658AD913C5@oracle.com> References: <558A8F06.5010803@oracle.com> <4DFDE221-C843-4465-8A3F-7A658AD913C5@oracle.com> Message-ID: <558BDFE3.2030100@oracle.com> That looks like a strange failure Attila. The timezone in use for that testcase is Europe/Vienna. 2015e tzdata changes haven't been pushed to jdk9-dev forest yet. Where the 1969 date coming from ? Is there some rollover calculation happening ? Regards, Sean. On 25/06/2015 09:05, Attila Szegedi wrote: > FWIW, he do have one new test failure in Nashorn now, it seems related. Can you confirm it is caused by your changes? > > [testng] Test test/script/basic/NASHORN-627.js failed at line 1 - > [testng] expected: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CET) -954000000 1969-12-20T23:00:00.000Z' > [testng] found: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CEST) -954000000 1969-12-20T23:00:00.000Z' > > Attila. > >> On Jun 24, 2015, at 1:05 PM, Aleksej Efimov wrote: >> >> Hello, >> >> Please, review the latest tzdata (2015e) [1] integration to JDK9: http://cr.openjdk.java.net/~aefimov/tzdata/2015e/9/0 >> Testing shows no TZ related failures on all platforms. >> >> With Best Regards, >> Aleksej >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8098547 From attila.szegedi at oracle.com Thu Jun 25 12:49:13 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 25 Jun 2015 14:49:13 +0200 Subject: RFR: 8098547: (tz) Support tzdata2015e In-Reply-To: <558BDFE3.2030100@oracle.com> References: <558A8F06.5010803@oracle.com> <4DFDE221-C843-4465-8A3F-7A658AD913C5@oracle.com> <558BDFE3.2030100@oracle.com> Message-ID: Yeah, basically instantiating a JavaScript native Date object with (70, 0, -10) and confirming it ends up being 10 days before epoch? This test failure happened tonight with jdk9, see >, so I presumed it has to be related (no changes to nashorn itself were made). It?s just suddenly the timezone is named ?CEST? instead of ?CET?. > On Jun 25, 2015, at 1:02 PM, Se?n Coffey wrote: > > That looks like a strange failure Attila. The timezone in use for that testcase is Europe/Vienna. > 2015e tzdata changes haven't been pushed to jdk9-dev forest yet. > > Where the 1969 date coming from ? Is there some rollover calculation happening ? > > Regards, > Sean. > > On 25/06/2015 09:05, Attila Szegedi wrote: >> FWIW, he do have one new test failure in Nashorn now, it seems related. Can you confirm it is caused by your changes? >> >> [testng] Test test/script/basic/NASHORN-627.js failed at line 1 - >> [testng] expected: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CET) -954000000 1969-12-20T23:00:00.000Z' >> [testng] found: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CEST) -954000000 1969-12-20T23:00:00.000Z' >> >> Attila. >> >>> On Jun 24, 2015, at 1:05 PM, Aleksej Efimov wrote: >>> >>> Hello, >>> >>> Please, review the latest tzdata (2015e) [1] integration to JDK9: http://cr.openjdk.java.net/~aefimov/tzdata/2015e/9/0 >>> Testing shows no TZ related failures on all platforms. >>> >>> With Best Regards, >>> Aleksej >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8098547 > From cnewland at chrisnewland.com Thu Jun 25 13:21:13 2015 From: cnewland at chrisnewland.com (Chris Newland) Date: Thu, 25 Jun 2015 14:21:13 +0100 Subject: Nashorn Octane JMH code publicly available? In-Reply-To: <59203574-527F-4A8F-A0C5-C29582952803@oracle.com> References: <44d8657fa857d44be1301f0b0c8cd225.squirrel@excalibur.xssl.net> <935E1B44-954F-4001-BFC2-72CDCE22991C@oracle.com> <441934b532df8acc01932d20fa8baf7d.squirrel@excalibur.xssl.net> <59203574-527F-4A8F-A0C5-C29582952803@oracle.com> Message-ID: <7e1bb37db9e426d436c984742708cb0c.squirrel@excalibur.xssl.net> Hi Volker, I thought I'd posted my findings back here but turns out I'd tweeted them: https://twitter.com/chriswhocodes/status/596723775779012608 Here is my JMH Octane wrapper: https://gist.github.com/chriswhocodes/c5bf3632fb7272e994e9 The gist doesn't incorporate incorporate Aleksey's @Setup suggestion. Given the time taken to reach 00s of runs I think it might be better to benchmark each Octane test in isolation rather than wait for the whole suite to stabilise? -Chris On Thu, June 25, 2015 09:04, Marcus Lagergren wrote: > No results are very unstable - using JMH will bring significant stability > to them, but you have to realize that in some cases HotSpot needs to do > hundreds of runs before plateauing out because of LambdaForms etc. > Aleksey knows more. > > > /M > > >> On 24 Jun 2015, at 17:50, Volker Simonis >> wrote: >> >> >> Hi Chris, Marcus, >> >> >> thanks for your responses. >> >> Some colleagues of mine who set up Octane in our environment >> complained about the test results being extremely unstable. And even more >> so if comparing two different JDK versions (like our internal build with >> an "official" Oracle-JDK build" which should "theoretically" behave the >> same). >> >> So I wanted to look at the differences and what I found was the quote >> from the Nashorn Wiki which says: "the octane base.js harness .. has a >> very primitive and deviation prone way of measuring benchmark time." >> That's why I thought to better use JMH harness as described on that >> page before starting to look at "real" problems. >> >> >> @Marcus: do you really see stable benchmark results when using your >> internal JMH Octane harness or is this a pointless undertaking anywhere? >> >> @Chris: if it isn't too much of an effort for you, I'd appreciate to >> have a look at your harness. >> >> Regards, >> Volker >> >> >> On Wed, Jun 24, 2015 at 5:38 PM, Chris Newland >> wrote: >> >>> Hi Volker, >>> >>> >>> In the end I wrote my own JMH harness around octane but I can't get >>> the results stable even with 3 day runs so my JMH code could be buggy. >>> >>> >>> Will share later off list if you're interested. >>> >>> >>> Regards, >>> >>> >>> Chris >>> @chriswhocodes >>> >>> >>> On Wed, June 24, 2015 16:00, Marcus Lagergren wrote: >>> >>>> Not sure if it???s available publically as part of JMH, but you can >>>> get the octane benchmark code itself from >>>> >>>> svn co http://octane-benchmark.googlecode.com/svn/trunk >>>> >>>> >>>> >>>> >>>> /M >>>> >>>> >>>> >>>>> On 24 Jun 2015, at 16:41, Volker Simonis >>>>> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> I just had the same question and couldn't find any answer with >>>>> Google >>>>> except this mail thread. >>>>> >>>>> So I'll just as again: is the Octane benchmark as part of JMH as >>>>> described in the Nashorn Wiki [1] publicly available somewhere? >>>>> >>>>> Thanks, >>>>> Volker >>>>> >>>>> >>>>> >>>>> [1] >>>>> https://wiki.openjdk.java.net/display/Nashorn/Monitoring+Nashorn+P >>>>> erfor mance >>>>> >>>>> On Thu, Apr 30, 2015 at 9:18 AM, Marcus Lagergren >>>>> wrote: >>>>> >>>>> >>>>>> >>>>>>> On 29 Apr 2015, at 09:08, Marcus Lagergren >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> The benchmark code itself is public, but I don???t know if >>>>>>> the benchmarks as part of JMH are. CC Aleksey /M >>>>>>> >>>>>>> >>>>>>>> On 28 Apr 2015, at 19:24, Chris Newland >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://wiki.openjdk.java.net/display/Nashorn/Monitoring+Na >>>>>>>> shorn+ Performance >>>>>>>> indicates the JMH microbenchmarks for octane are internal to >>>>>>>> Oracle (VPN >>>>>>>> needed). >>>>>>>> >>>>>>>> I can't see them elsewhere in the OpenJDK repos, are they >>>>>>>> public? >>>>>>>> >>>>>>>> >>>>>>>> Asking because the results I'm getting from >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> nashorn/test/script/external/octane$ jjs run.js >>>>>>>> >>>>>>>> are wildly variable (as per above wiki page). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>>> >>> >>> > > From attila.szegedi at oracle.com Thu Jun 25 15:26:19 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 25 Jun 2015 17:26:19 +0200 Subject: RFR: 8098547: (tz) Support tzdata2015e In-Reply-To: <558C1B48.1010204@oracle.com> References: <558A8F06.5010803@oracle.com> <4DFDE221-C843-4465-8A3F-7A658AD913C5@oracle.com> <558BDFE3.2030100@oracle.com> <558C1B48.1010204@oracle.com> Message-ID: <381BA948-8852-46AA-A4AC-9C144214BC03@oracle.com> Sure; filed >. (Removed Se?n Coffey from the recipient list as this is not a JDK8 issue.) Attila. > On Jun 25, 2015, at 5:16 PM, Naoto Sato wrote: > > Hi Attila, > > Looks like it's a regression caused by the fix to 8008577, where the default locale data switched to Unicode Consortium's CLDR. Would you please file an issue? > > Naoto > > On 6/25/15 5:49 AM, Attila Szegedi wrote: >> Yeah, basically instantiating a JavaScript native Date object with (70, 0, -10) and confirming it ends up being 10 days before epoch? >> This test failure happened tonight with jdk9, see >, so I presumed it has to be related (no changes to nashorn itself were made). It?s just suddenly the timezone is named ?CEST? instead of ?CET?. >> >>> On Jun 25, 2015, at 1:02 PM, Se?n Coffey wrote: >>> >>> That looks like a strange failure Attila. The timezone in use for that testcase is Europe/Vienna. >>> 2015e tzdata changes haven't been pushed to jdk9-dev forest yet. >>> >>> Where the 1969 date coming from ? Is there some rollover calculation happening ? >>> >>> Regards, >>> Sean. >>> >>> On 25/06/2015 09:05, Attila Szegedi wrote: >>>> FWIW, he do have one new test failure in Nashorn now, it seems related. Can you confirm it is caused by your changes? >>>> >>>> [testng] Test test/script/basic/NASHORN-627.js failed at line 1 - >>>> [testng] expected: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CET) -954000000 1969-12-20T23:00:00.000Z' >>>> [testng] found: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CEST) -954000000 1969-12-20T23:00:00.000Z' >>>> >>>> Attila. >>>> >>>>> On Jun 24, 2015, at 1:05 PM, Aleksej Efimov wrote: >>>>> >>>>> Hello, >>>>> >>>>> Please, review the latest tzdata (2015e) [1] integration to JDK9: http://cr.openjdk.java.net/~aefimov/tzdata/2015e/9/0 >>>>> Testing shows no TZ related failures on all platforms. >>>>> >>>>> With Best Regards, >>>>> Aleksej >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8098547 >>> >> From jan.lahoda at oracle.com Thu Jun 25 16:25:04 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 25 Jun 2015 18:25:04 +0200 Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs In-Reply-To: <5582D4CB.9090109@oracle.com> References: <5582D4CB.9090109@oracle.com> Message-ID: <558C2B60.6060502@oracle.com> Hello, Based on the feedback I've received so far, I've uploaded an updated version of the patch: http://cr.openjdk.java.net/~jlahoda/8080679/webrev.01/full/ Notable changes: -avoided the dependency on java.desktop and java.datatransfer -adjusted the native library build script as per Erik's recommendations -the module name is now changed to jdk.internal.le Any comments are welcome! Thanks, Jan On 18.6.2015 16:25, Jan Lahoda wrote: > Hello, > > I am proposing to add JLine 2.12.1 into the jdk repository for use by > the Java and Nashorn REPLs. Full patch is available here: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/full/ > > To aid the review, I've split this patch into to smaller patches: > -a patch that only adds unmodified jline sources at appropriate places > in the jdk repository: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/clean-jline/ > > -a patch that shows the additional changes I've done: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/additional/ > > This split is intended solely to simplify reviewing, my plan is to > integrate this as a single patch. > > The main additional changes are: > -plugging the new module, jdk.jline, into the JDK build. Currently, the > JLine packages are exported only to jdk.scripting.nashorn (the plan is > to also export them to the future jdk.jshell module). (The patch is not > adding the dependency from jdk.scripting.nashorn to jdk.jline, though - > I expect that to be added when needed.) > -the sources are re-packaged from package "jline" to "jdk.internal.jline" > -removing trailing whitespace, adding newlines at the end of the files, > encoding characters that are not ASCII > -avoiding the dependency on another library, jansi, by reimplementing > two elements that were used from the other library. These are mainly the > changes in WindowsTerminal and ConsoleReader.java. This also includes > the WindowsTerminal.cpp native library. The native part is heavily > inspired by: > http://cr.openjdk.java.net/~sherman/rl/src/java.base/windows/native/libjava/Console_md.c.html > > As I am not experienced in native programming, comments to the native > part would be particularly useful. > -changes to resolve javac warnings in JLine. > -tests for some of the added functionality. > > Any comments are welcome! > > Thanks, > Jan From Alan.Bateman at oracle.com Thu Jun 25 16:38:08 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 25 Jun 2015 17:38:08 +0100 Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs In-Reply-To: <558C2B60.6060502@oracle.com> References: <5582D4CB.9090109@oracle.com> <558C2B60.6060502@oracle.com> Message-ID: <558C2E70.4050704@oracle.com> On 25/06/2015 17:25, Jan Lahoda wrote: > Hello, > > Based on the feedback I've received so far, I've uploaded an updated > version of the patch: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.01/full/ > > Notable changes: > -avoided the dependency on java.desktop and java.datatransfer > -adjusted the native library build script as per Erik's recommendations > -the module name is now changed to jdk.internal.le > > Any comments are welcome! The new home and the dropping of the dependences on java.desktop & java.datatransfer look good. Since there only 2 tests then it might be better to add jdk/internal/jline to the mixed bag that is jdk_other. That way you don't need to update update jprt.properties and other places where the groups are used. The native method readKeyEvent seems to do a FindClass per key event. Maybe this is from the upstream project but I would think it would be more efficient to cache this in a global ref. It would also be more efficient if the INPUT_RECORD were just returned and avoid the upstream to create the object but that might be too much to change when you are trying to keep the code in sync with upstream. -Alan From anthony.vanelverdinghe at gmail.com Thu Jun 25 18:41:29 2015 From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe) Date: Thu, 25 Jun 2015 20:41:29 +0200 Subject: stdin parameter of $EXEC Message-ID: <558C4B59.5080707@gmail.com> Hi Looking at the fix for JDK-8080490 ("add $EXECV command to Nashorn scripting mode") raised a few questions concerning the stdin parameter of $EXEC: - sample exec.js [1] uses the empty string to denote "no stdin". Why wasn't undefined used instead? - $EXEC("someCmd", null) actually sends "null" to the process. In my opinion, null should be treated the same as undefined & not send any input to the process. - the implementation of $EXEC [2] always opens an OutputStreamWriter, even when there's no stdin. I think it would be better to move the if-statement out of the try-catch, like: if (input != UNDEFINED && input != NULL) { try (OutputStreamWriter outputStream = new OutputStreamWriter(process.getOutputStream())) { ... } catch (final IOException ex) {} } What do you think? [1] http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a24cb0bf79bc/samples/exec.js [2] http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a24cb0bf79bc/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptingFunctions.java#l217 Kind regards, Anthony From erik.joelsson at oracle.com Fri Jun 26 07:34:34 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 26 Jun 2015 09:34:34 +0200 Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs In-Reply-To: <558C2B60.6060502@oracle.com> References: <5582D4CB.9090109@oracle.com> <558C2B60.6060502@oracle.com> Message-ID: <558D008A.5050205@oracle.com> Hello Jan, Build changes look good. /Erik On 2015-06-25 18:25, Jan Lahoda wrote: > Hello, > > Based on the feedback I've received so far, I've uploaded an updated > version of the patch: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.01/full/ > > Notable changes: > -avoided the dependency on java.desktop and java.datatransfer > -adjusted the native library build script as per Erik's recommendations > -the module name is now changed to jdk.internal.le > > Any comments are welcome! > > Thanks, > Jan > > On 18.6.2015 16:25, Jan Lahoda wrote: >> Hello, >> >> I am proposing to add JLine 2.12.1 into the jdk repository for use by >> the Java and Nashorn REPLs. Full patch is available here: >> http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/full/ >> >> To aid the review, I've split this patch into to smaller patches: >> -a patch that only adds unmodified jline sources at appropriate places >> in the jdk repository: >> http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/clean-jline/ >> >> -a patch that shows the additional changes I've done: >> http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/additional/ >> >> This split is intended solely to simplify reviewing, my plan is to >> integrate this as a single patch. >> >> The main additional changes are: >> -plugging the new module, jdk.jline, into the JDK build. Currently, the >> JLine packages are exported only to jdk.scripting.nashorn (the plan is >> to also export them to the future jdk.jshell module). (The patch is not >> adding the dependency from jdk.scripting.nashorn to jdk.jline, though - >> I expect that to be added when needed.) >> -the sources are re-packaged from package "jline" to >> "jdk.internal.jline" >> -removing trailing whitespace, adding newlines at the end of the files, >> encoding characters that are not ASCII >> -avoiding the dependency on another library, jansi, by reimplementing >> two elements that were used from the other library. These are mainly the >> changes in WindowsTerminal and ConsoleReader.java. This also includes >> the WindowsTerminal.cpp native library. The native part is heavily >> inspired by: >> http://cr.openjdk.java.net/~sherman/rl/src/java.base/windows/native/libjava/Console_md.c.html >> >> >> As I am not experienced in native programming, comments to the native >> part would be particularly useful. >> -changes to resolve javac warnings in JLine. >> -tests for some of the added functionality. >> >> Any comments are welcome! >> >> Thanks, >> Jan From jan.lahoda at oracle.com Fri Jun 26 07:58:17 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 26 Jun 2015 09:58:17 +0200 Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs In-Reply-To: <558C2E70.4050704@oracle.com> References: <5582D4CB.9090109@oracle.com> <558C2B60.6060502@oracle.com> <558C2E70.4050704@oracle.com> Message-ID: <558D0619.7090108@oracle.com> Hi Alan, Thanks for the comments! A question inline. On 25.6.2015 18:38, Alan Bateman wrote: > > > On 25/06/2015 17:25, Jan Lahoda wrote: >> Hello, >> >> Based on the feedback I've received so far, I've uploaded an updated >> version of the patch: >> http://cr.openjdk.java.net/~jlahoda/8080679/webrev.01/full/ >> >> Notable changes: >> -avoided the dependency on java.desktop and java.datatransfer >> -adjusted the native library build script as per Erik's recommendations >> -the module name is now changed to jdk.internal.le >> >> Any comments are welcome! > The new home and the dropping of the dependences on java.desktop & > java.datatransfer look good. > > Since there only 2 tests then it might be better to add > jdk/internal/jline to the mixed bag that is jdk_other. That way you > don't need to update update jprt.properties and other places where the > groups are used. > > The native method readKeyEvent seems to do a FindClass per key event. > Maybe this is from the upstream project but I would think it would be > more efficient to cache this in a global ref. It would also be more I will work on this. > efficient if the INPUT_RECORD were just returned and avoid the upstream > to create the object but that might be too much to change when you are I am sorry, but I don't follow - I don't have much experience with native programing for JDK. Are there some more details on what I should do? > trying to keep the code in sync with upstream. This part of the code is not from the upstream, so I can change it as needed. Thanks! Jan > > -Alan > > > From attila.szegedi at oracle.com Fri Jun 26 10:20:51 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 26 Jun 2015 12:20:51 +0200 Subject: Review request for JDK-8129950: Wrong condition for checking absence of logger in MethodHandleFactory Message-ID: <1DB41460-3048-4A65-B477-EA2DC3816939@oracle.com> Please review JDK-8129950 "Wrong condition for checking absence of logger in MethodHandleFactory" at for Thanks, Attila. From hannes.wallnoefer at oracle.com Fri Jun 26 10:34:22 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 26 Jun 2015 12:34:22 +0200 Subject: Review request for JDK-8129950: Wrong condition for checking absence of logger in MethodHandleFactory In-Reply-To: <1DB41460-3048-4A65-B477-EA2DC3816939@oracle.com> References: <1DB41460-3048-4A65-B477-EA2DC3816939@oracle.com> Message-ID: <558D2AAE.10306@oracle.com> +1 Am 2015-06-26 um 12:20 schrieb Attila Szegedi: > Please review JDK-8129950 "Wrong condition for checking absence of logger in MethodHandleFactory" at for > > Thanks, > Attila. From attila.szegedi at oracle.com Fri Jun 26 11:02:30 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 26 Jun 2015 13:02:30 +0200 Subject: Review request for JDK-8129959: DebugLogger has unnecessary API methods Message-ID: Please review JDK-8129959 "DebugLogger has unnecessary API methods" at for Thanks, Attila. From marcus.lagergren at oracle.com Fri Jun 26 14:35:57 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 26 Jun 2015 16:35:57 +0200 Subject: Review request for JDK-8129950: Wrong condition for checking absence of logger in MethodHandleFactory In-Reply-To: <1DB41460-3048-4A65-B477-EA2DC3816939@oracle.com> References: <1DB41460-3048-4A65-B477-EA2DC3816939@oracle.com> Message-ID: <1A6CA73B-9C2A-406A-BABC-2C8BAA1ABCB2@oracle.com> +1. Thanks for this. /M > On 26 Jun 2015, at 12:20, Attila Szegedi wrote: > > Please review JDK-8129950 "Wrong condition for checking absence of logger in MethodHandleFactory" at for > > Thanks, > Attila. From marcus.lagergren at oracle.com Fri Jun 26 14:36:59 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 26 Jun 2015 16:36:59 +0200 Subject: Review request for JDK-8129959: DebugLogger has unnecessary API methods In-Reply-To: References: Message-ID: +1 That?s fine. More simple. > On 26 Jun 2015, at 13:02, Attila Szegedi wrote: > > Please review JDK-8129959 "DebugLogger has unnecessary API methods" at for > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Fri Jun 26 15:43:51 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 26 Jun 2015 17:43:51 +0200 Subject: Review request for JDK-8129959: DebugLogger has unnecessary API methods In-Reply-To: References: Message-ID: <558D7337.90102@oracle.com> +1 Am 2015-06-26 um 13:02 schrieb Attila Szegedi: > Please review JDK-8129959 "DebugLogger has unnecessary API methods" at for > > Thanks, > Attila. From stuart.marks at oracle.com Wed Jun 24 20:06:16 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 24 Jun 2015 13:06:16 -0700 Subject: JDK 9 RFR of JDK-8129597: Add tier 3 test definitions to the JDK 9 forest In-Reply-To: <558AE69C.7090905@oracle.com> References: <558AE69C.7090905@oracle.com> Message-ID: <558B0DB8.6030202@oracle.com> Hi Joe, Changes look good to me. I hope the initial tier3 test run passes. :-) s'marks On 6/24/15 10:19 AM, joe darcy wrote: > Hello, > > Per the recent email to jdk9-dev, > > "Test policy follow-up, third testing tier," > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-June/002325.html > > please review the patch below to address > > JDK-8129597 : Add tier 3 test definitions to the JDK 9 forest > http://cr.openjdk.java.net/~darcy/8129597.0/ > > (Tests will be added to tier 3 in subsequent changesets.) > > Thanks, > > -Joe > > --- old/jdk/test/TEST.groups 2015-06-23 09:47:53.929026307 -0700 > +++ new/jdk/test/TEST.groups 2015-06-23 09:47:53.761110302 -0700 > @@ -42,6 +42,9 @@ > :jdk_other \ > :jdk_svc > > +# Tier 3 is initially empty > +tier3 = > + > ############################################################################### > # > # Other test definitions; generally smaller granularity than tiers > --- old/langtools/test/TEST.groups 2015-06-23 09:47:54.296842319 -0700 > +++ new/langtools/test/TEST.groups 2015-06-23 09:47:54.192894315 -0700 > @@ -22,11 +22,14 @@ > > # Tiered testing definitions > > -# All langtools tests are tier 1 > +# All langtools tests are tier 1. > tier1 = \ > tools \ > com \ > lib > > -# No langtools tests are tier 2 > +# No langtools tests are tier 2. > tier2 = > + > +# No langtools tests are tier 3 either. > +tier3 = > --- old/jaxp/test/TEST.groups 2015-06-23 09:47:54.616682328 -0700 > +++ new/jaxp/test/TEST.groups 2015-06-23 09:47:54.528726325 -0700 > @@ -29,5 +29,8 @@ > tier2 = \ > :jaxp_all > > +# No tier 3 tests. > +tier3 = > + > jaxp_all = \ > javax/xml/jaxp > --- old/nashorn/test/TEST.groups 2015-06-23 09:47:54.936522337 -0700 > +++ new/nashorn/test/TEST.groups 2015-06-23 09:47:54.848566335 -0700 > @@ -27,3 +27,6 @@ > > # All nashorn tests are tier 2. > tier2 = src > + > +# No nashorn tests are tier 3. > +tier3 = > From naoto.sato at oracle.com Thu Jun 25 15:16:24 2015 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 25 Jun 2015 08:16:24 -0700 Subject: RFR: 8098547: (tz) Support tzdata2015e In-Reply-To: References: <558A8F06.5010803@oracle.com> <4DFDE221-C843-4465-8A3F-7A658AD913C5@oracle.com> <558BDFE3.2030100@oracle.com> Message-ID: <558C1B48.1010204@oracle.com> Hi Attila, Looks like it's a regression caused by the fix to 8008577, where the default locale data switched to Unicode Consortium's CLDR. Would you please file an issue? Naoto On 6/25/15 5:49 AM, Attila Szegedi wrote: > Yeah, basically instantiating a JavaScript native Date object with (70, 0, -10) and confirming it ends up being 10 days before epoch? > This test failure happened tonight with jdk9, see >, so I presumed it has to be related (no changes to nashorn itself were made). It?s just suddenly the timezone is named ?CEST? instead of ?CET?. > >> On Jun 25, 2015, at 1:02 PM, Se?n Coffey wrote: >> >> That looks like a strange failure Attila. The timezone in use for that testcase is Europe/Vienna. >> 2015e tzdata changes haven't been pushed to jdk9-dev forest yet. >> >> Where the 1969 date coming from ? Is there some rollover calculation happening ? >> >> Regards, >> Sean. >> >> On 25/06/2015 09:05, Attila Szegedi wrote: >>> FWIW, he do have one new test failure in Nashorn now, it seems related. Can you confirm it is caused by your changes? >>> >>> [testng] Test test/script/basic/NASHORN-627.js failed at line 1 - >>> [testng] expected: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CET) -954000000 1969-12-20T23:00:00.000Z' >>> [testng] found: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CEST) -954000000 1969-12-20T23:00:00.000Z' >>> >>> Attila. >>> >>>> On Jun 24, 2015, at 1:05 PM, Aleksej Efimov wrote: >>>> >>>> Hello, >>>> >>>> Please, review the latest tzdata (2015e) [1] integration to JDK9: http://cr.openjdk.java.net/~aefimov/tzdata/2015e/9/0 >>>> Testing shows no TZ related failures on all platforms. >>>> >>>> With Best Regards, >>>> Aleksej >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8098547 >> > From aleksej.efimov at oracle.com Thu Jun 25 11:31:40 2015 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Thu, 25 Jun 2015 14:31:40 +0300 Subject: RFR: 8098547: (tz) Support tzdata2015e In-Reply-To: <558BDFE3.2030100@oracle.com> References: <558A8F06.5010803@oracle.com> <4DFDE221-C843-4465-8A3F-7A658AD913C5@oracle.com> <558BDFE3.2030100@oracle.com> Message-ID: <558BE69C.5090805@oracle.com> Attila, Yes - this looks strange to me too. I checked the tzdata releases and there was no changes to Europe/Vienna since the 2014g (http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f7de7da2eb58). And as Sean stated the 2015e wasn't pushed to 9-dev repo yet. But, this one [1] was pushed just today and could cause observed failure. To confirm that, can you try to run your nashorn test with -Djava.locale.providers=JRE,SPI (similar to test updates in this bug)? For this tzdata2015e integration - I will run the tzdata tests with 8008577 changes - to confirm that there is no new failures. Thank you, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8008577 On 06/25/2015 02:02 PM, Se?n Coffey wrote: > That looks like a strange failure Attila. The timezone in use for that > testcase is Europe/Vienna. > 2015e tzdata changes haven't been pushed to jdk9-dev forest yet. > > Where the 1969 date coming from ? Is there some rollover calculation > happening ? > > Regards, > Sean. > > On 25/06/2015 09:05, Attila Szegedi wrote: >> FWIW, he do have one new test failure in Nashorn now, it seems >> related. Can you confirm it is caused by your changes? >> >> [testng] Test test/script/basic/NASHORN-627.js failed at line 1 - >> [testng] expected: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CET) >> -954000000 1969-12-20T23:00:00.000Z' >> [testng] found: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CEST) >> -954000000 1969-12-20T23:00:00.000Z' >> >> Attila. >> >>> On Jun 24, 2015, at 1:05 PM, Aleksej Efimov >>> wrote: >>> >>> Hello, >>> >>> Please, review the latest tzdata (2015e) [1] integration to JDK9: >>> http://cr.openjdk.java.net/~aefimov/tzdata/2015e/9/0 >>> Testing shows no TZ related failures on all platforms. >>> >>> With Best Regards, >>> Aleksej >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8098547 > From attila.szegedi at oracle.com Mon Jun 29 08:15:40 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 29 Jun 2015 10:15:40 +0200 Subject: Review request for JDK-8130035: Move test/script/basic/NASHORN-627.js to currently-failing until JDK-8129881 is fixed Message-ID: <24A32E55-0D3D-443C-B364-2C2CF49FD384@oracle.com> Please review JDK-8130035 "Move test/script/basic/NASHORN-627.js to currently-failing until JDK-8129881 is fixed" at for Thanks, Attila. From marcus.lagergren at oracle.com Mon Jun 29 08:18:17 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 29 Jun 2015 10:18:17 +0200 Subject: Review request for JDK-8130035: Move test/script/basic/NASHORN-627.js to currently-failing until JDK-8129881 is fixed In-Reply-To: <24A32E55-0D3D-443C-B364-2C2CF49FD384@oracle.com> References: <24A32E55-0D3D-443C-B364-2C2CF49FD384@oracle.com> Message-ID: <19D7BB99-1B85-4B9C-86A4-9BC81C572C28@oracle.com> +1. Please link this CR to the original issue. /M > On 29 Jun 2015, at 10:15, Attila Szegedi wrote: > > Please review JDK-8130035 "Move test/script/basic/NASHORN-627.js to currently-failing until JDK-8129881 is fixed" at for > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Mon Jun 29 08:24:38 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 29 Jun 2015 13:54:38 +0530 Subject: Review request for JDK-8130035: Move test/script/basic/NASHORN-627.js to currently-failing until JDK-8129881 is fixed In-Reply-To: <24A32E55-0D3D-443C-B364-2C2CF49FD384@oracle.com> References: <24A32E55-0D3D-443C-B364-2C2CF49FD384@oracle.com> Message-ID: <559100C6.8090401@oracle.com> +1 On Monday 29 June 2015 01:45 PM, Attila Szegedi wrote: > Please review JDK-8130035 "Move test/script/basic/NASHORN-627.js to currently-failing until JDK-8129881 is fixed" at for > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Mon Jun 29 16:02:53 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 29 Jun 2015 21:32:53 +0530 Subject: RFR 8114838: Anonymous functions escape to surrounding scope when defined under "with" statement Message-ID: <55916C2D.1010008@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8114838/ for https://bugs.openjdk.java.net/browse/JDK-8114838 Thanks, -Sundar From attila.szegedi at oracle.com Mon Jun 29 16:07:53 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 29 Jun 2015 18:07:53 +0200 Subject: RFR 8114838: Anonymous functions escape to surrounding scope when defined under "with" statement In-Reply-To: <55916C2D.1010008@oracle.com> References: <55916C2D.1010008@oracle.com> Message-ID: +1 > On Jun 29, 2015, at 6:02 PM, A. Sundararajan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8114838/ for https://bugs.openjdk.java.net/browse/JDK-8114838 > > Thanks, > -Sundar From hannes.wallnoefer at oracle.com Mon Jun 29 16:13:26 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 29 Jun 2015 18:13:26 +0200 Subject: RFR 8114838: Anonymous functions escape to surrounding scope when defined under "with" statement In-Reply-To: <55916C2D.1010008@oracle.com> References: <55916C2D.1010008@oracle.com> Message-ID: <55916EA6.4020705@oracle.com> Looks good! Hannes Am 2015-06-29 um 18:02 schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8114838/ for > https://bugs.openjdk.java.net/browse/JDK-8114838 > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Mon Jun 29 16:26:47 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 29 Jun 2015 21:56:47 +0530 Subject: RFR 8114838: Anonymous functions escape to surrounding scope when defined under "with" statement In-Reply-To: <55916EA6.4020705@oracle.com> References: <55916C2D.1010008@oracle.com> <55916EA6.4020705@oracle.com> Message-ID: <559171C7.2090909@oracle.com> Realized that I've left out the unused method in VarNode. Deleted it. Please review updated webrev @ http://cr.openjdk.java.net/~sundar/8114838/webrev.01/ Thanks -Sundar On Monday 29 June 2015 09:43 PM, Hannes Wallnoefer wrote: > Looks good! > > Hannes > > Am 2015-06-29 um 18:02 schrieb A. Sundararajan: >> Please review http://cr.openjdk.java.net/~sundar/8114838/ for >> https://bugs.openjdk.java.net/browse/JDK-8114838 >> >> Thanks, >> -Sundar > From attila.szegedi at oracle.com Mon Jun 29 19:12:49 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 29 Jun 2015 21:12:49 +0200 Subject: Fast passing of JSON between JS and Java (and vice versa) In-Reply-To: <95E5460F-E75E-42BD-895B-3CA63233FD35@oracle.com> References: <5477231D.8090304@gmail.com> <28461712-A70E-445E-B788-870886027EBE@oracle.com> <1D868CC1-342A-4972-AABA-7666382FE90C@oracle.com> <547776A9.1070805@gmail.com> <95E5460F-E75E-42BD-895B-3CA63233FD35@oracle.com> Message-ID: <66BDC180-9CBF-4828-B534-714AF8374BD2@oracle.com> Tim ? and everyone else interested ? this is now implemented. You can try it out with both JDK9 EA from > or JDK8u60 EA from > The final name of the API ended up being ?Java.asJSONCompatible(obj)? instead of ?Java.toJSONCompatible(obj)?. It?ll give you back an object that?s a live view of the underlying JS object, with most objects being represented as Map but JS native Array objects being represented as List instead, obviously applying to transitively retrieved properties of the initial object too. Cheers, Attila. > On Dec 5, 2014, at 2:30 PM, Attila Szegedi wrote: > > FYI, I filed it as an enhancement request so we don't lose track of it: https://bugs.openjdk.java.net/browse/JDK-8066773 > > On Nov 27, 2014, at 8:08 PM, Tim Fox wrote: > >> On 27/11/14 14:48, Attila Szegedi wrote: >>> So, some initial discussion of this with my team leads to following conclusions: >>> >>> - We can't stop wrapping all objects in ScriptObjectMirror, as ScriptObjectMirror is a public class, and we allow people to expect it. If we now started returning ScriptObjectMirror sometimes and ArrayMirror (provisional name) other times, that'd be an API breaking change. That's sad, really ? we should've probably never made ScriptObjectMirror public and instead forced people to only program against the JSObject interface instead. >>> >>> - We've been thinking of creating a separate "class ArrayMirror implements JSObject, List" for wrapping JS Arrays, but you'd need to explicitly ask a mirror that'll return these transitively, e.g. we could give you a Java.toJSONCompatible(obj) API that you'd use as: "myObject.expectsJSON(Java.toJSONCompatible(someJson));" You'd still be getting a ScriptObjectMirror on the top level (as long as it ain't an array in which case the top level would itself be an ArrayMirror), but it'd be carrying a hidden flag that'd change its behavior so whenever you retrieve an Array from it, it gets wrapped into ArrayMirror and not ScriptObjectMirror. Also, if you retrieve an Object from it, you'd get a ScriptObjectMirror with this flag propagated, so Arrays at any nesting depth would always be exposed as Lists. Arguably, this could be the default behaviour except for the fact that it isn't how it worked since the initial 8 release and we can't break backwards compatibility? >>> >>> How's that sound? >> >> >> Sounds good. Thanks for taking time to look at this :) >> >>> >>> Attila. >>> >>> On Nov 27, 2014, at 2:46 PM, Attila Szegedi wrote: >>> >>>> Also, the documentation for both List and Map interfaces prescribes an exact algorithm[1][2] that every implementation of them must use to calculate their hashCode(), and they too are incompatible. This is not as insurmountable as a javac error, but still not a good idea to violate. FWIW, having a separate ArrayMirror that implements only List might still be workable. >>>> >>>> Attila. >>>> >>>> --- >>>> [1] http://docs.oracle.com/javase/8/docs/api/java/util/List.html#hashCode-- >>>> [2] http://docs.oracle.com/javase/8/docs/api/java/util/Map.html#hashCode-- >>>> >>>> On Nov 27, 2014, at 2:40 PM, Attila Szegedi wrote: >>>> >>>>> [...] >>>>> >>>>> Unfortunately, we can't subclass ScriptObjectMirror to give you an ArrayMirror as no Java class can simultaneously implement both List and Map interfaces due to incompatibility in return types of "Object Map.remove(Object)" and "boolean List.remove(Object)" :-( Trust me, I was quite mad when I first realized this. >>>>> >>>>> [...] >>>>> >>>>> Attila. >>>>> >>>>> On Nov 27, 2014, at 2:11 PM, Tim Fox wrote: >>>>> >>>>>> As you know.. >>>>>> >>>>>> In JS, a JSON Object is represented by a JS object, and in the Java world it's often represented by Map. >>>>>> In JS a JSON array is represented by a JS array, and in the Java world it's often represented by a List. >>>>>> >>>>>> I'd love to be able to pass JSON between JS and Java and vice versa with the minimum of performance overhead. This is particularly important in Vert.x as we chuck a lot of JSON around. >>>>>> >>>>>> Let's say I have a Java interface which expects some JSON: >>>>>> >>>>>> interface SomeInterface { >>>>>> >>>>>> void expectsJSON(Map json); >>>>>> } >>>>>> >>>>>> Right now I am converting from JS-->Java as follows. >>>>>> >>>>>> var someJson = { foo: "bar"}; >>>>>> String encoded = JSON.stringify(someJson); >>>>>> Map map = SomeJavaJSONLibrary.decode(encoded); >>>>>> myObject.expectsJSON(map); >>>>>> >>>>>> As you can see it's pretty clunky. The other direction is equally as clunky. And it's slow as we're encoding/decoding everything via String. >>>>>> >>>>>> Then I realised that if I pass a JS object directly into the expectsJSON method Nashorn will provide me with a Map that backs the original object. I.e. I can do this: >>>>>> >>>>>> var someJson = { foo: "bar"}; >>>>>> myObject.expectsJSON(map); >>>>>> >>>>>> Yay! No encoding overhead. Fast. :) >>>>>> >>>>>> And it works with nested json: >>>>>> >>>>>> var someJson = { foo: "bar", nested: { wibble: "blah"}}; >>>>>> >>>>>> Just when I was getting my hopes up that this would be a great super fast way of transferring JSON betwen Java and JS, I tried it with a nest array: >>>>>> >>>>>> var someJson = { foo: "bar", nestedArray: [123, 456]}; >>>>>> >>>>>> But in Java, map.get("nestedArray") returns a ScriptObjectMirror not a List as I was hoping. :( >>>>>> >>>>>> So.. passing from JS to Java: JS Object maps to Map, but JS Array maps to ScriptObjectMirror. (Seems a bit asymmetric?). >>>>>> >>>>>> Any reason why we can't map JS Array to Java list when calling JS->Java? (Perhaps this is related to my previous question backing a JS Array with a List...) >>>>>> >>>>>> Do you have any other suggestions for transferring JSON between JS and Java without too much encoding overhead? >>>>>> >>>>>> Thanks again! > From hannes.wallnoefer at oracle.com Tue Jun 30 08:10:23 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 30 Jun 2015 10:10:23 +0200 Subject: RFR 8114838: Anonymous functions escape to surrounding scope when defined under "with" statement In-Reply-To: <559171C7.2090909@oracle.com> References: <55916C2D.1010008@oracle.com> <55916EA6.4020705@oracle.com> <559171C7.2090909@oracle.com> Message-ID: <55924EEF.3090402@oracle.com> +1 Am 2015-06-29 um 18:26 schrieb A. Sundararajan: > Realized that I've left out the unused method in VarNode. Deleted it. > Please review updated webrev @ > http://cr.openjdk.java.net/~sundar/8114838/webrev.01/ > > Thanks > -Sundar > > On Monday 29 June 2015 09:43 PM, Hannes Wallnoefer wrote: >> Looks good! >> >> Hannes >> >> Am 2015-06-29 um 18:02 schrieb A. Sundararajan: >>> Please review http://cr.openjdk.java.net/~sundar/8114838/ for >>> https://bugs.openjdk.java.net/browse/JDK-8114838 >>> >>> Thanks, >>> -Sundar >> > From tonyzakula at gmail.com Tue Jun 30 11:51:50 2015 From: tonyzakula at gmail.com (Tony Zakula) Date: Tue, 30 Jun 2015 06:51:50 -0500 Subject: Fast passing of JSON between JS and Java (and vice versa) In-Reply-To: <66BDC180-9CBF-4828-B534-714AF8374BD2@oracle.com> References: <5477231D.8090304@gmail.com> <28461712-A70E-445E-B788-870886027EBE@oracle.com> <1D868CC1-342A-4972-AABA-7666382FE90C@oracle.com> <547776A9.1070805@gmail.com> <95E5460F-E75E-42BD-895B-3CA63233FD35@oracle.com> <66BDC180-9CBF-4828-B534-714AF8374BD2@oracle.com> Message-ID: That is great. We will leverage this right away. Thanks. Tony On Mon, Jun 29, 2015 at 2:12 PM, Attila Szegedi wrote: > Tim ? and everyone else interested ? this is now implemented. You can try > it out with both JDK9 EA from https://jdk9.java.net/download>> or JDK8u60 EA from < > https://jdk8.java.net/download.html > > > The final name of the API ended up being ?Java.asJSONCompatible(obj)? > instead of ?Java.toJSONCompatible(obj)?. It?ll give you back an object > that?s a live view of the underlying JS object, with most objects being > represented as Map but JS native Array objects being > represented as List instead, obviously applying to transitively > retrieved properties of the initial object too. > > Cheers, > Attila. > > > On Dec 5, 2014, at 2:30 PM, Attila Szegedi > wrote: > > > > FYI, I filed it as an enhancement request so we don't lose track of it: > https://bugs.openjdk.java.net/browse/JDK-8066773 > > > > On Nov 27, 2014, at 8:08 PM, Tim Fox wrote: > > > >> On 27/11/14 14:48, Attila Szegedi wrote: > >>> So, some initial discussion of this with my team leads to following > conclusions: > >>> > >>> - We can't stop wrapping all objects in ScriptObjectMirror, as > ScriptObjectMirror is a public class, and we allow people to expect it. If > we now started returning ScriptObjectMirror sometimes and ArrayMirror > (provisional name) other times, that'd be an API breaking change. That's > sad, really ? we should've probably never made ScriptObjectMirror public > and instead forced people to only program against the JSObject interface > instead. > >>> > >>> - We've been thinking of creating a separate "class ArrayMirror > implements JSObject, List" for wrapping JS Arrays, but you'd need > to explicitly ask a mirror that'll return these transitively, e.g. we could > give you a Java.toJSONCompatible(obj) API that you'd use as: > "myObject.expectsJSON(Java.toJSONCompatible(someJson));" You'd still be > getting a ScriptObjectMirror on the top level (as long as it ain't an array > in which case the top level would itself be an ArrayMirror), but it'd be > carrying a hidden flag that'd change its behavior so whenever you retrieve > an Array from it, it gets wrapped into ArrayMirror and not > ScriptObjectMirror. Also, if you retrieve an Object from it, you'd get a > ScriptObjectMirror with this flag propagated, so Arrays at any nesting > depth would always be exposed as Lists. Arguably, this could be the default > behaviour except for the fact that it isn't how it worked since the initial > 8 release and we can't break backwards compatibility? > >>> > >>> How's that sound? > >> > >> > >> Sounds good. Thanks for taking time to look at this :) > >> > >>> > >>> Attila. > >>> > >>> On Nov 27, 2014, at 2:46 PM, Attila Szegedi > wrote: > >>> > >>>> Also, the documentation for both List and Map interfaces prescribes > an exact algorithm[1][2] that every implementation of them must use to > calculate their hashCode(), and they too are incompatible. This is not as > insurmountable as a javac error, but still not a good idea to violate. > FWIW, having a separate ArrayMirror that implements only List might > still be workable. > >>>> > >>>> Attila. > >>>> > >>>> --- > >>>> [1] > http://docs.oracle.com/javase/8/docs/api/java/util/List.html#hashCode-- > >>>> [2] > http://docs.oracle.com/javase/8/docs/api/java/util/Map.html#hashCode-- > >>>> > >>>> On Nov 27, 2014, at 2:40 PM, Attila Szegedi < > attila.szegedi at oracle.com> wrote: > >>>> > >>>>> [...] > >>>>> > >>>>> Unfortunately, we can't subclass ScriptObjectMirror to give you an > ArrayMirror as no Java class can simultaneously implement both List and Map > interfaces due to incompatibility in return types of "Object > Map.remove(Object)" and "boolean List.remove(Object)" :-( Trust me, I was > quite mad when I first realized this. > >>>>> > >>>>> [...] > >>>>> > >>>>> Attila. > >>>>> > >>>>> On Nov 27, 2014, at 2:11 PM, Tim Fox wrote: > >>>>> > >>>>>> As you know.. > >>>>>> > >>>>>> In JS, a JSON Object is represented by a JS object, and in the Java > world it's often represented by Map. > >>>>>> In JS a JSON array is represented by a JS array, and in the Java > world it's often represented by a List. > >>>>>> > >>>>>> I'd love to be able to pass JSON between JS and Java and vice versa > with the minimum of performance overhead. This is particularly important in > Vert.x as we chuck a lot of JSON around. > >>>>>> > >>>>>> Let's say I have a Java interface which expects some JSON: > >>>>>> > >>>>>> interface SomeInterface { > >>>>>> > >>>>>> void expectsJSON(Map json); > >>>>>> } > >>>>>> > >>>>>> Right now I am converting from JS-->Java as follows. > >>>>>> > >>>>>> var someJson = { foo: "bar"}; > >>>>>> String encoded = JSON.stringify(someJson); > >>>>>> Map map = SomeJavaJSONLibrary.decode(encoded); > >>>>>> myObject.expectsJSON(map); > >>>>>> > >>>>>> As you can see it's pretty clunky. The other direction is equally > as clunky. And it's slow as we're encoding/decoding everything via String. > >>>>>> > >>>>>> Then I realised that if I pass a JS object directly into the > expectsJSON method Nashorn will provide me with a Map that > backs the original object. I.e. I can do this: > >>>>>> > >>>>>> var someJson = { foo: "bar"}; > >>>>>> myObject.expectsJSON(map); > >>>>>> > >>>>>> Yay! No encoding overhead. Fast. :) > >>>>>> > >>>>>> And it works with nested json: > >>>>>> > >>>>>> var someJson = { foo: "bar", nested: { wibble: "blah"}}; > >>>>>> > >>>>>> Just when I was getting my hopes up that this would be a great > super fast way of transferring JSON betwen Java and JS, I tried it with a > nest array: > >>>>>> > >>>>>> var someJson = { foo: "bar", nestedArray: [123, 456]}; > >>>>>> > >>>>>> But in Java, map.get("nestedArray") returns a ScriptObjectMirror > not a List as I was hoping. :( > >>>>>> > >>>>>> So.. passing from JS to Java: JS Object maps to Map, but JS Array > maps to ScriptObjectMirror. (Seems a bit asymmetric?). > >>>>>> > >>>>>> Any reason why we can't map JS Array to Java list when calling > JS->Java? (Perhaps this is related to my previous question backing a JS > Array with a List...) > >>>>>> > >>>>>> Do you have any other suggestions for transferring JSON between JS > and Java without too much encoding overhead? > >>>>>> > >>>>>> Thanks again! > > > > From attila.szegedi at oracle.com Tue Jun 30 11:55:56 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 30 Jun 2015 13:55:56 +0200 Subject: RFR 8114838: Anonymous functions escape to surrounding scope when defined under "with" statement In-Reply-To: <55924EEF.3090402@oracle.com> References: <55916C2D.1010008@oracle.com> <55916EA6.4020705@oracle.com> <559171C7.2090909@oracle.com> <55924EEF.3090402@oracle.com> Message-ID: <1771C877-67E0-4A31-A462-C7896E0CF80C@oracle.com> +1 > On Jun 30, 2015, at 10:10 AM, Hannes Wallnoefer wrote: > > +1 > > Am 2015-06-29 um 18:26 schrieb A. Sundararajan: >> Realized that I've left out the unused method in VarNode. Deleted it. Please review updated webrev @ >> http://cr.openjdk.java.net/~sundar/8114838/webrev.01/ >> >> Thanks >> -Sundar >> >> On Monday 29 June 2015 09:43 PM, Hannes Wallnoefer wrote: >>> Looks good! >>> >>> Hannes >>> >>> Am 2015-06-29 um 18:02 schrieb A. Sundararajan: >>>> Please review http://cr.openjdk.java.net/~sundar/8114838/ for https://bugs.openjdk.java.net/browse/JDK-8114838 >>>> >>>> Thanks, >>>> -Sundar >>> >> > From michael.haupt at oracle.com Tue Jun 30 13:18:00 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 30 Jun 2015 15:18:00 +0200 Subject: stdin parameter of $EXEC In-Reply-To: <558C4B59.5080707@gmail.com> References: <558C4B59.5080707@gmail.com> Message-ID: <3A2B6E5D-2807-4D3D-900D-EF4FE02435EA@oracle.com> Hi Anthony, thank you, these are good points. In fact, undefined and null should be treated as no input. The corresponding issue is here: https://bugs.openjdk.java.net/browse/JDK-8130127 Best, Michael > Am 25.06.2015 um 20:41 schrieb Anthony Vanelverdinghe : > > Hi > > Looking at the fix for JDK-8080490 ("add $EXECV command to Nashorn scripting mode") raised a few questions concerning the stdin parameter of $EXEC: > > - sample exec.js [1] uses the empty string to denote "no stdin". Why wasn't undefined used instead? > - $EXEC("someCmd", null) actually sends "null" to the process. In my opinion, null should be treated the same as undefined & not send any input to the process. > - the implementation of $EXEC [2] always opens an OutputStreamWriter, even when there's no stdin. I think it would be better to move the if-statement out of the try-catch, like: > > if (input != UNDEFINED && input != NULL) { > try (OutputStreamWriter outputStream = new OutputStreamWriter(process.getOutputStream())) { > ... > } catch (final IOException ex) {} > } > > What do you think? > > [1] http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a24cb0bf79bc/samples/exec.js > [2] http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a24cb0bf79bc/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptingFunctions.java#l217 > > Kind regards, > Anthony -- 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 is committed to developing practices and products that help protect the environment