From jan.lahoda at oracle.com Tue Apr 3 16:06:20 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 3 Apr 2018 18:06:20 +0200 Subject: RFR 8198801: JShell: user exception chained cause not retained In-Reply-To: <185d5de5-2389-7fc4-6136-d4b5870ab6cc@oracle.com> References: <185d5de5-2389-7fc4-6136-d4b5870ab6cc@oracle.com> Message-ID: <5AC3A67C.3030809@oracle.com> Looks OK to me. Jan On 15.3.2018 22:13, Robert Field wrote: > Please review. > > See bug report for details: > > https://bugs.openjdk.java.net/browse/JDK-8198801 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8198801v0.webrev/ > > Thanks, > Robert > From amy.lu at oracle.com Wed Apr 4 03:26:39 2018 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 4 Apr 2018 11:26:39 +0800 Subject: [11] RFR 8200703: Problem list jdk/jshell/ExceptionsTest.java fails on windows Message-ID: <57fb43a9-6da8-6a53-22d8-ee418700f8da@oracle.com> jdk/jshell/ExceptionsTest.java This test has been failing on Windows (JDK-8200701) since the push for JDK-8198801. The test needs to be problem listed on Windows until a full fix is developed. Please review the patch below. Thanks, Amy --- old/test/langtools/ProblemList.txt?? ?2018-04-04 11:17:19.000000000 +0800 +++ new/test/langtools/ProblemList.txt?? ?2018-04-04 11:17:19.000000000 +0800 @@ -38,6 +38,7 @@ ?jdk/jshell/UserJdiUserRemoteTest.java 8173079??? linux-all ?jdk/jshell/UserInputTest.java 8169536??? generic-all +jdk/jshell/ExceptionsTest.java 8200701??? windows-all ?########################################################################### ?# From amy.lu at oracle.com Wed Apr 4 08:11:24 2018 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 4 Apr 2018 16:11:24 +0800 Subject: [11] RFR 8200703: Problem list jdk/jshell/ExceptionsTest.java fails on windows In-Reply-To: <57fb43a9-6da8-6a53-22d8-ee418700f8da@oracle.com> References: <57fb43a9-6da8-6a53-22d8-ee418700f8da@oracle.com> Message-ID: [Including core-libs-dev] Quick review needed. bug: https://bugs.openjdk.java.net/browse/JDK-8200703 webrev: http://cr.openjdk.java.net/~amlu/8200703/webrev.00/ Thanks, Amy On 04/04/2018 11:26 AM, Amy Lu wrote: > jdk/jshell/ExceptionsTest.java > > This test has been failing on Windows (JDK-8200701) since the push for > JDK-8198801. The test needs to be problem listed on Windows until a > full fix is developed. > > Please review the patch below. > > Thanks, > Amy > > > --- old/test/langtools/ProblemList.txt?? ?2018-04-04 > 11:17:19.000000000 +0800 > +++ new/test/langtools/ProblemList.txt?? ?2018-04-04 > 11:17:19.000000000 +0800 > @@ -38,6 +38,7 @@ > > ?jdk/jshell/UserJdiUserRemoteTest.java 8173079??? linux-all > ?jdk/jshell/UserInputTest.java 8169536??? generic-all > +jdk/jshell/ExceptionsTest.java 8200701??? windows-all > > ?########################################################################### > > ?# > From jan.lahoda at oracle.com Wed Apr 4 08:37:38 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 4 Apr 2018 10:37:38 +0200 Subject: [11] RFR 8200703: Problem list jdk/jshell/ExceptionsTest.java fails on windows In-Reply-To: <57fb43a9-6da8-6a53-22d8-ee418700f8da@oracle.com> References: <57fb43a9-6da8-6a53-22d8-ee418700f8da@oracle.com> Message-ID: <5AC48ED2.6000900@oracle.com> Hi, Ok to problem list. Jan On 4.4.2018 05:26, Amy Lu wrote: > jdk/jshell/ExceptionsTest.java > > This test has been failing on Windows (JDK-8200701) since the push for > JDK-8198801. The test needs to be problem listed on Windows until a full > fix is developed. > > Please review the patch below. > > Thanks, > Amy > > > --- old/test/langtools/ProblemList.txt 2018-04-04 11:17:19.000000000 > +0800 > +++ new/test/langtools/ProblemList.txt 2018-04-04 11:17:19.000000000 > +0800 > @@ -38,6 +38,7 @@ > > jdk/jshell/UserJdiUserRemoteTest.java 8173079 linux-all > jdk/jshell/UserInputTest.java 8169536 generic-all > +jdk/jshell/ExceptionsTest.java 8200701 windows-all > > ########################################################################### > # > From amy.lu at oracle.com Wed Apr 4 08:53:56 2018 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 4 Apr 2018 16:53:56 +0800 Subject: [11] RFR 8200703: Problem list jdk/jshell/ExceptionsTest.java fails on windows In-Reply-To: <5AC48ED2.6000900@oracle.com> References: <57fb43a9-6da8-6a53-22d8-ee418700f8da@oracle.com> <5AC48ED2.6000900@oracle.com> Message-ID: <2b58adbc-55dd-0fc2-ab1c-6dc9c4499b6a@oracle.com> Thank you Jan. Thanks, Amy On 04/04/2018 4:37 PM, Jan Lahoda wrote: > Hi, > > Ok to problem list. > > Jan > > On 4.4.2018 05:26, Amy Lu wrote: >> jdk/jshell/ExceptionsTest.java >> >> This test has been failing on Windows (JDK-8200701) since the push for >> JDK-8198801. The test needs to be problem listed on Windows until a full >> fix is developed. >> >> Please review the patch below. >> >> Thanks, >> Amy >> >> >> --- old/test/langtools/ProblemList.txt??? 2018-04-04 11:17:19.000000000 >> +0800 >> +++ new/test/langtools/ProblemList.txt??? 2018-04-04 11:17:19.000000000 >> +0800 >> @@ -38,6 +38,7 @@ >> >> ? jdk/jshell/UserJdiUserRemoteTest.java 8173079??? linux-all >> ? jdk/jshell/UserInputTest.java 8169536??? generic-all >> +jdk/jshell/ExceptionsTest.java 8200701??? windows-all >> >> ########################################################################### >> ? # >> From robert.field at oracle.com Mon Apr 23 07:10:09 2018 From: robert.field at oracle.com (Robert Field) Date: Mon, 23 Apr 2018 00:10:09 -0700 Subject: RFR 8199193: jshell tool: Add support for preview features Message-ID: <175fb443-2ecd-f380-c695-6a9626462a1c@oracle.com> Please review.... Bug: ??? https://bugs.openjdk.java.net/browse/JDK-8199193 Webrev: ??? http://cr.openjdk.java.net/~rfield/8199193v0.webrev/ Thanks, Robert From sundararajan.athijegannathan at oracle.com Mon Apr 23 07:51:04 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 23 Apr 2018 00:51:04 -0700 Subject: RFR 8199193: jshell tool: Add support for preview features In-Reply-To: <175fb443-2ecd-f380-c695-6a9626462a1c@oracle.com> References: <175fb443-2ecd-f380-c695-6a9626462a1c@oracle.com> Message-ID: <5ADD9068.8030205@oracle.com> * On the new ToolEnablePreviewTest: 1) do you need to build KullTesting for this test? 2) do you need those @module declarations for this test? Seems like this test stays within public APIs. -Sundar On 23/04/18, 12:10 AM, Robert Field wrote: > Please review.... > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8199193 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8199193v0.webrev/ > > Thanks, > Robert > > From robert.field at oracle.com Mon Apr 23 15:41:04 2018 From: robert.field at oracle.com (Robert Field) Date: Mon, 23 Apr 2018 08:41:04 -0700 Subject: RFR 8199193: jshell tool: Add support for preview features In-Reply-To: <5ADD9068.8030205@oracle.com> References: <175fb443-2ecd-f380-c695-6a9626462a1c@oracle.com> <5ADD9068.8030205@oracle.com> Message-ID: <058c4a46-b262-1385-35dd-140a019bf0c1@oracle.com> On 04/23/18 00:51, Sundararajan Athijegannathan wrote: > * On the new ToolEnablePreviewTest: > > 1) do you need to build KullTesting for this test? > 2) do you need those @module declarations for this test? Seems like > this test stays within public APIs. All the tool tests clone, probably excess, @modules.? And neither @build is, I believe, needed. I've changed the header to just: /* ?* @test ?* @bug 8199193 ?* @summary Tests for the --enable-preview option ?* @run testng ToolEnablePreviewTest ?*/ New webrev, with only this header changed: ??? http://cr.openjdk.java.net/~rfield/8199193v1.webrev/ Thanks, Robert > > -Sundar > > On 23/04/18, 12:10 AM, Robert Field wrote: >> Please review.... >> >> Bug: >> >> ??? https://bugs.openjdk.java.net/browse/JDK-8199193 >> >> Webrev: >> >> ??? http://cr.openjdk.java.net/~rfield/8199193v0.webrev/ >> >> Thanks, >> Robert >> >> From sundararajan.athijegannathan at oracle.com Mon Apr 23 15:54:00 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 23 Apr 2018 08:54:00 -0700 Subject: RFR 8199193: jshell tool: Add support for preview features In-Reply-To: <058c4a46-b262-1385-35dd-140a019bf0c1@oracle.com> References: <175fb443-2ecd-f380-c695-6a9626462a1c@oracle.com> <5ADD9068.8030205@oracle.com> <058c4a46-b262-1385-35dd-140a019bf0c1@oracle.com> Message-ID: <5ADE0198.8010608@oracle.com> Looks good -Sundar On 23/04/18, 8:41 AM, Robert Field wrote: > On 04/23/18 00:51, Sundararajan Athijegannathan wrote: > >> * On the new ToolEnablePreviewTest: >> >> 1) do you need to build KullTesting for this test? >> 2) do you need those @module declarations for this test? Seems like >> this test stays within public APIs. > > All the tool tests clone, probably excess, @modules. And neither > @build is, I believe, needed. > > I've changed the header to just: > > /* > * @test > * @bug 8199193 > * @summary Tests for the --enable-preview option > * @run testng ToolEnablePreviewTest > */ > > > New webrev, with only this header changed: > > http://cr.openjdk.java.net/~rfield/8199193v1.webrev/ > > Thanks, > Robert > >> >> -Sundar >> >> On 23/04/18, 12:10 AM, Robert Field wrote: >>> Please review.... >>> >>> Bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8199193 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~rfield/8199193v0.webrev/ >>> >>> Thanks, >>> Robert >>> >>> > From jonathan.gibbons at oracle.com Mon Apr 23 16:14:25 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 23 Apr 2018 09:14:25 -0700 Subject: RFR 8199193: jshell tool: Add support for preview features In-Reply-To: <058c4a46-b262-1385-35dd-140a019bf0c1@oracle.com> References: <175fb443-2ecd-f380-c695-6a9626462a1c@oracle.com> <5ADD9068.8030205@oracle.com> <058c4a46-b262-1385-35dd-140a019bf0c1@oracle.com> Message-ID: <715cc4be-1fd5-7728-bcbb-3940f893ebfd@oracle.com> You need @modules.??? You may not need to export/open any internal API, but you certainly need the presence of certain modules. -- Jon On 4/23/18 8:41 AM, Robert Field wrote: > On 04/23/18 00:51, Sundararajan Athijegannathan wrote: > >> * On the new ToolEnablePreviewTest: >> >> 1) do you need to build KullTesting for this test? >> 2) do you need those @module declarations for this test? Seems like >> this test stays within public APIs. > > All the tool tests clone, probably excess, @modules.? And neither > @build is, I believe, needed. > > I've changed the header to just: > > ?? /* > ??? ?* @test > ??? ?* @bug 8199193 > ??? ?* @summary Tests for the --enable-preview option > ??? ?* @run testng ToolEnablePreviewTest > ??? ?*/ > > > New webrev, with only this header changed: > > ??? http://cr.openjdk.java.net/~rfield/8199193v1.webrev/ > > Thanks, > Robert > >> >> -Sundar >> >> On 23/04/18, 12:10 AM, Robert Field wrote: >>> Please review.... >>> >>> Bug: >>> >>> ??? https://bugs.openjdk.java.net/browse/JDK-8199193 >>> >>> Webrev: >>> >>> ??? http://cr.openjdk.java.net/~rfield/8199193v0.webrev/ >>> >>> Thanks, >>> Robert >>> >>> > From sundararajan.athijegannathan at oracle.com Mon Apr 23 16:32:08 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 23 Apr 2018 09:32:08 -0700 Subject: RFR 8199193: jshell tool: Add support for preview features In-Reply-To: <715cc4be-1fd5-7728-bcbb-3940f893ebfd@oracle.com> References: <175fb443-2ecd-f380-c695-6a9626462a1c@oracle.com> <5ADD9068.8030205@oracle.com> <058c4a46-b262-1385-35dd-140a019bf0c1@oracle.com> <715cc4be-1fd5-7728-bcbb-3940f893ebfd@oracle.com> Message-ID: <5ADE0A88.6020303@oracle.com> To check the presence of jdk.jshell module? (to avoid running it when that module is not present?). Even then we don't need it in the form with internal package names, right? @modules jdk.jshell ? -Sundar On 23/04/18, 9:14 AM, Jonathan Gibbons wrote: > You need @modules. You may not need to export/open any internal > API, but you certainly need the presence of certain modules. > > -- Jon > > > On 4/23/18 8:41 AM, Robert Field wrote: >> On 04/23/18 00:51, Sundararajan Athijegannathan wrote: >> >>> * On the new ToolEnablePreviewTest: >>> >>> 1) do you need to build KullTesting for this test? >>> 2) do you need those @module declarations for this test? Seems like >>> this test stays within public APIs. >> >> All the tool tests clone, probably excess, @modules. And neither >> @build is, I believe, needed. >> >> I've changed the header to just: >> >> /* >> * @test >> * @bug 8199193 >> * @summary Tests for the --enable-preview option >> * @run testng ToolEnablePreviewTest >> */ >> >> >> New webrev, with only this header changed: >> >> http://cr.openjdk.java.net/~rfield/8199193v1.webrev/ >> >> Thanks, >> Robert >> >>> >>> -Sundar >>> >>> On 23/04/18, 12:10 AM, Robert Field wrote: >>>> Please review.... >>>> >>>> Bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8199193 >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~rfield/8199193v0.webrev/ >>>> >>>> Thanks, >>>> Robert >>>> >>>> >> > From robert.field at oracle.com Mon Apr 23 18:23:52 2018 From: robert.field at oracle.com (Robert Field) Date: Mon, 23 Apr 2018 11:23:52 -0700 Subject: RFR 8199193: jshell tool: Add support for preview features In-Reply-To: <715cc4be-1fd5-7728-bcbb-3940f893ebfd@oracle.com> References: <175fb443-2ecd-f380-c695-6a9626462a1c@oracle.com> <5ADD9068.8030205@oracle.com> <058c4a46-b262-1385-35dd-140a019bf0c1@oracle.com> <715cc4be-1fd5-7728-bcbb-3940f893ebfd@oracle.com> Message-ID: On 04/23/18 09:14, Jonathan Gibbons wrote: > You need @modules.??? You may not need to export/open any internal > API, but you certainly need the presence of certain modules. Thanks. Since tests are generally run with the full JDK, they do not verify the correctness of the @modules tag.? Do we have a way to verify/generate the correct entries?? Without testing, won't these descend into meaningless cloning of @modules or missing @modules? The tag spec: ?? http://openjdk.java.net/jtreg/tag-spec.html Does not document :open, ... It is not documented, can it be assumed that dependencies of a module are included automatically? -Robert > > -- Jon > > > On 4/23/18 8:41 AM, Robert Field wrote: >> On 04/23/18 00:51, Sundararajan Athijegannathan wrote: >> >>> * On the new ToolEnablePreviewTest: >>> >>> 1) do you need to build KullTesting for this test? >>> 2) do you need those @module declarations for this test? Seems like >>> this test stays within public APIs. >> >> All the tool tests clone, probably excess, @modules.? And neither >> @build is, I believe, needed. >> >> I've changed the header to just: >> >> ?? /* >> ??? ?* @test >> ??? ?* @bug 8199193 >> ??? ?* @summary Tests for the --enable-preview option >> ??? ?* @run testng ToolEnablePreviewTest >> ??? ?*/ >> >> >> New webrev, with only this header changed: >> >> ??? http://cr.openjdk.java.net/~rfield/8199193v1.webrev/ >> >> Thanks, >> Robert >> >>> >>> -Sundar >>> >>> On 23/04/18, 12:10 AM, Robert Field wrote: >>>> Please review.... >>>> >>>> Bug: >>>> >>>> ??? https://bugs.openjdk.java.net/browse/JDK-8199193 >>>> >>>> Webrev: >>>> >>>> ??? http://cr.openjdk.java.net/~rfield/8199193v0.webrev/ >>>> >>>> Thanks, >>>> Robert >>>> >>>> >> > From jonathan.gibbons at oracle.com Mon Apr 23 18:54:59 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 23 Apr 2018 11:54:59 -0700 Subject: RFR 8199193: jshell tool: Add support for preview features In-Reply-To: References: <175fb443-2ecd-f380-c695-6a9626462a1c@oracle.com> <5ADD9068.8030205@oracle.com> <058c4a46-b262-1385-35dd-140a019bf0c1@oracle.com> <715cc4be-1fd5-7728-bcbb-3940f893ebfd@oracle.com> Message-ID: <5ADE2C03.2050701@oracle.com> On 04/23/2018 11:23 AM, Robert Field wrote: > > > On 04/23/18 09:14, Jonathan Gibbons wrote: >> You need @modules. You may not need to export/open any internal >> API, but you certainly need the presence of certain modules. > > Thanks. > > Since tests are generally run with the full JDK, they do not verify > the correctness of the @modules tag. Do we have a way to > verify/generate the correct entries? Without testing, won't these > descend into meaningless cloning of @modules or missing @modules? It is desirable that we should be able to run all appropriate tests on small systems created with jlink. Shura is looking at ways to validate the @modules tag. It is generally obvious when not enough @modules are specified; it it somewhat harder to check whether or not any unnecessary modules have been specified. > > The tag spec: > > http://openjdk.java.net/jtreg/tag-spec.html > > Does not document :open, ... I'll update that copy. The copy in the jtreg repo has been updated. > > @modules [/[:]]+ > > Express a dependence on modules in the system being tested, and > optionally, on selected internal packages in some or all of those > modules. > > If no dependencies are specified explicitly, a default set of > dependencies will be read from the |modules| entry in test suite > configuration files . > > The dependencies will be ignored if the version of JDK used to run > the tests does not support the use of modules. Otherwise, a test > will not be run if the system being tested does not contain all of > the specified modules. All of the specified modules will be > present in the configuration when the test is run. > > A flag may be specified to indicate the desired access to a > specified package. > > Flag Access > /none/ The package should be exported, so that its public types > will be available for use by the test at compile time and run time. > |open| The package should be opened, so that its types will be > available for use by the test at run time using deep reflection. > |+open| The package should be both exported and opened, so that > its public types will be available for use by the test at compile > time and run time, and other types will be available at run time > using deep reflection. > > > > It is not documented, can it be assumed that dependencies of a module > are included automatically? :open and :+open are about opening internal packages. That is different from assuming anything about dependencies of a module. The Java Platform Module System will ensure that the dependencies of a module are included automatically, assuming they are available on the overall module path. > > -Robert > > >> >> -- Jon >> >> >> On 4/23/18 8:41 AM, Robert Field wrote: >>> On 04/23/18 00:51, Sundararajan Athijegannathan wrote: >>> >>>> * On the new ToolEnablePreviewTest: >>>> >>>> 1) do you need to build KullTesting for this test? >>>> 2) do you need those @module declarations for this test? Seems like >>>> this test stays within public APIs. >>> >>> All the tool tests clone, probably excess, @modules. And neither >>> @build is, I believe, needed. >>> >>> I've changed the header to just: >>> >>> /* >>> * @test >>> * @bug 8199193 >>> * @summary Tests for the --enable-preview option >>> * @run testng ToolEnablePreviewTest >>> */ >>> >>> >>> New webrev, with only this header changed: >>> >>> http://cr.openjdk.java.net/~rfield/8199193v1.webrev/ >>> >>> Thanks, >>> Robert >>> >>>> >>>> -Sundar >>>> >>>> On 23/04/18, 12:10 AM, Robert Field wrote: >>>>> Please review.... >>>>> >>>>> Bug: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8199193 >>>>> >>>>> Webrev: >>>>> >>>>> http://cr.openjdk.java.net/~rfield/8199193v0.webrev/ >>>>> >>>>> Thanks, >>>>> Robert >>>>> >>>>> >>> >> > From jonathan.gibbons at oracle.com Mon Apr 23 19:44:08 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 23 Apr 2018 12:44:08 -0700 Subject: RFR 8199193: jshell tool: Add support for preview features In-Reply-To: <5ADE0A88.6020303@oracle.com> References: <175fb443-2ecd-f380-c695-6a9626462a1c@oracle.com> <5ADD9068.8030205@oracle.com> <058c4a46-b262-1385-35dd-140a019bf0c1@oracle.com> <715cc4be-1fd5-7728-bcbb-3940f893ebfd@oracle.com> <5ADE0A88.6020303@oracle.com> Message-ID: Sundar, Yes, you only need specify an internal package if the source code of the test directly references that package (e.g. in an import statement) Informally, jtreg module-info command line @module m requires m; --add-module m m/p:open opens p; --add-opens m/p=ALL-UNNAMED m/p:+open exports p; --add-opens m/p=ALL-UNNAMED --add-exports m/p=ALL-UNNAMED -- Jon On 4/23/18 9:32 AM, Sundararajan Athijegannathan wrote: > To check the presence of jdk.jshell module? (to avoid running it when > that module is not present?). Even then we don't need it in the form > with internal package names, right? > > @modules jdk.jshell ? > > -Sundar > > On 23/04/18, 9:14 AM, Jonathan Gibbons wrote: >> You need @modules.??? You may not need to export/open any internal >> API, but you certainly need the presence of certain modules. >> >> -- Jon >> >> >> On 4/23/18 8:41 AM, Robert Field wrote: >>> On 04/23/18 00:51, Sundararajan Athijegannathan wrote: >>> >>>> * On the new ToolEnablePreviewTest: >>>> >>>> 1) do you need to build KullTesting for this test? >>>> 2) do you need those @module declarations for this test? Seems like >>>> this test stays within public APIs. >>> >>> All the tool tests clone, probably excess, @modules.? And neither >>> @build is, I believe, needed. >>> >>> I've changed the header to just: >>> >>> ?? /* >>> ???? * @test >>> ???? * @bug 8199193 >>> ???? * @summary Tests for the --enable-preview option >>> ???? * @run testng ToolEnablePreviewTest >>> ???? */ >>> >>> >>> New webrev, with only this header changed: >>> >>> ??? http://cr.openjdk.java.net/~rfield/8199193v1.webrev/ >>> >>> Thanks, >>> Robert >>> >>>> >>>> -Sundar >>>> >>>> On 23/04/18, 12:10 AM, Robert Field wrote: >>>>> Please review.... >>>>> >>>>> Bug: >>>>> >>>>> ??? https://bugs.openjdk.java.net/browse/JDK-8199193 >>>>> >>>>> Webrev: >>>>> >>>>> ??? http://cr.openjdk.java.net/~rfield/8199193v0.webrev/ >>>>> >>>>> Thanks, >>>>> Robert >>>>> >>>>> >>> >> From jan.lahoda at oracle.com Wed Apr 25 11:50:06 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 25 Apr 2018 13:50:06 +0200 Subject: RFR: JDK-8202105: jshell tool: on exiting, terminal echo is disabled Message-ID: <5AE06B6E.2060902@oracle.com> Hi, Under: https://bugs.openjdk.java.net/browse/JDK-8194750 j.i.Console was changed to capture the state of the terminal echo at creation time, and to restore it on shutdown. That is problematic at least in jshell, where the terminal is already in the raw mode when j.i.Console is created, and so "echo disabled" is recorded there. So even though jshell itself sets the terminal into the original mode when it terminates, the shutdown hook in j.i.Console, which is run later, sets the echo to off even if it was enabled before the VM started. My understanding is that the shutdown hook is only needed in case the VM goes down while readPassword is running. So I tried to change the shutdown hook to only work while readPassword is running. Bug: https://bugs.openjdk.java.net/browse/JDK-8202105 Webrev: http://cr.openjdk.java.net/~jlahoda/8202105/webrev.00/ What do you think? Thanks, Jan From mvala at redhat.com Thu Apr 26 07:01:09 2018 From: mvala at redhat.com (Michal Vala) Date: Thu, 26 Apr 2018 09:01:09 +0200 Subject: JDK-8199912 - jshell /open URL Message-ID: <0b273d84-e940-c889-604e-8d0c406134a5@redhat.com> Hi, I've been implementing jshell function to open scripts from url - JDK-8199912. Here's the rough working implementation: https://michalvala.fedorapeople.org/webrevs/JDK-8199912/webrev.00/ Few questions: 1] Is this requirement still valid? 2] Is dependency on java.net.http module ok? 3] Is there any better way how to detect http URL? This is ugly, but I haven't find any better example inside jdk. 4] Any better way how to handle http response status? -- Michal Vala OpenJDK QE Red Hat Czech From sormuras at gmail.com Thu Apr 26 07:31:16 2018 From: sormuras at gmail.com (Christian Stein) Date: Thu, 26 Apr 2018 09:31:16 +0200 Subject: JDK-8199912 - jshell /open URL In-Reply-To: <0b273d84-e940-c889-604e-8d0c406134a5@redhat.com> References: <0b273d84-e940-c889-604e-8d0c406134a5@redhat.com> Message-ID: Hi Michal, 1] I hope so! :) 2] Would a simple `java.nio.Files.copy()` using `java.net.URL`/`openStream()` suffice? try (var stream = new URL(fileUrl).openStream()) { Files.copy(stream, target); } Or a `stream.transferTo(target)` where `target` is piped into the `Scanner` instance. This would by-pass the dependency to `java.net.http`. 3] Mh, try to create a URI/URL and catch `URISyntaxException` and friends? 4] When using the `URL.openStream` + `transferTo` methods all http responses are encapsulated in `IOExceptions`. While typing this response, one could refactor the existing `runFile(...)` method to only support URIs, local files are just a special case using the `file://` protocol. Cheers, Christian On Thu, Apr 26, 2018 at 9:01 AM, Michal Vala wrote: > Hi, > I've been implementing jshell function to open scripts from url - > JDK-8199912. > > Here's the rough working implementation: https://michalvala.fedorapeopl > e.org/webrevs/JDK-8199912/webrev.00/ > > Few questions: > > 1] Is this requirement still valid? > 2] Is dependency on java.net.http module ok? > 3] Is there any better way how to detect http URL? This is ugly, but I > haven't find any better example inside jdk. > 4] Any better way how to handle http response status? > > > > -- > Michal Vala > OpenJDK QE > Red Hat Czech > From mvala at redhat.com Thu Apr 26 13:23:07 2018 From: mvala at redhat.com (Michal Vala) Date: Thu, 26 Apr 2018 15:23:07 +0200 Subject: JDK-8199912 - jshell /open URL In-Reply-To: References: <0b273d84-e940-c889-604e-8d0c406134a5@redhat.com> Message-ID: <50d63106-1ca5-1d70-ddd6-56feac3254e5@redhat.com> Hi Christian, thanks for comments. Updated webrev: https://michalvala.fedorapeople.org/webrevs/JDK-8199912/webrev.01/ I replaced http request with passing proper source to Scanner. The order of if condition is by probability of the hit. I'm assuming that simple local file path is the most common option, then resource as it's used at the start of the jshell and is cheaper than url request, which is last. I've added also few testcases. Thoughts? On 04/26/2018 09:31 AM, Christian Stein wrote: > Hi Michal, > > 1] I hope so! :) > > 2] Would a simple `java.nio.Files.copy()` using > `java.net.URL`/`openStream()` suffice? > > try (var stream = new URL(fileUrl).openStream()) { > Files.copy(stream, target); > } > > Or a `stream.transferTo(target)` where `target` is piped into the `Scanner` > instance. > This would by-pass the dependency to `java.net.http`. > > 3] Mh, try to create a URI/URL and catch `URISyntaxException` and friends? > > 4] When using the `URL.openStream` + `transferTo` methods all http responses > are encapsulated in `IOExceptions`. > > While typing this response, one could refactor the existing `runFile(...)` > method > to only support URIs, local files are just a special case using the > `file://` protocol. > > Cheers, > Christian > > > > On Thu, Apr 26, 2018 at 9:01 AM, Michal Vala wrote: > >> Hi, >> I've been implementing jshell function to open scripts from url - >> JDK-8199912. >> >> Here's the rough working implementation: https://michalvala.fedorapeopl >> e.org/webrevs/JDK-8199912/webrev.00/ >> >> Few questions: >> >> 1] Is this requirement still valid? >> 2] Is dependency on java.net.http module ok? >> 3] Is there any better way how to detect http URL? This is ugly, but I >> haven't find any better example inside jdk. >> 4] Any better way how to handle http response status? >> >> >> >> -- >> Michal Vala >> OpenJDK QE >> Red Hat Czech >> > -- Michal Vala OpenJDK QE Red Hat Czech From mvala at redhat.com Thu Apr 26 13:32:46 2018 From: mvala at redhat.com (Michal Vala) Date: Thu, 26 Apr 2018 15:32:46 +0200 Subject: JShell runFile does not properly close the Scanner Message-ID: <8a82fdbd-423d-8bd7-53f7-20f06d3d7bdc@redhat.com> Hi, while I've been playing with opening url in jshell, I've noticed that Scanner that goes into run(...) at JShellTool#runFile(...) is not properly closed. See following patch: diff -r 4745598b307f src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java --- a/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java Thu Apr 26 11:56:24 2018 +0200 +++ b/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java Thu Apr 26 15:27:13 2018 +0200 @@ -3005,7 +3005,9 @@ : new FileReader(path.toString()) ); } - run(new ScannerIOContext(scanner)); + try (var scannerIOContext = new ScannerIOContext(scanner)) { + run(scannerIOContext); + } return true; } catch (FileNotFoundException e) { errormsg("jshell.err.file.not.found", context, filename, e.getMessage()); thoughts? -- Michal Vala OpenJDK QE Red Hat Czech From sormuras at gmail.com Fri Apr 27 19:10:55 2018 From: sormuras at gmail.com (Christian Stein) Date: Fri, 27 Apr 2018 19:10:55 +0000 Subject: JDK-8199912 - jshell /open URL In-Reply-To: <50d63106-1ca5-1d70-ddd6-56feac3254e5@redhat.com> References: <0b273d84-e940-c889-604e-8d0c406134a5@redhat.com> <50d63106-1ca5-1d70-ddd6-56feac3254e5@redhat.com> Message-ID: Looks good to me. On Thu, Apr 26, 2018 at 3:23 PM Michal Vala wrote: > Hi Christian, > > thanks for comments. > Updated webrev: > https://michalvala.fedorapeople.org/webrevs/JDK-8199912/webrev.01/ > > I replaced http request with passing proper source to Scanner. The order > of if > condition is by probability of the hit. I'm assuming that simple local > file path > is the most common option, then resource as it's used at the start of the > jshell > and is cheaper than url request, which is last. > > I've added also few testcases. > > Thoughts? > > On 04/26/2018 09:31 AM, Christian Stein wrote: > > Hi Michal, > > > > 1] I hope so! :) > > > > 2] Would a simple `java.nio.Files.copy()` using > > `java.net.URL`/`openStream()` suffice? > > > > try (var stream = new URL(fileUrl).openStream()) { > > Files.copy(stream, target); > > } > > > > Or a `stream.transferTo(target)` where `target` is piped into the > `Scanner` > > instance. > > This would by-pass the dependency to `java.net.http`. > > > > 3] Mh, try to create a URI/URL and catch `URISyntaxException` and > friends? > > > > 4] When using the `URL.openStream` + `transferTo` methods all http > responses > > are encapsulated in `IOExceptions`. > > > > While typing this response, one could refactor the existing > `runFile(...)` > > method > > to only support URIs, local files are just a special case using the > > `file://` protocol. > > > > Cheers, > > Christian > > > > > > > > On Thu, Apr 26, 2018 at 9:01 AM, Michal Vala wrote: > > > >> Hi, > >> I've been implementing jshell function to open scripts from url - > >> JDK-8199912. > >> > >> Here's the rough working implementation: https://michalvala.fedorapeopl > >> e.org/webrevs/JDK-8199912/webrev.00/ > >> > >> Few questions: > >> > >> 1] Is this requirement still valid? > >> 2] Is dependency on java.net.http module ok? > >> 3] Is there any better way how to detect http URL? This is ugly, but I > >> haven't find any better example inside jdk. > >> 4] Any better way how to handle http response status? > >> > >> > >> > >> -- > >> Michal Vala > >> OpenJDK QE > >> Red Hat Czech > >> > > > > -- > Michal Vala > OpenJDK QE > Red Hat Czech > From robert.field at oracle.com Fri Apr 27 19:45:46 2018 From: robert.field at oracle.com (Robert Field) Date: Fri, 27 Apr 2018 12:45:46 -0700 Subject: JDK-8199912 - jshell /open URL In-Reply-To: References: <0b273d84-e940-c889-604e-8d0c406134a5@redhat.com> <50d63106-1ca5-1d70-ddd6-56feac3254e5@redhat.com> Message-ID: Thank you Michal and Christian! I'll take it from here (with the runFile fix rolled in). -Robert On 04/27/18 12:10, Christian Stein wrote: > Looks good to me. > > On Thu, Apr 26, 2018 at 3:23 PM Michal Vala wrote: > >> Hi Christian, >> >> thanks for comments. >> Updated webrev: >> https://michalvala.fedorapeople.org/webrevs/JDK-8199912/webrev.01/ >> >> I replaced http request with passing proper source to Scanner. The order >> of if >> condition is by probability of the hit. I'm assuming that simple local >> file path >> is the most common option, then resource as it's used at the start of the >> jshell >> and is cheaper than url request, which is last. >> >> I've added also few testcases. >> >> Thoughts? >> >> On 04/26/2018 09:31 AM, Christian Stein wrote: >>> Hi Michal, >>> >>> 1] I hope so! :) >>> >>> 2] Would a simple `java.nio.Files.copy()` using >>> `java.net.URL`/`openStream()` suffice? >>> >>> try (var stream = new URL(fileUrl).openStream()) { >>> Files.copy(stream, target); >>> } >>> >>> Or a `stream.transferTo(target)` where `target` is piped into the >> `Scanner` >>> instance. >>> This would by-pass the dependency to `java.net.http`. >>> >>> 3] Mh, try to create a URI/URL and catch `URISyntaxException` and >> friends? >>> 4] When using the `URL.openStream` + `transferTo` methods all http >> responses >>> are encapsulated in `IOExceptions`. >>> >>> While typing this response, one could refactor the existing >> `runFile(...)` >>> method >>> to only support URIs, local files are just a special case using the >>> `file://` protocol. >>> >>> Cheers, >>> Christian >>> >>> >>> >>> On Thu, Apr 26, 2018 at 9:01 AM, Michal Vala wrote: >>> >>>> Hi, >>>> I've been implementing jshell function to open scripts from url - >>>> JDK-8199912. >>>> >>>> Here's the rough working implementation: https://michalvala.fedorapeopl >>>> e.org/webrevs/JDK-8199912/webrev.00/ >>>> >>>> Few questions: >>>> >>>> 1] Is this requirement still valid? >>>> 2] Is dependency on java.net.http module ok? >>>> 3] Is there any better way how to detect http URL? This is ugly, but I >>>> haven't find any better example inside jdk. >>>> 4] Any better way how to handle http response status? >>>> >>>> >>>> >>>> -- >>>> Michal Vala >>>> OpenJDK QE >>>> Red Hat Czech >>>> >> -- >> Michal Vala >> OpenJDK QE >> Red Hat Czech >> From mvala at redhat.com Sat Apr 28 03:17:59 2018 From: mvala at redhat.com (Michal Vala) Date: Sat, 28 Apr 2018 05:17:59 +0200 Subject: JDK-8199912 - jshell /open URL In-Reply-To: References: <0b273d84-e940-c889-604e-8d0c406134a5@redhat.com> <50d63106-1ca5-1d70-ddd6-56feac3254e5@redhat.com> Message-ID: <9633ffec-440c-bdd0-56da-a73b7dc09190@redhat.com> Thanks Robert. Do you mean this one http://mail.openjdk.java.net/pipermail/kulla-dev/2018-April/002268.html ? I thought it should go separately under new bug id. Once JDK-8199912 is pushed, I'll update the other one, because there will be line mismatch. Anyway, I would like to ask for sponsorship. On 04/27/2018 09:45 PM, Robert Field wrote: > Thank you Michal and Christian! > > I'll take it from here (with the runFile fix rolled in). > > -Robert > > > On 04/27/18 12:10, Christian Stein wrote: >> Looks good to me. >> >> On Thu, Apr 26, 2018 at 3:23 PM Michal Vala wrote: >> >>> Hi Christian, >>> >>> thanks for comments. >>> Updated webrev: >>> https://michalvala.fedorapeople.org/webrevs/JDK-8199912/webrev.01/ >>> >>> I replaced http request with passing proper source to Scanner. The order >>> of if >>> condition is by probability of the hit. I'm assuming that simple local >>> file path >>> is the most common option, then resource as it's used at the start of the >>> jshell >>> and is cheaper than url request, which is last. >>> >>> I've added also few testcases. >>> >>> Thoughts? >>> >>> On 04/26/2018 09:31 AM, Christian Stein wrote: >>>> Hi Michal, >>>> >>>> 1] I hope so! :) >>>> >>>> 2] Would a simple `java.nio.Files.copy()` using >>>> `java.net.URL`/`openStream()` suffice? >>>> >>>> ??? try (var stream = new URL(fileUrl).openStream()) { >>>> ????? Files.copy(stream, target); >>>> ??? } >>>> >>>> Or a `stream.transferTo(target)` where `target` is piped into the >>> `Scanner` >>>> instance. >>>> This would by-pass the dependency to `java.net.http`. >>>> >>>> 3] Mh, try to create a URI/URL and catch `URISyntaxException` and >>> friends? >>>> 4] When using the `URL.openStream` + `transferTo` methods all http >>> responses >>>> are encapsulated in `IOExceptions`. >>>> >>>> While typing this response, one could refactor the existing >>> `runFile(...)` >>>> method >>>> to only support URIs, local files are just a special case using the >>>> `file://` protocol. >>>> >>>> Cheers, >>>> Christian >>>> >>>> >>>> >>>> On Thu, Apr 26, 2018 at 9:01 AM, Michal Vala wrote: >>>> >>>>> Hi, >>>>> I've been implementing jshell function to open scripts from url - >>>>> JDK-8199912. >>>>> >>>>> Here's the rough working implementation: https://michalvala.fedorapeopl >>>>> e.org/webrevs/JDK-8199912/webrev.00/ >>>>> >>>>> Few questions: >>>>> >>>>> 1] Is this requirement still valid? >>>>> 2] Is dependency on java.net.http module ok? >>>>> 3] Is there any better way how to detect http URL? This is ugly, but I >>>>> haven't find any better example inside jdk. >>>>> 4] Any better way how to handle http response status? >>>>> >>>>> >>>>> >>>>> -- >>>>> Michal Vala >>>>> OpenJDK QE >>>>> Red Hat Czech >>>>> >>> -- >>> Michal Vala >>> OpenJDK QE >>> Red Hat Czech >>> > -- Michal Vala OpenJDK QE Red Hat Czech From robert.field at oracle.com Mon Apr 30 18:45:29 2018 From: robert.field at oracle.com (Robert Field) Date: Mon, 30 Apr 2018 11:45:29 -0700 Subject: 8199912: jshell tool: /open from URI Message-ID: Please review the following, contributed by: ? ? ? ??? Michal Vala Thank you Christian Stein for your comments. Bug: ??? https://bugs.openjdk.java.net/browse/JDK-8199912 Webrev: ??? http://cr.openjdk.java.net/~rfield/8199912v1.webrev/ -Robert From sormuras at gmail.com Mon Apr 30 18:50:26 2018 From: sormuras at gmail.com (Christian Stein) Date: Mon, 30 Apr 2018 18:50:26 +0000 Subject: 8199912: jshell tool: /open from URI In-Reply-To: References: Message-ID: Looks still good to me. Looking forward to jdk-11-ea+12 or ...+13 then. :) On Mon, Apr 30, 2018 at 8:45 PM Robert Field wrote: > Please review the following, contributed by: > > Michal Vala > > Thank you Christian Stein for your comments. > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8199912 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8199912v1.webrev/ > > > -Robert > > >