From jan.lahoda at oracle.com Mon May 2 06:55:28 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 2 May 2016 08:55:28 +0200 Subject: RFR 8147984: WindowsTerminal should support function keys In-Reply-To: References: <56A21578.5080105@oracle.com> Message-ID: <5726F9E0.4000801@oracle.com> Hi Stuart, Thanks for the comments and the link! A webrev which includes the link is here: http://cr.openjdk.java.net/~jlahoda/8147984/webrev.01/ Delta webrev to the last iteration is here: http://cr.openjdk.java.net/~jlahoda/8147984/webrev.01/delta/webrev Thanks, Jan On 29.4.2016 23:49, Stuart Marks wrote: > Hi Jan, > > I finally got a chance to take a look at this. The change looks fine. > > It would be nice to have a reference to where the escape sequences are > documented. There are links to the Windows VK_ codes there, which is > great. But there's no reference for the escape sequences that each > keypress is mapped to, e.g. F4 is "ESC O S", and F5 is "ESC [ 1 5 ~" > (and what happened to "ESC [ 1 6 ~"??) > > I did some searching, and it seems really hard to find a definitive > reference. Perhaps the best reference is "XTerm Control Sequences" [1] > which seems to document xterm pretty thoroughly, which is what everybody > seems to follow nowadays. It even looks like it's being kept up to date > (last modified 2016-02-21). > > Anyway I'd suggest adding a comment with a reference to this document. > > As a cross-check, these sequences match what my Mac's Terminal.app > emits, at least for unshifted F1-F12. (The Terminal app was probably > copied from xterm.) > > Thanks, > > s'marks > > > [1] http://invisible-island.net/xterm/ctlseqs/ctlseqs.html > > > On 1/22/16 3:41 AM, Jan Lahoda wrote: >> Hello, >> >> I'd like to enhance the WindowsTerminal in jdk.internal.le with >> function keys >> handling. The intent is so that jshell can bind actions for shortcuts >> including >> function keys. >> >> The patch for adding the function keys support is here: >> http://cr.openjdk.java.net/~jlahoda/8147984/webrev.00/ >> >> An example of a feature that uses/may use this support is here: >> http://mail.openjdk.java.net/pipermail/kulla-dev/2016-January/001226.html >> >> Any comments are welcome! >> >> Thanks, >> Jan From jan.lahoda at oracle.com Mon May 2 08:15:13 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 2 May 2016 10:15:13 +0200 Subject: RFR 8139832: JShell API: Diag constructor should not be exposed and fix typo In-Reply-To: <57224AD8.1060801@oracle.com> References: <57224AD8.1060801@oracle.com> Message-ID: <57270C91.7090708@oracle.com> Seems OK to me. Jan On 28.4.2016 19:39, Robert Field wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8139832 > > Webrev: > http://cr.openjdk.java.net/~rfield/8139832.webrev/ > > -Robert > From stuart.marks at oracle.com Mon May 2 18:31:16 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 2 May 2016 11:31:16 -0700 Subject: RFR 8147984: WindowsTerminal should support function keys In-Reply-To: <5726F9E0.4000801@oracle.com> References: <56A21578.5080105@oracle.com> <5726F9E0.4000801@oracle.com> Message-ID: <8e47a023-b313-d40e-7ed7-c91428f2d700@oracle.com> Hi Jan, Thanks for the update. Including the link is fine, but I'm a bit suspicious of the durability of that website -- it appears to be the personal website of the current maintainer. Who knows if it'll be around in a couple years. I'd suggest including in the comment the official title of the document, "XTerm Control Sequences" along with a mention of the authors (Moy, Gildea, Dickey) so that if the link were to go bad, it would be possible to do a web search to find some version of the document. No need for an updated webrev. Thanks, s'marks On 5/1/16 11:55 PM, Jan Lahoda wrote: > Hi Stuart, > > Thanks for the comments and the link! > > A webrev which includes the link is here: > http://cr.openjdk.java.net/~jlahoda/8147984/webrev.01/ > > Delta webrev to the last iteration is here: > http://cr.openjdk.java.net/~jlahoda/8147984/webrev.01/delta/webrev > > Thanks, > Jan > > On 29.4.2016 23:49, Stuart Marks wrote: >> Hi Jan, >> >> I finally got a chance to take a look at this. The change looks fine. >> >> It would be nice to have a reference to where the escape sequences are >> documented. There are links to the Windows VK_ codes there, which is >> great. But there's no reference for the escape sequences that each >> keypress is mapped to, e.g. F4 is "ESC O S", and F5 is "ESC [ 1 5 ~" >> (and what happened to "ESC [ 1 6 ~"??) >> >> I did some searching, and it seems really hard to find a definitive >> reference. Perhaps the best reference is "XTerm Control Sequences" [1] >> which seems to document xterm pretty thoroughly, which is what everybody >> seems to follow nowadays. It even looks like it's being kept up to date >> (last modified 2016-02-21). >> >> Anyway I'd suggest adding a comment with a reference to this document. >> >> As a cross-check, these sequences match what my Mac's Terminal.app >> emits, at least for unshifted F1-F12. (The Terminal app was probably >> copied from xterm.) >> >> Thanks, >> >> s'marks >> >> >> [1] http://invisible-island.net/xterm/ctlseqs/ctlseqs.html >> >> >> On 1/22/16 3:41 AM, Jan Lahoda wrote: >>> Hello, >>> >>> I'd like to enhance the WindowsTerminal in jdk.internal.le with >>> function keys >>> handling. The intent is so that jshell can bind actions for shortcuts >>> including >>> function keys. >>> >>> The patch for adding the function keys support is here: >>> http://cr.openjdk.java.net/~jlahoda/8147984/webrev.00/ >>> >>> An example of a feature that uses/may use this support is here: >>> http://mail.openjdk.java.net/pipermail/kulla-dev/2016-January/001226.html >>> >>> Any comments are welcome! >>> >>> Thanks, >>> Jan From weijun.wang at oracle.com Wed May 4 04:32:47 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 4 May 2016 12:32:47 +0800 Subject: jshell depends on some windows registry? Message-ID: <2127fcfc-f3e5-3dd2-1513-40a0ac4d737c@oracle.com> I copied the images to my own computer (without running any installer) and running jshell in jdk9/b116 shows this $ jshell May 04, 2016 12:30:25 PM java.util.prefs.WindowsPreferences WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5. | Welcome to JShell -- Version 9-ea | For an introduction type: /help intro jshell> Then if I enter anything, it just hangs forever. Must I install it? What if I am building my own jdk? Thanks Max From robert.field at oracle.com Wed May 4 04:48:24 2016 From: robert.field at oracle.com (Robert Field) Date: Tue, 3 May 2016 21:48:24 -0700 Subject: jshell depends on some windows registry? In-Reply-To: <2127fcfc-f3e5-3dd2-1513-40a0ac4d737c@oracle.com> References: <2127fcfc-f3e5-3dd2-1513-40a0ac4d737c@oracle.com> Message-ID: <57297F18.7060902@oracle.com> Hi Max, There is no concept of "installing" jshell beyond having JDK9 installed. The jshell tool uses the Java Preferences API, which seems to be failing in this case -- the Preferences API uses platform specific functionality to save/restore preferences. I don't know the specifics of how it works on different platforms -- anybody have an idea what is going on here? We may need to file a Preferences bug. Just to be sure everything is lined up right, can you do: java -fullversion jshell -fullversion Thanks, Robert On 05/03/2016 09:32 PM, Weijun Wang wrote: > I copied the images to my own computer (without running any installer) > and running jshell in jdk9/b116 shows this > > $ jshell > May 04, 2016 12:30:25 PM java.util.prefs.WindowsPreferences > WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs > at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5. > | Welcome to JShell -- Version 9-ea > | For an introduction type: /help intro > > jshell> > > Then if I enter anything, it just hangs forever. > > Must I install it? What if I am building my own jdk? > > Thanks > Max From weijun.wang at oracle.com Wed May 4 05:59:14 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 4 May 2016 13:59:14 +0800 Subject: Or terminal? (was Re: jshell depends on some windows registry?) In-Reply-To: <57297F18.7060902@oracle.com> References: <2127fcfc-f3e5-3dd2-1513-40a0ac4d737c@oracle.com> <57297F18.7060902@oracle.com> Message-ID: <67254a00-b014-a1e2-be4d-3694de930d95@oracle.com> First, an quite important observation. The jshell tool works fine in a Windows Command Prompt window but not in a Cygwin terminal. Precisely: 1. Cygwin Terminal, i.e. its mintty terminal: Not working. 2. Windows cmd.exe under C:> prompt: Working. 3. Windows cmd.exe and then call c:\cygwin\cygwin.bat: Still working. So maybe this is not a registry issue but a terminal one. Replies to your questions inline below. On 5/4/2016 12:48, Robert Field wrote: > Hi Max, > > There is no concept of "installing" jshell beyond having JDK9 installed. I meant installing the JDK, I heard it add some registry entries but not sure what they are. > > The jshell tool uses the Java Preferences API, which seems to be failing > in this case -- the Preferences API uses platform specific functionality > to save/restore preferences. > > I don't know the specifics of how it works on different platforms -- > anybody have an idea what is going on here? We may need to file a > Preferences bug. > > Just to be sure everything is lined up right, can you do: > > java -fullversion java full version "9-ea+116" > > jshell -fullversion May 04, 2016 1:44:11 PM java.util.prefs.WindowsPreferences WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5. jshell 9-ea+116 Thanks Max > > Thanks, > Robert > > > On 05/03/2016 09:32 PM, Weijun Wang wrote: >> I copied the images to my own computer (without running any installer) >> and running jshell in jdk9/b116 shows this >> >> $ jshell >> May 04, 2016 12:30:25 PM java.util.prefs.WindowsPreferences >> WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs >> at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5. >> | Welcome to JShell -- Version 9-ea >> | For an introduction type: /help intro >> >> jshell> >> >> Then if I enter anything, it just hangs forever. >> >> Must I install it? What if I am building my own jdk? >> >> Thanks >> Max > From Roger.Riggs at Oracle.com Wed May 4 14:13:58 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 4 May 2016 10:13:58 -0400 Subject: jshell depends on some windows registry? In-Reply-To: <57297F18.7060902@oracle.com> References: <2127fcfc-f3e5-3dd2-1513-40a0ac4d737c@oracle.com> <57297F18.7060902@oracle.com> Message-ID: <45202843-0ec5-e723-d51d-6260f7122736@Oracle.com> Hi Robert, Is there any alternative to the Preferences API. What state is stored in it? It would be better not to have too many dependencies in JShell. Thanks, Roger On 5/4/2016 12:48 AM, Robert Field wrote: > Hi Max, > > There is no concept of "installing" jshell beyond having JDK9 installed. > > The jshell tool uses the Java Preferences API, which seems to be > failing in this case -- the Preferences API uses platform specific > functionality to save/restore preferences. > > I don't know the specifics of how it works on different platforms -- > anybody have an idea what is going on here? We may need to file a > Preferences bug. > > Just to be sure everything is lined up right, can you do: > > java -fullversion > > jshell -fullversion > > Thanks, > Robert > > > On 05/03/2016 09:32 PM, Weijun Wang wrote: >> I copied the images to my own computer (without running any >> installer) and running jshell in jdk9/b116 shows this >> >> $ jshell >> May 04, 2016 12:30:25 PM java.util.prefs.WindowsPreferences >> WARNING: Could not open/create prefs root node >> Software\JavaSoft\Prefs at root 0x80000002. Windows >> RegCreateKeyEx(...) returned error code 5. >> | Welcome to JShell -- Version 9-ea >> | For an introduction type: /help intro >> >> jshell> >> >> Then if I enter anything, it just hangs forever. >> >> Must I install it? What if I am building my own jdk? >> >> Thanks >> Max > From jan.lahoda at oracle.com Wed May 4 14:17:32 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 4 May 2016 16:17:32 +0200 Subject: Or terminal? (was Re: jshell depends on some windows registry?) In-Reply-To: <67254a00-b014-a1e2-be4d-3694de930d95@oracle.com> References: <2127fcfc-f3e5-3dd2-1513-40a0ac4d737c@oracle.com> <57297F18.7060902@oracle.com> <67254a00-b014-a1e2-be4d-3694de930d95@oracle.com> Message-ID: <572A047C.5080200@oracle.com> Yes, running jshell in the Cygwin Terminal does not (yet) work. (It tries to talk to it as if it was the command prompt window, which does not work well.) Jan On 4.5.2016 07:59, Weijun Wang wrote: > First, an quite important observation. The jshell tool works fine in a > Windows Command Prompt window but not in a Cygwin terminal. Precisely: > > 1. Cygwin Terminal, i.e. its mintty terminal: Not working. > > 2. Windows cmd.exe under C:> prompt: Working. > > 3. Windows cmd.exe and then call c:\cygwin\cygwin.bat: Still working. > > So maybe this is not a registry issue but a terminal one. > > Replies to your questions inline below. > > On 5/4/2016 12:48, Robert Field wrote: >> Hi Max, >> >> There is no concept of "installing" jshell beyond having JDK9 installed. > > I meant installing the JDK, I heard it add some registry entries but not > sure what they are. > >> >> The jshell tool uses the Java Preferences API, which seems to be failing >> in this case -- the Preferences API uses platform specific functionality >> to save/restore preferences. >> >> I don't know the specifics of how it works on different platforms -- >> anybody have an idea what is going on here? We may need to file a >> Preferences bug. >> >> Just to be sure everything is lined up right, can you do: >> >> java -fullversion > > java full version "9-ea+116" > >> >> jshell -fullversion > > May 04, 2016 1:44:11 PM java.util.prefs.WindowsPreferences > WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs > at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5. > jshell 9-ea+116 > > Thanks > Max > >> >> Thanks, >> Robert >> >> >> On 05/03/2016 09:32 PM, Weijun Wang wrote: >>> I copied the images to my own computer (without running any installer) >>> and running jshell in jdk9/b116 shows this >>> >>> $ jshell >>> May 04, 2016 12:30:25 PM java.util.prefs.WindowsPreferences >>> WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs >>> at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5. >>> | Welcome to JShell -- Version 9-ea >>> | For an introduction type: /help intro >>> >>> jshell> >>> >>> Then if I enter anything, it just hangs forever. >>> >>> Must I install it? What if I am building my own jdk? >>> >>> Thanks >>> Max >> From robert.field at oracle.com Wed May 4 17:15:16 2016 From: robert.field at oracle.com (Robert Field) Date: Wed, 04 May 2016 10:15:16 -0700 Subject: jshell depends on some windows registry? In-Reply-To: <45202843-0ec5-e723-d51d-6260f7122736@Oracle.com> References: <2127fcfc-f3e5-3dd2-1513-40a0ac4d737c@oracle.com> <57297F18.7060902@oracle.com> <45202843-0ec5-e723-d51d-6260f7122736@Oracle.com> Message-ID: <1547cc43ca0.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> We need to be able to store and retrieve info between JShell tool sessions. Perhaps we should have a backup of Preferences fails? -Robert On May 4, 2016 7:14:07 AM Roger Riggs wrote: > Hi Robert, > > Is there any alternative to the Preferences API. What state is stored > in it? > > It would be better not to have too many dependencies in JShell. > > Thanks, Roger > > > On 5/4/2016 12:48 AM, Robert Field wrote: >> Hi Max, >> >> There is no concept of "installing" jshell beyond having JDK9 installed. >> >> The jshell tool uses the Java Preferences API, which seems to be >> failing in this case -- the Preferences API uses platform specific >> functionality to save/restore preferences. >> >> I don't know the specifics of how it works on different platforms -- >> anybody have an idea what is going on here? We may need to file a >> Preferences bug. >> >> Just to be sure everything is lined up right, can you do: >> >> java -fullversion >> >> jshell -fullversion >> >> Thanks, >> Robert >> >> >> On 05/03/2016 09:32 PM, Weijun Wang wrote: >>> I copied the images to my own computer (without running any >>> installer) and running jshell in jdk9/b116 shows this >>> >>> $ jshell >>> May 04, 2016 12:30:25 PM java.util.prefs.WindowsPreferences >>> WARNING: Could not open/create prefs root node >>> Software\JavaSoft\Prefs at root 0x80000002. Windows >>> RegCreateKeyEx(...) returned error code 5. >>> | Welcome to JShell -- Version 9-ea >>> | For an introduction type: /help intro >>> >>> jshell> >>> >>> Then if I enter anything, it just hangs forever. >>> >>> Must I install it? What if I am building my own jdk? >>> >>> Thanks >>> Max >> > From jan.lahoda at oracle.com Thu May 5 12:14:04 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 5 May 2016 14:14:04 +0200 Subject: RFR: 8153761: JShell: Completion -- Show parameter names if possible Message-ID: <572B390C.8020001@oracle.com> Hi, JBS: https://bugs.openjdk.java.net/browse/JDK-8153761 Webrev: http://cr.openjdk.java.net/~jlahoda/8153761/webrev.00/index.html Currently, when showing the synopsis of methods (Shift-), synthesised, not real, parameter names are shown. This patches improves that by: -reading the parameter names from the classfiles if they are available (by using "-XDsave-parameter-names=true") -storing parameter names when compiling user's snippets (by using "-parameters") -looking for src.zip in the JDK installation if the parameter names are not available in the classfiles, and reading the parameter names from the sources. Comments are welcome! Jan From joe.darcy at oracle.com Thu May 5 17:35:26 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 5 May 2016 10:35:26 -0700 Subject: JDK 9 RFR of JDK-8156158: Mark ToolLocaleMessageTest.java as intermittently failing, demote to tier 2 Message-ID: <0552bb6a-cf98-4e1d-2d5f-9be978eb1bcf@oracle.com> Hello, The test jdk/jshell/ToolLocaleMessageTest.java has been seen to intermittently fail (JDK-8154178). It should be marked accordingly and demoted from tier 1 to tier 2 until the reliability issues are resolved. Please review the patch below which does this. Thanks, -Joe diff -r d5ca3c84a004 test/TEST.groups --- a/test/TEST.groups Tue May 03 11:38:13 2016 +0100 +++ b/test/TEST.groups Thu May 05 10:34:58 2016 -0700 @@ -28,11 +28,13 @@ jdk \ lib \ tools \ - -jdk/jshell/ToolReloadTest.java + -jdk/jshell/ToolReloadTest.java \ + -jdk/jshell/ToolLocaleMessageTest.java # (Almost) no langtools tests are tier 2. tier2 = \ - jdk/jshell/ToolReloadTest.java + jdk/jshell/ToolReloadTest.java \ + jdk/jshell/ToolLocaleMessageTest.java # No langtools tests are tier 3 either. tier3 = diff -r d5ca3c84a004 test/jdk/jshell/ToolLocaleMessageTest.java --- a/test/jdk/jshell/ToolLocaleMessageTest.java Tue May 03 11:38:13 2016 +0100 +++ b/test/jdk/jshell/ToolLocaleMessageTest.java Thu May 05 10:34:58 2016 -0700 @@ -32,6 +32,7 @@ * jdk.jshell/jdk.internal.jshell.tool * @build KullaTesting TestingInputStream toolbox.ToolBox Compiler * @run testng ToolLocaleMessageTest + * @key intermittent */ import java.util.Locale; From robert.field at oracle.com Fri May 6 05:14:03 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 5 May 2016 22:14:03 -0700 Subject: RFR: 8153761: JShell: Completion -- Show parameter names if possible In-Reply-To: <572B390C.8020001@oracle.com> References: <572B390C.8020001@oracle.com> Message-ID: <572C281B.5000006@oracle.com> Looks good. I notice that the SourceCache initialization (including findSources()) gets run every time, even if all the real parameter names are in the classfile. I don't know how significant that is. -Robert On 05/05/2016 05:14 AM, Jan Lahoda wrote: > Hi, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8153761 > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8153761/webrev.00/index.html > > Currently, when showing the synopsis of methods (Shift-), > synthesised, not real, parameter names are shown. This patches > improves that by: > -reading the parameter names from the classfiles if they are available > (by using "-XDsave-parameter-names=true") > -storing parameter names when compiling user's snippets (by using > "-parameters") > -looking for src.zip in the JDK installation if the parameter names > are not available in the classfiles, and reading the parameter names > from the sources. > > Comments are welcome! > > Jan From jan.lahoda at oracle.com Mon May 9 17:07:07 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 9 May 2016 19:07:07 +0200 Subject: JDK 9 RFR of JDK-8156158: Mark ToolLocaleMessageTest.java as intermittently failing, demote to tier 2 In-Reply-To: <0552bb6a-cf98-4e1d-2d5f-9be978eb1bcf@oracle.com> References: <0552bb6a-cf98-4e1d-2d5f-9be978eb1bcf@oracle.com> Message-ID: <5730C3BB.1070100@oracle.com> Hi, Seems the @key line in ToolLocaleMessageTest.java may be indented wrong/differently that the other lines. With that double-checked and fixed if needed, I'm OK with the patch. Jan On 5.5.2016 19:35, joe darcy wrote: > Hello, > > The test > > jdk/jshell/ToolLocaleMessageTest.java > > has been seen to intermittently fail (JDK-8154178). It should be marked > accordingly and demoted from tier 1 to tier 2 until the reliability > issues are resolved. > > Please review the patch below which does this. > > Thanks, > > -Joe > > > diff -r d5ca3c84a004 test/TEST.groups > --- a/test/TEST.groups Tue May 03 11:38:13 2016 +0100 > +++ b/test/TEST.groups Thu May 05 10:34:58 2016 -0700 > @@ -28,11 +28,13 @@ > jdk \ > lib \ > tools \ > - -jdk/jshell/ToolReloadTest.java > + -jdk/jshell/ToolReloadTest.java \ > + -jdk/jshell/ToolLocaleMessageTest.java > > # (Almost) no langtools tests are tier 2. > tier2 = \ > - jdk/jshell/ToolReloadTest.java > + jdk/jshell/ToolReloadTest.java \ > + jdk/jshell/ToolLocaleMessageTest.java > > # No langtools tests are tier 3 either. > tier3 = > diff -r d5ca3c84a004 test/jdk/jshell/ToolLocaleMessageTest.java > --- a/test/jdk/jshell/ToolLocaleMessageTest.java Tue May 03 11:38:13 > 2016 +0100 > +++ b/test/jdk/jshell/ToolLocaleMessageTest.java Thu May 05 10:34:58 > 2016 -0700 > @@ -32,6 +32,7 @@ > * jdk.jshell/jdk.internal.jshell.tool > * @build KullaTesting TestingInputStream toolbox.ToolBox Compiler > * @run testng ToolLocaleMessageTest > + * @key intermittent > */ > > import java.util.Locale; > From jan.lahoda at oracle.com Mon May 9 19:39:56 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 9 May 2016 21:39:56 +0200 Subject: RFR: 8153761: JShell: Completion -- Show parameter names if possible In-Reply-To: <572C281B.5000006@oracle.com> References: <572B390C.8020001@oracle.com> <572C281B.5000006@oracle.com> Message-ID: <5730E78C.90900@oracle.com> On 6.5.2016 07:14, Robert Field wrote: > Looks good. Thanks. > > I notice that the SourceCache initialization (including findSources()) > gets run every time, even if all the real parameter names are in the > classfile. I don't know how significant that is. The result of findSources() should be cached, so it should be just the initialization of the file manager (caching the file manager would be troublesome, as there is no clear point when it could be closed). I hope the initialization shouldn't be a significant problem (in my measurements on my laptop, the first SourceCache initialization took 1-2ms, and the subsequent initializations took <1ms). Jan > > -Robert > > > On 05/05/2016 05:14 AM, Jan Lahoda wrote: >> Hi, >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8153761 >> >> Webrev: >> http://cr.openjdk.java.net/~jlahoda/8153761/webrev.00/index.html >> >> Currently, when showing the synopsis of methods (Shift-), >> synthesised, not real, parameter names are shown. This patches >> improves that by: >> -reading the parameter names from the classfiles if they are available >> (by using "-XDsave-parameter-names=true") >> -storing parameter names when compiling user's snippets (by using >> "-parameters") >> -looking for src.zip in the JDK installation if the parameter names >> are not available in the classfiles, and reading the parameter names >> from the sources. >> >> Comments are welcome! >> >> Jan > From robert.field at oracle.com Tue May 10 05:11:58 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 09 May 2016 22:11:58 -0700 Subject: RFR: 8153761: JShell: Completion -- Show parameter names if possible In-Reply-To: <5730E78C.90900@oracle.com> References: <572B390C.8020001@oracle.com> <572C281B.5000006@oracle.com> <5730E78C.90900@oracle.com> Message-ID: <15499142d48.2765.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Cool! On May 9, 2016 12:40:01 PM Jan Lahoda wrote: > On 6.5.2016 07:14, Robert Field wrote: >> Looks good. > > Thanks. > >> >> I notice that the SourceCache initialization (including findSources()) >> gets run every time, even if all the real parameter names are in the >> classfile. I don't know how significant that is. > > The result of findSources() should be cached, so it should be just the > initialization of the file manager (caching the file manager would be > troublesome, as there is no clear point when it could be closed). I hope > the initialization shouldn't be a significant problem (in my > measurements on my laptop, the first SourceCache initialization took > 1-2ms, and the subsequent initializations took <1ms). > > Jan > >> >> -Robert >> >> >> On 05/05/2016 05:14 AM, Jan Lahoda wrote: >>> Hi, >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8153761 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~jlahoda/8153761/webrev.00/index.html >>> >>> Currently, when showing the synopsis of methods (Shift-), >>> synthesised, not real, parameter names are shown. This patches >>> improves that by: >>> -reading the parameter names from the classfiles if they are available >>> (by using "-XDsave-parameter-names=true") >>> -storing parameter names when compiling user's snippets (by using >>> "-parameters") >>> -looking for src.zip in the JDK installation if the parameter names >>> are not available in the classfiles, and reading the parameter names >>> from the sources. >>> >>> Comments are welcome! >>> >>> Jan >> From robert.field at oracle.com Thu May 12 05:53:27 2016 From: robert.field at oracle.com (Robert Field) Date: Wed, 11 May 2016 22:53:27 -0700 Subject: RFR 8156101: JShell SPI: Provide a pluggable execution control SPI Message-ID: <57341A57.6090000@oracle.com> Please review the new Service Provider Interface for using alternate execution implements. Bug: https://bugs.openjdk.java.net/browse/JDK-8156101 Webrevs: http://cr.openjdk.java.net/~rfield/8156101v0_lang.webrev/ http://cr.openjdk.java.net/~rfield/8156101v0_ws.webrev/ Javadoc: http://cr.openjdk.java.net/~rfield/jshell_spi/ Note: The SPI is tested since it is used by the default JDI implementation (which has no special access). However, tests using an alternative execution engine will be included. Thanks, Robert From jan.lahoda at oracle.com Thu May 12 10:25:09 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 12 May 2016 12:25:09 +0200 Subject: RFR: 8133549: Generalize jshell's EditingHistory Message-ID: <57345A05.2060504@oracle.com> Hello, In jshell, there's a special history mode that is intended to aid with editing/re-entering multi-line snippets (EditingHistory). It works like this: when the user goes back through the history to the first line of a multi-line snippet, and enters/confirms that line, the history view is limited only to the given snippet. I.e. up and down arrows won't go through the whole history, but only the few lines of the given snippet. When the multi-line snippet is finished, the history is restored to the original full state. The proposal here is to generalize this history mode so that it can be used in jjs as well. For this, a new support class is added into jdk.internal.le, that implements this history. Also, ConsoleReader is extended to also accept actions as a Runnable instead of only ActionListener, so that the EditingHistory can add extra actions to jump by the whole snippets when going back in history. Bug: https://bugs.openjdk.java.net/browse/JDK-8133549 Webrev: jdk repository: http://cr.openjdk.java.net/~jlahoda/8133549/jdk/webrev.00/ langtools repository: http://cr.openjdk.java.net/~jlahoda/8133549/langtools/webrev.00/ nashorn repository: http://cr.openjdk.java.net/~jlahoda/8133549/nashorn/webrev.00/ Any comments are welcome! Thanks, Jan From sundararajan.athijegannathan at oracle.com Thu May 12 11:44:41 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 12 May 2016 17:14:41 +0530 Subject: RFR: 8133549: Generalize jshell's EditingHistory In-Reply-To: <57345A05.2060504@oracle.com> References: <57345A05.2060504@oracle.com> Message-ID: <5bc12b5b-f705-d840-832a-1511ef92fdcd@oracle.com> The nashorn and jdk repo changes look good to me. Thanks, -Sundar On 5/12/2016 3:55 PM, Jan Lahoda wrote: > Hello, > > In jshell, there's a special history mode that is intended to aid with > editing/re-entering multi-line snippets (EditingHistory). It works > like this: when the user goes back through the history to the first > line of a multi-line snippet, and enters/confirms that line, the > history view is limited only to the given snippet. I.e. up and down > arrows won't go through the whole history, but only the few lines of > the given snippet. When the multi-line snippet is finished, the > history is restored to the original full state. > > The proposal here is to generalize this history mode so that it can be > used in jjs as well. For this, a new support class is added into > jdk.internal.le, that implements this history. Also, ConsoleReader is > extended to also accept actions as a Runnable instead of only > ActionListener, so that the EditingHistory can add extra actions to > jump by the whole snippets when going back in history. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8133549 > > Webrev: > jdk repository: > http://cr.openjdk.java.net/~jlahoda/8133549/jdk/webrev.00/ > > langtools repository: > http://cr.openjdk.java.net/~jlahoda/8133549/langtools/webrev.00/ > > nashorn repository: > http://cr.openjdk.java.net/~jlahoda/8133549/nashorn/webrev.00/ > > Any comments are welcome! > > Thanks, > Jan From jonathan.gibbons at oracle.com Thu May 12 18:23:24 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 12 May 2016 11:23:24 -0700 Subject: file manager should be closed Message-ID: <5734CA1C.4000504@oracle.com> This is in SourceCodeAnalysisImpl.java. getStandardFileManager is defined to return a new instance each time it is called. Ideally, each such instance should be closed. This can be done by creating the file manager with try-wirth-resources, public SourceCache(AnalyzeTask originalTask) { this.originalTask = originalTask; List sources = findSources(); if (sources.iterator().hasNext()) { StandardJavaFileManager fm = compiler.getStandardFileManager(null, null, null); try { fm.setLocationFromPaths(StandardLocation.SOURCE_PATH, sources); } catch (IOException ex) { proc.debug(ex, "SourceCodeAnalysisImpl.SourceCache.(...)"); fm = null; } this.fm = fm; } else { //don't waste time if there are no sources this.fm = null; } } From jonathan.gibbons at oracle.com Thu May 12 18:26:51 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 12 May 2016 11:26:51 -0700 Subject: RFR: 8149843, 8150111 Two small changes to StandardJavaFileManager API In-Reply-To: <57349F94.6000002@oracle.com> References: <572D2752.3000607@oracle.com> <5733B1D1.7070304@oracle.com> <57349F94.6000002@oracle.com> Message-ID: <5734CAEB.4090706@oracle.com> After merging with the latest jdk9/dev bits, some additional minor changes are required in jdk.jshell, to avoid the use of Iterable. The most obvious change is simply to use List instead, as shown here. $ hg diff src/jdk.jshell diff -r c51b40933e0c src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java --- a/src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java Wed May 11 20:28:22 2016 +0000 +++ b/src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java Thu May 12 11:25:46 2016 -0700 @@ -1045,7 +1045,7 @@ public SourceCache(AnalyzeTask originalTask) { this.originalTask = originalTask; - Iterable sources = findSources(); + List sources = findSources(); if (sources.iterator().hasNext()) { StandardJavaFileManager fm = compiler.getStandardFileManager(null, null, null); try { @@ -1145,9 +1145,9 @@ } } - private Iterable availableSources; + private List availableSources; - private Iterable findSources() { + private List findSources() { if (availableSources != null) { return availableSources; } On 05/12/2016 08:21 AM, Jan Lahoda wrote: > Looks fine to me too. > > Jan > > On 12.5.2016 00:27, Vicente-Arturo Romero-Zaldivar wrote: >> approved, >> >> Thanks, >> Vicente >> >> On 05/06/2016 07:22 PM, Jonathan Gibbons wrote: >>> This is for two small changes to the StandardJavaFileManager API. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8149843 >>> StandardJavaFileManager should provide a way to get paths from strings >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8150111 >>> Need to change signature of >>> StandardJavaFileManager.setLocationFromPaths >>> >>> With these changes, all standard uses of Paths.get are replaced by >>> using >>> a user-provided function, defaulting to Paths::get. >>> >>> The exceptions are: >>> file names specified on the javac command line >>> file names used in some internal debugging/tracing features in >>> javac >>> file names used in sjavac >>> >>> Combined specdiff: http://cr.openjdk.java.net/~jjg/8149843/specdiff.00/ >>> Combined webrev: http://cr.openjdk.java.net/~jjg/8149843/webrev.00/ >>> >>> -- Jon >> From jan.lahoda at oracle.com Thu May 12 18:31:40 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 12 May 2016 20:31:40 +0200 Subject: RFR: 8149843, 8150111 Two small changes to StandardJavaFileManager API In-Reply-To: <5734CAEB.4090706@oracle.com> References: <572D2752.3000607@oracle.com> <5733B1D1.7070304@oracle.com> <57349F94.6000002@oracle.com> <5734CAEB.4090706@oracle.com> Message-ID: <5734CC0C.2060607@oracle.com> Seems fine. Jan On 12.5.2016 20:26, Jonathan Gibbons wrote: > After merging with the latest jdk9/dev bits, some additional minor > changes are required in jdk.jshell, to avoid the use of Iterable extends Path>. The most obvious change is simply to use List > instead, as shown here. > > $ hg diff src/jdk.jshell > diff -r c51b40933e0c > src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java > --- > a/src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java > Wed May 11 20:28:22 2016 +0000 > +++ > b/src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java > Thu May 12 11:25:46 2016 -0700 > @@ -1045,7 +1045,7 @@ > > public SourceCache(AnalyzeTask originalTask) { > this.originalTask = originalTask; > - Iterable sources = findSources(); > + List sources = findSources(); > if (sources.iterator().hasNext()) { > StandardJavaFileManager fm = > compiler.getStandardFileManager(null, null, null); > try { > @@ -1145,9 +1145,9 @@ > } > } > > - private Iterable availableSources; > + private List availableSources; > > - private Iterable findSources() { > + private List findSources() { > if (availableSources != null) { > return availableSources; > } > > > > On 05/12/2016 08:21 AM, Jan Lahoda wrote: >> Looks fine to me too. >> >> Jan >> >> On 12.5.2016 00:27, Vicente-Arturo Romero-Zaldivar wrote: >>> approved, >>> >>> Thanks, >>> Vicente >>> >>> On 05/06/2016 07:22 PM, Jonathan Gibbons wrote: >>>> This is for two small changes to the StandardJavaFileManager API. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8149843 >>>> StandardJavaFileManager should provide a way to get paths from strings >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8150111 >>>> Need to change signature of >>>> StandardJavaFileManager.setLocationFromPaths >>>> >>>> With these changes, all standard uses of Paths.get are replaced by >>>> using >>>> a user-provided function, defaulting to Paths::get. >>>> >>>> The exceptions are: >>>> file names specified on the javac command line >>>> file names used in some internal debugging/tracing features in >>>> javac >>>> file names used in sjavac >>>> >>>> Combined specdiff: http://cr.openjdk.java.net/~jjg/8149843/specdiff.00/ >>>> Combined webrev: http://cr.openjdk.java.net/~jjg/8149843/webrev.00/ >>>> >>>> -- Jon >>> > From vicente.romero at oracle.com Thu May 12 18:31:41 2016 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Thu, 12 May 2016 14:31:41 -0400 Subject: RFR: 8149843, 8150111 Two small changes to StandardJavaFileManager API In-Reply-To: <5734CAEB.4090706@oracle.com> References: <572D2752.3000607@oracle.com> <5733B1D1.7070304@oracle.com> <57349F94.6000002@oracle.com> <5734CAEB.4090706@oracle.com> Message-ID: <5734CC0D.2060200@oracle.com> I'm OK with the last changes, Thanks, Vicente On 05/12/2016 02:26 PM, Jonathan Gibbons wrote: > After merging with the latest jdk9/dev bits, some additional minor > changes are required in jdk.jshell, to avoid the use of Iterable extends Path>. The most obvious change is simply to use List > instead, as shown here. > > $ hg diff src/jdk.jshell > diff -r c51b40933e0c > src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java > --- > a/src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java > Wed May 11 20:28:22 2016 +0000 > +++ > b/src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java > Thu May 12 11:25:46 2016 -0700 > @@ -1045,7 +1045,7 @@ > > public SourceCache(AnalyzeTask originalTask) { > this.originalTask = originalTask; > - Iterable sources = findSources(); > + List sources = findSources(); > if (sources.iterator().hasNext()) { > StandardJavaFileManager fm = > compiler.getStandardFileManager(null, null, null); > try { > @@ -1145,9 +1145,9 @@ > } > } > > - private Iterable availableSources; > + private List availableSources; > > - private Iterable findSources() { > + private List findSources() { > if (availableSources != null) { > return availableSources; > } > > > > On 05/12/2016 08:21 AM, Jan Lahoda wrote: >> Looks fine to me too. >> >> Jan >> >> On 12.5.2016 00:27, Vicente-Arturo Romero-Zaldivar wrote: >>> approved, >>> >>> Thanks, >>> Vicente >>> >>> On 05/06/2016 07:22 PM, Jonathan Gibbons wrote: >>>> This is for two small changes to the StandardJavaFileManager API. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8149843 >>>> StandardJavaFileManager should provide a way to get paths from strings >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8150111 >>>> Need to change signature of >>>> StandardJavaFileManager.setLocationFromPaths >>>> >>>> With these changes, all standard uses of Paths.get are replaced by >>>> using >>>> a user-provided function, defaulting to Paths::get. >>>> >>>> The exceptions are: >>>> file names specified on the javac command line >>>> file names used in some internal debugging/tracing features in >>>> javac >>>> file names used in sjavac >>>> >>>> Combined specdiff: >>>> http://cr.openjdk.java.net/~jjg/8149843/specdiff.00/ >>>> Combined webrev: http://cr.openjdk.java.net/~jjg/8149843/webrev.00/ >>>> >>>> -- Jon >>> > From robert.field at oracle.com Fri May 13 06:41:52 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 12 May 2016 23:41:52 -0700 Subject: RFR 8156101: JShell SPI: Provide a pluggable execution control SPI In-Reply-To: <57341A57.6090000@oracle.com> References: <57341A57.6090000@oracle.com> Message-ID: <57357730.7050408@oracle.com> Attached is a test for this functionality utilizing a local implementation of ExecutionControl courtesy of Grigory Ptashko. Thank you Grigory! All files in test/jdk/jshell. This test needs one method added to KullaTesting -- diff -r c51b40933e0c test/jdk/jshell/KullaTesting.java --- a/test/jdk/jshell/KullaTesting.java Wed May 11 20:28:22 2016 +0000 +++ b/test/jdk/jshell/KullaTesting.java Thu May 12 23:31:14 2016 -0700 @@ -72,6 +72,7 @@ import static jdk.jshell.Snippet.Status.*; import static org.testng.Assert.*; import static jdk.jshell.Snippet.SubKind.METHOD_SUBKIND; +import jdk.jshell.spi.ExecutionControl; public class KullaTesting { @@ -166,6 +167,21 @@ classpath = new ArrayList<>(); } + public void setUp(ExecutionControl ec) { + inStream = new TestingInputStream(); + outStream = new ByteArrayOutputStream(); + errStream = new ByteArrayOutputStream(); + state = JShell.builder() + .executionEngine(ec) + .in(inStream) + .out(new PrintStream(outStream)) + .err(new PrintStream(errStream)) + .build(); + allSnippets = new LinkedHashSet<>(); + idToSnippet = new LinkedHashMap<>(); + classpath = new ArrayList<>(); + } + @AfterMethod public void tearDown() { if (state != null) state.close(); On 05/11/2016 10:53 PM, Robert Field wrote: > Please review the new Service Provider Interface for using alternate > execution implements. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8156101 > > Webrevs: > http://cr.openjdk.java.net/~rfield/8156101v0_lang.webrev/ > http://cr.openjdk.java.net/~rfield/8156101v0_ws.webrev/ > > Javadoc: > http://cr.openjdk.java.net/~rfield/jshell_spi/ > > Note: The SPI is tested since it is used by the default JDI > implementation (which has no special access). However, tests using an > alternative execution engine will be included. > > Thanks, > Robert > From robert.field at oracle.com Fri May 13 06:46:11 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 12 May 2016 23:46:11 -0700 Subject: file manager should be closed In-Reply-To: <5734CA1C.4000504@oracle.com> References: <5734CA1C.4000504@oracle.com> Message-ID: <57357833.3090406@oracle.com> Thanks, Jon. Created: https://bugs.openjdk.java.net/browse/JDK-8156911 -Robert On 05/12/2016 11:23 AM, Jonathan Gibbons wrote: > This is in SourceCodeAnalysisImpl.java. > getStandardFileManager is defined to return a new instance each time > it is called. Ideally, each such instance should be closed. This > can be done by creating the file manager with try-wirth-resources, > > > public SourceCache(AnalyzeTask originalTask) { > this.originalTask = originalTask; > List sources = findSources(); > if (sources.iterator().hasNext()) { > StandardJavaFileManager fm = > compiler.getStandardFileManager(null, null, null); > try { > fm.setLocationFromPaths(StandardLocation.SOURCE_PATH, sources); > } catch (IOException ex) { > proc.debug(ex, > "SourceCodeAnalysisImpl.SourceCache.(...)"); > fm = null; > } > this.fm = fm; > } else { > //don't waste time if there are no sources > this.fm = null; > } > } From robert.field at oracle.com Fri May 13 07:29:19 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 13 May 2016 00:29:19 -0700 Subject: RFR 8156101: JShell SPI: Provide a pluggable execution control SPI In-Reply-To: <57357730.7050408@oracle.com> References: <57341A57.6090000@oracle.com> <57357730.7050408@oracle.com> Message-ID: <5735824F.6030804@oracle.com> Updated langtools webrev: http://cr.openjdk.java.net/~rfield/8156101v1_lang.webrev/ -Robert On 05/12/2016 11:41 PM, Robert Field wrote: > Attached is a test for this functionality utilizing a local > implementation of ExecutionControl courtesy of Grigory Ptashko. > Thank you Grigory! > > All files in test/jdk/jshell. > > This test needs one method added to KullaTesting -- > > diff -r c51b40933e0c test/jdk/jshell/KullaTesting.java > --- a/test/jdk/jshell/KullaTesting.java Wed May 11 20:28:22 2016 +0000 > +++ b/test/jdk/jshell/KullaTesting.java Thu May 12 23:31:14 2016 -0700 > @@ -72,6 +72,7 @@ > import static jdk.jshell.Snippet.Status.*; > import static org.testng.Assert.*; > import static jdk.jshell.Snippet.SubKind.METHOD_SUBKIND; > +import jdk.jshell.spi.ExecutionControl; > > public class KullaTesting { > > @@ -166,6 +167,21 @@ > classpath = new ArrayList<>(); > } > > + public void setUp(ExecutionControl ec) { > + inStream = new TestingInputStream(); > + outStream = new ByteArrayOutputStream(); > + errStream = new ByteArrayOutputStream(); > + state = JShell.builder() > + .executionEngine(ec) > + .in(inStream) > + .out(new PrintStream(outStream)) > + .err(new PrintStream(errStream)) > + .build(); > + allSnippets = new LinkedHashSet<>(); > + idToSnippet = new LinkedHashMap<>(); > + classpath = new ArrayList<>(); > + } > + > @AfterMethod > public void tearDown() { > if (state != null) state.close(); > > > On 05/11/2016 10:53 PM, Robert Field wrote: >> Please review the new Service Provider Interface for using alternate >> execution implements. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8156101 >> >> Webrevs: >> http://cr.openjdk.java.net/~rfield/8156101v0_lang.webrev/ >> http://cr.openjdk.java.net/~rfield/8156101v0_ws.webrev/ >> >> Javadoc: >> http://cr.openjdk.java.net/~rfield/jshell_spi/ >> >> Note: The SPI is tested since it is used by the default JDI >> implementation (which has no special access). However, tests using >> an alternative execution engine will be included. >> >> Thanks, >> Robert >> > From robert.field at oracle.com Fri May 13 17:18:57 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 13 May 2016 10:18:57 -0700 Subject: RFR: 8133549: Generalize jshell's EditingHistory In-Reply-To: <57345A05.2060504@oracle.com> References: <57345A05.2060504@oracle.com> Message-ID: <57360C81.2060906@oracle.com> Thumbs up on langtools changes -Robert On 05/12/16 03:25, Jan Lahoda wrote: > Hello, > > In jshell, there's a special history mode that is intended to aid with > editing/re-entering multi-line snippets (EditingHistory). It works > like this: when the user goes back through the history to the first > line of a multi-line snippet, and enters/confirms that line, the > history view is limited only to the given snippet. I.e. up and down > arrows won't go through the whole history, but only the few lines of > the given snippet. When the multi-line snippet is finished, the > history is restored to the original full state. > > The proposal here is to generalize this history mode so that it can be > used in jjs as well. For this, a new support class is added into > jdk.internal.le, that implements this history. Also, ConsoleReader is > extended to also accept actions as a Runnable instead of only > ActionListener, so that the EditingHistory can add extra actions to > jump by the whole snippets when going back in history. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8133549 > > Webrev: > jdk repository: > http://cr.openjdk.java.net/~jlahoda/8133549/jdk/webrev.00/ > > langtools repository: > http://cr.openjdk.java.net/~jlahoda/8133549/langtools/webrev.00/ > > nashorn repository: > http://cr.openjdk.java.net/~jlahoda/8133549/nashorn/webrev.00/ > > Any comments are welcome! > > Thanks, > Jan From robert.field at oracle.com Sat May 14 00:04:38 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 13 May 2016 17:04:38 -0700 Subject: RFR 8154812: jshell tool: value printing truncation Message-ID: <57366B96.9060905@oracle.com> Please review configurable result value truncation. Bug: https://bugs.openjdk.java.net/browse/JDK-8154812 Webrev: http://cr.openjdk.java.net/~rfield/8154812v0.webrev/ Thanks, Robert From jonathan.gibbons at oracle.com Sat May 14 00:35:40 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 13 May 2016 17:35:40 -0700 Subject: Style suggestion Message-ID: <573672DC.70900@oracle.com> This pattern: 122 for (FormatCase e : EnumSet.allOf(FormatCase.class)) is more simply written as 122 for (FormatCase e : FormatCase.values()) -- Jon From robert.field at oracle.com Sat May 14 00:56:47 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 13 May 2016 17:56:47 -0700 Subject: Style suggestion In-Reply-To: <573672DC.70900@oracle.com> References: <573672DC.70900@oracle.com> Message-ID: <573677CF.60408@oracle.com> Thanks Jon, Filed: https://bugs.openjdk.java.net/browse/JDK-8156984 -Robert On 05/13/16 17:35, Jonathan Gibbons wrote: > This pattern: > > 122 for (FormatCase e : EnumSet.allOf(FormatCase.class)) > > > is more simply written as > > 122 for (FormatCase e : FormatCase.values()) > > > -- Jon > > > From robert.field at oracle.com Sat May 14 03:55:50 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 13 May 2016 20:55:50 -0700 Subject: RFR 8156101: JShell SPI: Provide a pluggable execution control SPI In-Reply-To: <5735824F.6030804@oracle.com> References: <57341A57.6090000@oracle.com> <57357730.7050408@oracle.com> <5735824F.6030804@oracle.com> Message-ID: <5736A1C6.7040302@oracle.com> Updated langtools webrev with additional code comments only (to ease review). No changes to code: http://cr.openjdk.java.net/~rfield/8156101v2_lang.webrev/ -Robert On 05/13/2016 12:29 AM, Robert Field wrote: > Updated langtools webrev: > http://cr.openjdk.java.net/~rfield/8156101v1_lang.webrev/ > > -Robert > > > On 05/12/2016 11:41 PM, Robert Field wrote: >> Attached is a test for this functionality utilizing a local >> implementation of ExecutionControl courtesy of Grigory Ptashko. >> Thank you Grigory! >> >> All files in test/jdk/jshell. >> >> This test needs one method added to KullaTesting -- >> >> diff -r c51b40933e0c test/jdk/jshell/KullaTesting.java >> --- a/test/jdk/jshell/KullaTesting.java Wed May 11 20:28:22 2016 >> +0000 >> +++ b/test/jdk/jshell/KullaTesting.java Thu May 12 23:31:14 2016 >> -0700 >> @@ -72,6 +72,7 @@ >> import static jdk.jshell.Snippet.Status.*; >> import static org.testng.Assert.*; >> import static jdk.jshell.Snippet.SubKind.METHOD_SUBKIND; >> +import jdk.jshell.spi.ExecutionControl; >> >> public class KullaTesting { >> >> @@ -166,6 +167,21 @@ >> classpath = new ArrayList<>(); >> } >> >> + public void setUp(ExecutionControl ec) { >> + inStream = new TestingInputStream(); >> + outStream = new ByteArrayOutputStream(); >> + errStream = new ByteArrayOutputStream(); >> + state = JShell.builder() >> + .executionEngine(ec) >> + .in(inStream) >> + .out(new PrintStream(outStream)) >> + .err(new PrintStream(errStream)) >> + .build(); >> + allSnippets = new LinkedHashSet<>(); >> + idToSnippet = new LinkedHashMap<>(); >> + classpath = new ArrayList<>(); >> + } >> + >> @AfterMethod >> public void tearDown() { >> if (state != null) state.close(); >> >> >> On 05/11/2016 10:53 PM, Robert Field wrote: >>> Please review the new Service Provider Interface for using alternate >>> execution implements. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8156101 >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~rfield/8156101v0_lang.webrev/ >>> http://cr.openjdk.java.net/~rfield/8156101v0_ws.webrev/ >>> >>> Javadoc: >>> http://cr.openjdk.java.net/~rfield/jshell_spi/ >>> >>> Note: The SPI is tested since it is used by the default JDI >>> implementation (which has no special access). However, tests using >>> an alternative execution engine will be included. >>> >>> Thanks, >>> Robert >>> >> > From robert.field at oracle.com Sat May 14 23:09:14 2016 From: robert.field at oracle.com (Robert Field) Date: Sat, 14 May 2016 16:09:14 -0700 Subject: RFR 8154812: jshell tool: value printing truncation In-Reply-To: <57366B96.9060905@oracle.com> References: <57366B96.9060905@oracle.com> Message-ID: <5737B01A.20607@oracle.com> (With updated webrev) Please review configurable result value truncation. Bug: https://bugs.openjdk.java.net/browse/JDK-8154812 Webrev: http://cr.openjdk.java.net/~rfield/8154812v1.webrev/ Thanks, Robert From robert.field at oracle.com Sun May 15 05:50:06 2016 From: robert.field at oracle.com (Robert Field) Date: Sat, 14 May 2016 22:50:06 -0700 Subject: RFR 8153920: jshell tool: allow a parameter on the /vars /methods /classes commands Message-ID: <57380E0E.6010908@oracle.com> Please review that allows the same parameters on /vars /methods and /types as allowed on /list -- thus one can look a specific snippet in detail: /var x Bug: https://bugs.openjdk.java.net/browse/JDK-8153920 Webrev: http://cr.openjdk.java.net/~rfield/8153920v0.webrev/ Thanks, Robert From bitterfoxc at gmail.com Mon May 16 03:43:10 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Mon, 16 May 2016 12:43:10 +0900 Subject: Very cool user developped tool: jshell with maven artifact Message-ID: Hi all, @kawasima developed and released the very cool tool which everybody would want, extending from JShell! https://github.com/kawasima/try-artifact This tool makes trying maven artifact easy: -> /resolve org.apache.commons:commons-lang3:jar:3.4 | Path /home/kawasima/.m2/repository/org/apache/commons/commons-lang3/3.4/commons-lang3-3.4.jar added to classpath -> org.apache.commons.lang3.RandomStringUtils.randomAlphanumeric(30) | Expression value is: "8D1ysKPGhHPLGpsducw0ch0SnSfixb" | assigned to temporary variable $1 of type String You can download the jar file from https://github.com/kawasima/try-artifact/releases ------ To Robert, Thank you for implementing internationalization. And I'm terribly sorry about it. I couldn't do because I'm still busy for doing my research and writing a paper. Hopefully I will be free after July, and I'd like to send some patches and update my patches which are not merged yet. Regards, shinyafox(Shinya Yoshida) From jan.lahoda at oracle.com Mon May 16 07:14:07 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 16 May 2016 09:14:07 +0200 Subject: RFR 8156101: JShell SPI: Provide a pluggable execution control SPI In-Reply-To: <5736A1C6.7040302@oracle.com> References: <57341A57.6090000@oracle.com> <57357730.7050408@oracle.com> <5735824F.6030804@oracle.com> <5736A1C6.7040302@oracle.com> Message-ID: <5739733F.5080906@oracle.com> Overall, seems reasonable to me. Would be good to get a confirmation from the clients, that it matches their needs. For the top-level changes, a review from build-dev would be good. Comments: -I am not sure of SPIConstants - is there a chance we could avoid this class? I see that: --DOIT_METHOD_NAME is used in invoke - maybe invoke could take the method name as a parameter? --PREFIX_PATTERN is used in implementation of ExecutionControl.varValue; but do we want everybody to re-implement the Object->String conversion? I was thinking if a method like: ExecutionControl: public static String toString(Object value) {...} that every ExecutionControl implementation would call wouldn't work better. -also not sure about SPIDebugControl - is there a chance we could replace that with a group of Loggers, or something similar? -in KullaTesting I wonder if we could avoid the code duplication and let the setUp() method delegate to setUp(ExecutionControl) A few nits: -commented-out code in LocalExecutionControl.java -javadoc of ClassTracker.ClassInfo: Associates a class name class bytes and ReferenceType. maybe a missing comma between "class name" and "class bytes"? Jan On 14.5.2016 05:55, Robert Field wrote: > Updated langtools webrev with additional code comments only (to ease > review). No changes to code: > > http://cr.openjdk.java.net/~rfield/8156101v2_lang.webrev/ > > -Robert > > > > On 05/13/2016 12:29 AM, Robert Field wrote: >> Updated langtools webrev: >> http://cr.openjdk.java.net/~rfield/8156101v1_lang.webrev/ >> >> -Robert >> >> >> On 05/12/2016 11:41 PM, Robert Field wrote: >>> Attached is a test for this functionality utilizing a local >>> implementation of ExecutionControl courtesy of Grigory Ptashko. >>> Thank you Grigory! >>> >>> All files in test/jdk/jshell. >>> >>> This test needs one method added to KullaTesting -- >>> >>> diff -r c51b40933e0c test/jdk/jshell/KullaTesting.java >>> --- a/test/jdk/jshell/KullaTesting.java Wed May 11 20:28:22 2016 >>> +0000 >>> +++ b/test/jdk/jshell/KullaTesting.java Thu May 12 23:31:14 2016 >>> -0700 >>> @@ -72,6 +72,7 @@ >>> import static jdk.jshell.Snippet.Status.*; >>> import static org.testng.Assert.*; >>> import static jdk.jshell.Snippet.SubKind.METHOD_SUBKIND; >>> +import jdk.jshell.spi.ExecutionControl; >>> >>> public class KullaTesting { >>> >>> @@ -166,6 +167,21 @@ >>> classpath = new ArrayList<>(); >>> } >>> >>> + public void setUp(ExecutionControl ec) { >>> + inStream = new TestingInputStream(); >>> + outStream = new ByteArrayOutputStream(); >>> + errStream = new ByteArrayOutputStream(); >>> + state = JShell.builder() >>> + .executionEngine(ec) >>> + .in(inStream) >>> + .out(new PrintStream(outStream)) >>> + .err(new PrintStream(errStream)) >>> + .build(); >>> + allSnippets = new LinkedHashSet<>(); >>> + idToSnippet = new LinkedHashMap<>(); >>> + classpath = new ArrayList<>(); >>> + } >>> + >>> @AfterMethod >>> public void tearDown() { >>> if (state != null) state.close(); >>> >>> >>> On 05/11/2016 10:53 PM, Robert Field wrote: >>>> Please review the new Service Provider Interface for using alternate >>>> execution implements. >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8156101 >>>> >>>> Webrevs: >>>> http://cr.openjdk.java.net/~rfield/8156101v0_lang.webrev/ >>>> http://cr.openjdk.java.net/~rfield/8156101v0_ws.webrev/ >>>> >>>> Javadoc: >>>> http://cr.openjdk.java.net/~rfield/jshell_spi/ >>>> >>>> Note: The SPI is tested since it is used by the default JDI >>>> implementation (which has no special access). However, tests using >>>> an alternative execution engine will be included. >>>> >>>> Thanks, >>>> Robert >>>> >>> >> > From kubota.yuji at gmail.com Mon May 16 07:40:14 2016 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Mon, 16 May 2016 16:40:14 +0900 Subject: Very cool user developped tool: jshell with maven artifact In-Reply-To: References: Message-ID: This is very awesome tool. I'm looking forward to the session he will talk about this tool on Java Day Tokyo 2016 [1] :) [1]: http://www.oracle.co.jp/events/javaday/2016/#secDay1 (3-E) Regards, Yuji 2016-05-16 12:43 GMT+09:00 ShinyaYoshida : > Hi all, > > @kawasima developed and released the very cool tool which everybody would > want, extending from JShell! > https://github.com/kawasima/try-artifact > > This tool makes trying maven artifact easy: > > -> /resolve org.apache.commons:commons-lang3:jar:3.4 > | Path > /home/kawasima/.m2/repository/org/apache/commons/commons-lang3/3.4/commons-lang3-3.4.jar > added to classpath > > -> org.apache.commons.lang3.RandomStringUtils.randomAlphanumeric(30) > | Expression value is: "8D1ysKPGhHPLGpsducw0ch0SnSfixb" > | assigned to temporary variable $1 of type String > > You can download the jar file from > https://github.com/kawasima/try-artifact/releases > > ------ > > To Robert, > Thank you for implementing internationalization. > And I'm terribly sorry about it. > I couldn't do because I'm still busy for doing my research and writing a > paper. > > Hopefully I will be free after July, and I'd like to send some patches and > update my patches which are not merged yet. > > Regards, > shinyafox(Shinya Yoshida) From robert.field at oracle.com Mon May 16 16:27:37 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 16 May 2016 09:27:37 -0700 Subject: RFR 8156101: JShell SPI: Provide a pluggable execution control SPI In-Reply-To: <5739733F.5080906@oracle.com> References: <57341A57.6090000@oracle.com> <57357730.7050408@oracle.com> <5735824F.6030804@oracle.com> <5736A1C6.7040302@oracle.com> <5739733F.5080906@oracle.com> Message-ID: <5739F4F9.7040101@oracle.com> On 05/16/2016 12:14 AM, Jan Lahoda wrote: > Overall, seems reasonable to me. Would be good to get a confirmation > from the clients, that it matches their needs. Grigory was able to port to the SPI in a few hours. > For the top-level changes, a review from build-dev would be good. > > Comments: > -I am not sure of SPIConstants - is there a chance we could avoid this > class? I see that: > --DOIT_METHOD_NAME is used in invoke - maybe invoke could take the > method name as a parameter? > --PREFIX_PATTERN is used in implementation of > ExecutionControl.varValue; but do we want everybody to re-implement > the Object->String conversion? I was thinking if a method like: > ExecutionControl: > public static String toString(Object value) {...} > that every ExecutionControl implementation would call wouldn't work > better. The functionality that uses PREFIX_PATTERN is the expunge() method. However, expunge() is also called on the result value on the JShell-core side, thus its use in an execution engine is redundant and I will remove. Having the method name be a parameter makes it more general (I was trying to keep it tightly tailored) but it gets rid of the last shared constant and allows for some possibly interesting extensibility. So, I have remove SPIConstants. > > -also not sure about SPIDebugControl - is there a chance we could > replace that with a group of Loggers, or something similar? Suggestions... > > -in KullaTesting I wonder if we could avoid the code duplication and > let the setUp() method delegate to setUp(ExecutionControl) We could, but then we wouldn't be testing the default case (no ExecutionControl explicitly specified). > > A few nits: > -commented-out code in LocalExecutionControl.java I've updated to Grigory's latest code, and this is gone. > -javadoc of ClassTracker.ClassInfo: > Associates a class name class bytes and ReferenceType. > maybe a missing comma between "class name" and "class bytes"? Fixed. > > Jan Thanks Jan! -Robert > > > On 14.5.2016 05:55, Robert Field wrote: >> Updated langtools webrev with additional code comments only (to ease >> review). No changes to code: >> >> http://cr.openjdk.java.net/~rfield/8156101v2_lang.webrev/ >> >> -Robert >> >> >> >> On 05/13/2016 12:29 AM, Robert Field wrote: >>> Updated langtools webrev: >>> http://cr.openjdk.java.net/~rfield/8156101v1_lang.webrev/ >>> >>> -Robert >>> >>> >>> On 05/12/2016 11:41 PM, Robert Field wrote: >>>> Attached is a test for this functionality utilizing a local >>>> implementation of ExecutionControl courtesy of Grigory Ptashko. >>>> Thank you Grigory! >>>> >>>> All files in test/jdk/jshell. >>>> >>>> This test needs one method added to KullaTesting -- >>>> >>>> diff -r c51b40933e0c test/jdk/jshell/KullaTesting.java >>>> --- a/test/jdk/jshell/KullaTesting.java Wed May 11 20:28:22 2016 >>>> +0000 >>>> +++ b/test/jdk/jshell/KullaTesting.java Thu May 12 23:31:14 2016 >>>> -0700 >>>> @@ -72,6 +72,7 @@ >>>> import static jdk.jshell.Snippet.Status.*; >>>> import static org.testng.Assert.*; >>>> import static jdk.jshell.Snippet.SubKind.METHOD_SUBKIND; >>>> +import jdk.jshell.spi.ExecutionControl; >>>> >>>> public class KullaTesting { >>>> >>>> @@ -166,6 +167,21 @@ >>>> classpath = new ArrayList<>(); >>>> } >>>> >>>> + public void setUp(ExecutionControl ec) { >>>> + inStream = new TestingInputStream(); >>>> + outStream = new ByteArrayOutputStream(); >>>> + errStream = new ByteArrayOutputStream(); >>>> + state = JShell.builder() >>>> + .executionEngine(ec) >>>> + .in(inStream) >>>> + .out(new PrintStream(outStream)) >>>> + .err(new PrintStream(errStream)) >>>> + .build(); >>>> + allSnippets = new LinkedHashSet<>(); >>>> + idToSnippet = new LinkedHashMap<>(); >>>> + classpath = new ArrayList<>(); >>>> + } >>>> + >>>> @AfterMethod >>>> public void tearDown() { >>>> if (state != null) state.close(); >>>> >>>> >>>> On 05/11/2016 10:53 PM, Robert Field wrote: >>>>> Please review the new Service Provider Interface for using alternate >>>>> execution implements. >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8156101 >>>>> >>>>> Webrevs: >>>>> http://cr.openjdk.java.net/~rfield/8156101v0_lang.webrev/ >>>>> http://cr.openjdk.java.net/~rfield/8156101v0_ws.webrev/ >>>>> >>>>> Javadoc: >>>>> http://cr.openjdk.java.net/~rfield/jshell_spi/ >>>>> >>>>> Note: The SPI is tested since it is used by the default JDI >>>>> implementation (which has no special access). However, tests using >>>>> an alternative execution engine will be included. >>>>> >>>>> Thanks, >>>>> Robert >>>>> >>>> >>> >> From robert.field at oracle.com Mon May 16 19:41:10 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 16 May 2016 12:41:10 -0700 Subject: RFR 8156101: JShell SPI: Provide a pluggable execution control SPI In-Reply-To: <5739733F.5080906@oracle.com> References: <57341A57.6090000@oracle.com> <57357730.7050408@oracle.com> <5735824F.6030804@oracle.com> <5736A1C6.7040302@oracle.com> <5739733F.5080906@oracle.com> Message-ID: <573A2256.3040004@oracle.com> Per Jan's review, I have updated the webrev: http://cr.openjdk.java.net/~rfield/8156101v3_lang.webrev/ Specifically: * SPIConstants has been removed (the values moved internal, to Util, and made package private). * The method name is now passed to ExecutionControl.invoke() -- and correspondingly, is now sent over the wire to the RemoteAgent. * The expunge() method (and calls to it) have been removed from JDIExecutionControl and LocalExecutionControl. * SPIDebugControl has been removed (and InternalDebugControl un-removed, but now having the updated guts of SPIDebugControl). * To rid ourselves of InternalDebugControl in the future, I have created: https://bugs.openjdk.java.net/browse/JDK-8157080. * I have updated LocalExecutionControl to Grigory's latest version (which no longer has commented out code). * I have fixed the javadoc of ClassTracker.ClassInfo. Bug: https://bugs.openjdk.java.net/browse/JDK-8156101 -Robert On 05/16/2016 12:14 AM, Jan Lahoda wrote: > Overall, seems reasonable to me. Would be good to get a confirmation > from the clients, that it matches their needs. For the top-level > changes, a review from build-dev would be good. > > Comments: > -I am not sure of SPIConstants - is there a chance we could avoid this > class? I see that: > --DOIT_METHOD_NAME is used in invoke - maybe invoke could take the > method name as a parameter? > --PREFIX_PATTERN is used in implementation of > ExecutionControl.varValue; but do we want everybody to re-implement > the Object->String conversion? I was thinking if a method like: > ExecutionControl: > public static String toString(Object value) {...} > that every ExecutionControl implementation would call wouldn't work > better. > > -also not sure about SPIDebugControl - is there a chance we could > replace that with a group of Loggers, or something similar? > > -in KullaTesting I wonder if we could avoid the code duplication and > let the setUp() method delegate to setUp(ExecutionControl) > > A few nits: > -commented-out code in LocalExecutionControl.java > -javadoc of ClassTracker.ClassInfo: > Associates a class name class bytes and ReferenceType. > maybe a missing comma between "class name" and "class bytes"? > > Jan > > On 14.5.2016 05:55, Robert Field wrote: >> Updated langtools webrev with additional code comments only (to ease >> review). No changes to code: >> >> http://cr.openjdk.java.net/~rfield/8156101v2_lang.webrev/ >> >> -Robert >> >> >> >> On 05/13/2016 12:29 AM, Robert Field wrote: >>> Updated langtools webrev: >>> http://cr.openjdk.java.net/~rfield/8156101v1_lang.webrev/ >>> >>> -Robert >>> >>> >>> On 05/12/2016 11:41 PM, Robert Field wrote: >>>> Attached is a test for this functionality utilizing a local >>>> implementation of ExecutionControl courtesy of Grigory Ptashko. >>>> Thank you Grigory! >>>> >>>> All files in test/jdk/jshell. >>>> >>>> This test needs one method added to KullaTesting -- >>>> >>>> diff -r c51b40933e0c test/jdk/jshell/KullaTesting.java >>>> --- a/test/jdk/jshell/KullaTesting.java Wed May 11 20:28:22 2016 >>>> +0000 >>>> +++ b/test/jdk/jshell/KullaTesting.java Thu May 12 23:31:14 2016 >>>> -0700 >>>> @@ -72,6 +72,7 @@ >>>> import static jdk.jshell.Snippet.Status.*; >>>> import static org.testng.Assert.*; >>>> import static jdk.jshell.Snippet.SubKind.METHOD_SUBKIND; >>>> +import jdk.jshell.spi.ExecutionControl; >>>> >>>> public class KullaTesting { >>>> >>>> @@ -166,6 +167,21 @@ >>>> classpath = new ArrayList<>(); >>>> } >>>> >>>> + public void setUp(ExecutionControl ec) { >>>> + inStream = new TestingInputStream(); >>>> + outStream = new ByteArrayOutputStream(); >>>> + errStream = new ByteArrayOutputStream(); >>>> + state = JShell.builder() >>>> + .executionEngine(ec) >>>> + .in(inStream) >>>> + .out(new PrintStream(outStream)) >>>> + .err(new PrintStream(errStream)) >>>> + .build(); >>>> + allSnippets = new LinkedHashSet<>(); >>>> + idToSnippet = new LinkedHashMap<>(); >>>> + classpath = new ArrayList<>(); >>>> + } >>>> + >>>> @AfterMethod >>>> public void tearDown() { >>>> if (state != null) state.close(); >>>> >>>> >>>> On 05/11/2016 10:53 PM, Robert Field wrote: >>>>> Please review the new Service Provider Interface for using alternate >>>>> execution implements. >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8156101 >>>>> >>>>> Webrevs: >>>>> http://cr.openjdk.java.net/~rfield/8156101v0_lang.webrev/ >>>>> http://cr.openjdk.java.net/~rfield/8156101v0_ws.webrev/ >>>>> >>>>> Javadoc: >>>>> http://cr.openjdk.java.net/~rfield/jshell_spi/ >>>>> >>>>> Note: The SPI is tested since it is used by the default JDI >>>>> implementation (which has no special access). However, tests using >>>>> an alternative execution engine will be included. >>>>> >>>>> Thanks, >>>>> Robert >>>>> >>>> >>> >> From vicente.romero at oracle.com Mon May 16 22:55:28 2016 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Mon, 16 May 2016 18:55:28 -0400 Subject: RFR 8154812: jshell tool: value printing truncation Message-ID: <573A4FE0.7040302@oracle.com> accepted, Thanks, Vicente >Please review configurable result value truncation. > >Bug: >https://bugs.openjdk.java.net/browse/JDK-8154812 > >Webrev: >http://cr.openjdk.java.net/~rfield/8154812v0.webrev/ > >Thanks, >Robert From vicente.romero at oracle.com Mon May 16 22:59:23 2016 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Mon, 16 May 2016 18:59:23 -0400 Subject: RFR 8153920: jshell tool: allow a parameter on the /vars /methods /classes commands Message-ID: <573A50CB.2050701@oracle.com> accepted, Thanks, Vicente >Please review that allows the same parameters on /vars /methods and >/types as allowed on /list -- thus one can look a specific snippet in >detail: /var x > >Bug: >https://bugs.openjdk.java.net/browse/JDK-8153920 > >Webrev: >http://cr.openjdk.java.net/~rfield/8153920v0.webrev/ > >Thanks, >Robert From jan.lahoda at oracle.com Tue May 17 19:32:19 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 17 May 2016 21:32:19 +0200 Subject: RFR 8156101: JShell SPI: Provide a pluggable execution control SPI In-Reply-To: <573A2256.3040004@oracle.com> References: <57341A57.6090000@oracle.com> <57357730.7050408@oracle.com> <5735824F.6030804@oracle.com> <5736A1C6.7040302@oracle.com> <5739733F.5080906@oracle.com> <573A2256.3040004@oracle.com> Message-ID: <573B71C3.3060402@oracle.com> Seems OK to me. Jan On 16.5.2016 21:41, Robert Field wrote: > Per Jan's review, I have updated the webrev: > > http://cr.openjdk.java.net/~rfield/8156101v3_lang.webrev/ > > Specifically: > * SPIConstants has been removed (the values moved internal, to Util, and > made package private). > * The method name is now passed to ExecutionControl.invoke() -- and > correspondingly, is now sent over the wire to the RemoteAgent. > * The expunge() method (and calls to it) have been removed from > JDIExecutionControl and LocalExecutionControl. > * SPIDebugControl has been removed (and InternalDebugControl un-removed, > but now having the updated guts of SPIDebugControl). > * To rid ourselves of InternalDebugControl in the future, I have > created: https://bugs.openjdk.java.net/browse/JDK-8157080. > * I have updated LocalExecutionControl to Grigory's latest version > (which no longer has commented out code). > * I have fixed the javadoc of ClassTracker.ClassInfo. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8156101 > > -Robert > > On 05/16/2016 12:14 AM, Jan Lahoda wrote: >> Overall, seems reasonable to me. Would be good to get a confirmation >> from the clients, that it matches their needs. For the top-level >> changes, a review from build-dev would be good. >> >> Comments: >> -I am not sure of SPIConstants - is there a chance we could avoid this >> class? I see that: >> --DOIT_METHOD_NAME is used in invoke - maybe invoke could take the >> method name as a parameter? >> --PREFIX_PATTERN is used in implementation of >> ExecutionControl.varValue; but do we want everybody to re-implement >> the Object->String conversion? I was thinking if a method like: >> ExecutionControl: >> public static String toString(Object value) {...} >> that every ExecutionControl implementation would call wouldn't work >> better. >> >> -also not sure about SPIDebugControl - is there a chance we could >> replace that with a group of Loggers, or something similar? >> >> -in KullaTesting I wonder if we could avoid the code duplication and >> let the setUp() method delegate to setUp(ExecutionControl) >> >> A few nits: >> -commented-out code in LocalExecutionControl.java >> -javadoc of ClassTracker.ClassInfo: >> Associates a class name class bytes and ReferenceType. >> maybe a missing comma between "class name" and "class bytes"? >> >> Jan >> >> On 14.5.2016 05:55, Robert Field wrote: >>> Updated langtools webrev with additional code comments only (to ease >>> review). No changes to code: >>> >>> http://cr.openjdk.java.net/~rfield/8156101v2_lang.webrev/ >>> >>> -Robert >>> >>> >>> >>> On 05/13/2016 12:29 AM, Robert Field wrote: >>>> Updated langtools webrev: >>>> http://cr.openjdk.java.net/~rfield/8156101v1_lang.webrev/ >>>> >>>> -Robert >>>> >>>> >>>> On 05/12/2016 11:41 PM, Robert Field wrote: >>>>> Attached is a test for this functionality utilizing a local >>>>> implementation of ExecutionControl courtesy of Grigory Ptashko. >>>>> Thank you Grigory! >>>>> >>>>> All files in test/jdk/jshell. >>>>> >>>>> This test needs one method added to KullaTesting -- >>>>> >>>>> diff -r c51b40933e0c test/jdk/jshell/KullaTesting.java >>>>> --- a/test/jdk/jshell/KullaTesting.java Wed May 11 20:28:22 2016 >>>>> +0000 >>>>> +++ b/test/jdk/jshell/KullaTesting.java Thu May 12 23:31:14 2016 >>>>> -0700 >>>>> @@ -72,6 +72,7 @@ >>>>> import static jdk.jshell.Snippet.Status.*; >>>>> import static org.testng.Assert.*; >>>>> import static jdk.jshell.Snippet.SubKind.METHOD_SUBKIND; >>>>> +import jdk.jshell.spi.ExecutionControl; >>>>> >>>>> public class KullaTesting { >>>>> >>>>> @@ -166,6 +167,21 @@ >>>>> classpath = new ArrayList<>(); >>>>> } >>>>> >>>>> + public void setUp(ExecutionControl ec) { >>>>> + inStream = new TestingInputStream(); >>>>> + outStream = new ByteArrayOutputStream(); >>>>> + errStream = new ByteArrayOutputStream(); >>>>> + state = JShell.builder() >>>>> + .executionEngine(ec) >>>>> + .in(inStream) >>>>> + .out(new PrintStream(outStream)) >>>>> + .err(new PrintStream(errStream)) >>>>> + .build(); >>>>> + allSnippets = new LinkedHashSet<>(); >>>>> + idToSnippet = new LinkedHashMap<>(); >>>>> + classpath = new ArrayList<>(); >>>>> + } >>>>> + >>>>> @AfterMethod >>>>> public void tearDown() { >>>>> if (state != null) state.close(); >>>>> >>>>> >>>>> On 05/11/2016 10:53 PM, Robert Field wrote: >>>>>> Please review the new Service Provider Interface for using alternate >>>>>> execution implements. >>>>>> >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8156101 >>>>>> >>>>>> Webrevs: >>>>>> http://cr.openjdk.java.net/~rfield/8156101v0_lang.webrev/ >>>>>> http://cr.openjdk.java.net/~rfield/8156101v0_ws.webrev/ >>>>>> >>>>>> Javadoc: >>>>>> http://cr.openjdk.java.net/~rfield/jshell_spi/ >>>>>> >>>>>> Note: The SPI is tested since it is used by the default JDI >>>>>> implementation (which has no special access). However, tests using >>>>>> an alternative execution engine will be included. >>>>>> >>>>>> Thanks, >>>>>> Robert >>>>>> >>>>> >>>> >>> > From jan.lahoda at oracle.com Tue May 17 21:47:53 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 17 May 2016 23:47:53 +0200 Subject: RFR: 8133549: Generalize jshell's EditingHistory In-Reply-To: <57360C81.2060906@oracle.com> References: <57345A05.2060504@oracle.com> <57360C81.2060906@oracle.com> Message-ID: <573B9189.1030700@oracle.com> I realized I've forgot to do some cleanup in ConsoleIOContext: the new EditingHistory in jdk.internal.le is registering shortcuts for itself, so the ConsoleIOContext does not need to register the shortcuts anymore. Updated webrev: http://cr.openjdk.java.net/~jlahoda/8133549/langtools/webrev.01/ Delta webrev since the previous iteration: http://cr.openjdk.java.net/~jlahoda/8133549/langtools/webrev.01/delta/webrev/ Does this look OK? Thanks, Jan On 13.5.2016 19:18, Robert Field wrote: > Thumbs up on langtools changes > > -Robert > > On 05/12/16 03:25, Jan Lahoda wrote: >> Hello, >> >> In jshell, there's a special history mode that is intended to aid with >> editing/re-entering multi-line snippets (EditingHistory). It works >> like this: when the user goes back through the history to the first >> line of a multi-line snippet, and enters/confirms that line, the >> history view is limited only to the given snippet. I.e. up and down >> arrows won't go through the whole history, but only the few lines of >> the given snippet. When the multi-line snippet is finished, the >> history is restored to the original full state. >> >> The proposal here is to generalize this history mode so that it can be >> used in jjs as well. For this, a new support class is added into >> jdk.internal.le, that implements this history. Also, ConsoleReader is >> extended to also accept actions as a Runnable instead of only >> ActionListener, so that the EditingHistory can add extra actions to >> jump by the whole snippets when going back in history. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8133549 >> >> Webrev: >> jdk repository: >> http://cr.openjdk.java.net/~jlahoda/8133549/jdk/webrev.00/ >> >> langtools repository: >> http://cr.openjdk.java.net/~jlahoda/8133549/langtools/webrev.00/ >> >> nashorn repository: >> http://cr.openjdk.java.net/~jlahoda/8133549/nashorn/webrev.00/ >> >> Any comments are welcome! >> >> Thanks, >> Jan > From robert.field at oracle.com Tue May 17 22:00:13 2016 From: robert.field at oracle.com (Robert Field) Date: Tue, 17 May 2016 15:00:13 -0700 Subject: RFR: 8133549: Generalize jshell's EditingHistory In-Reply-To: <573B9189.1030700@oracle.com> References: <57345A05.2060504@oracle.com> <57360C81.2060906@oracle.com> <573B9189.1030700@oracle.com> Message-ID: <573B946D.8080801@oracle.com> Thumbs up on new changes too. -Robert On 05/17/16 14:47, Jan Lahoda wrote: > I realized I've forgot to do some cleanup in ConsoleIOContext: the new > EditingHistory in jdk.internal.le is registering shortcuts for itself, > so the ConsoleIOContext does not need to register the shortcuts anymore. > > Updated webrev: > http://cr.openjdk.java.net/~jlahoda/8133549/langtools/webrev.01/ > > Delta webrev since the previous iteration: > http://cr.openjdk.java.net/~jlahoda/8133549/langtools/webrev.01/delta/webrev/ > > > Does this look OK? > > Thanks, > Jan > > On 13.5.2016 19:18, Robert Field wrote: >> Thumbs up on langtools changes >> >> -Robert >> >> On 05/12/16 03:25, Jan Lahoda wrote: >>> Hello, >>> >>> In jshell, there's a special history mode that is intended to aid with >>> editing/re-entering multi-line snippets (EditingHistory). It works >>> like this: when the user goes back through the history to the first >>> line of a multi-line snippet, and enters/confirms that line, the >>> history view is limited only to the given snippet. I.e. up and down >>> arrows won't go through the whole history, but only the few lines of >>> the given snippet. When the multi-line snippet is finished, the >>> history is restored to the original full state. >>> >>> The proposal here is to generalize this history mode so that it can be >>> used in jjs as well. For this, a new support class is added into >>> jdk.internal.le, that implements this history. Also, ConsoleReader is >>> extended to also accept actions as a Runnable instead of only >>> ActionListener, so that the EditingHistory can add extra actions to >>> jump by the whole snippets when going back in history. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8133549 >>> >>> Webrev: >>> jdk repository: >>> http://cr.openjdk.java.net/~jlahoda/8133549/jdk/webrev.00/ >>> >>> langtools repository: >>> http://cr.openjdk.java.net/~jlahoda/8133549/langtools/webrev.00/ >>> >>> nashorn repository: >>> http://cr.openjdk.java.net/~jlahoda/8133549/nashorn/webrev.00/ >>> >>> Any comments are welcome! >>> >>> Thanks, >>> Jan >> From robert.field at oracle.com Wed May 18 00:37:51 2016 From: robert.field at oracle.com (Robert Field) Date: Tue, 17 May 2016 17:37:51 -0700 Subject: RFR 8157185: jshell tool: ambiguous format -- distinguished arguments should be options Message-ID: <573BB95F.6060806@oracle.com> Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8157185 Webrev: http://cr.openjdk.java.net/~rfield/8157185v0.webrev/ Thanks, Robert From nadeesh.tv at oracle.com Wed May 18 09:35:50 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Wed, 18 May 2016 15:05:50 +0530 Subject: RFR:JDK-8155581:jshell tool: replace use of Option.get() Message-ID: <573C3776.1070903@oracle.com> Hi all, Please review BugId : https://bugs.openjdk.java.net/browse/JDK-8155581 webrev: http://cr.openjdk.java.net/~ntv/kulla/8155581/webrev.00/ Solution : Changed the usage of stream to String.join() as suggested by Stuart -- Thanks and Regards, Nadeesh TV From vicente.romero at oracle.com Wed May 18 15:02:11 2016 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Wed, 18 May 2016 11:02:11 -0400 Subject: RFR 8157185: jshell tool: ambiguous format -- distinguished arguments should be options In-Reply-To: <573BB95F.6060806@oracle.com> References: <573BB95F.6060806@oracle.com> Message-ID: <573C83F3.9080905@oracle.com> approved, Thanks, Vicente On 05/17/2016 08:37 PM, Robert Field wrote: > Please review. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8157185 > > Webrev: > http://cr.openjdk.java.net/~rfield/8157185v0.webrev/ > > Thanks, > Robert > From robert.field at oracle.com Wed May 18 16:56:38 2016 From: robert.field at oracle.com (Robert Field) Date: Wed, 18 May 2016 09:56:38 -0700 Subject: RFR:JDK-8155581:jshell tool: replace use of Option.get() In-Reply-To: <573C3776.1070903@oracle.com> References: <573C3776.1070903@oracle.com> Message-ID: <154c4cc3570.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Thumbs up, with the nit that it would be nice if you split the long line to be consistent with the line length (no need for a re-review for fixing that). -Robert On May 18, 2016 2:36:33 AM nadeesh tv wrote: > Hi all, > > Please review > > BugId : https://bugs.openjdk.java.net/browse/JDK-8155581 > > webrev: http://cr.openjdk.java.net/~ntv/kulla/8155581/webrev.00/ > > Solution : Changed the usage of stream to String.join() as suggested by > Stuart > > -- > Thanks and Regards, > Nadeesh TV > From nadeesh.tv at oracle.com Wed May 18 16:59:55 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Wed, 18 May 2016 22:29:55 +0530 Subject: RFR:JDK-8155581:jshell tool: replace use of Option.get() In-Reply-To: <154c4cc3570.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> References: <573C3776.1070903@oracle.com> <154c4cc3570.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Message-ID: <573C9F8B.808@oracle.com> Thanks Robert. I will make the suggested changes. On 5/18/2016 10:26 PM, Robert Field wrote: > Thumbs up, with the nit that it would be nice if you split the long > line to be consistent with the line length (no need for a re-review > for fixing that). > > -Robert > > > > On May 18, 2016 2:36:33 AM nadeesh tv wrote: > >> Hi all, >> >> Please review >> >> BugId : https://bugs.openjdk.java.net/browse/JDK-8155581 >> >> webrev: http://cr.openjdk.java.net/~ntv/kulla/8155581/webrev.00/ >> >> Solution : Changed the usage of stream to String.join() as suggested by >> Stuart >> >> -- >> Thanks and Regards, >> Nadeesh TV >> > > -- Thanks and Regards, Nadeesh TV From robert.field at oracle.com Fri May 20 03:57:47 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 19 May 2016 20:57:47 -0700 Subject: RFR 8157200: jshell tool: Add /retain command to persist settings Message-ID: <573E8B3B.3060409@oracle.com> Please review... Bugs: 8157200: jshell tool: Add /retain command to persist settings https://bugs.openjdk.java.net/browse/JDK-8157200 8156910: jshell tool: crash when code with syntax error contains format specifier https://bugs.openjdk.java.net/browse/JDK-8156910 Webrev: http://cr.openjdk.java.net/~rfield/8157200v0.webrev/ Thanks, Robert From jan.lahoda at oracle.com Fri May 20 10:44:52 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 20 May 2016 12:44:52 +0200 Subject: RFR: 8131017: jshell tool: pasting code with tabs invokes tab completion Message-ID: <573EEAA4.9030307@oracle.com> Please review. Problem: when pasting code that contains tab characters into both jshell and jjs, the tab completion gets invoked on tabs instead of using the tab character itself. The proposed solution is to set setCopyPasteDetection(true) on jline's ConsoleReader, which should enable jline's copy-paste detection, and avoid invoking the tab completion on paste. A limitation of the detection is that it cannot detect trailing tab characters, only can detect tab character followed by at least one more character. I hope that shouldn't be a big problem. Bug: https://bugs.openjdk.java.net/browse/JDK-8131017 Webrev - langtools: http://cr.openjdk.java.net/~jlahoda/8131017/langtools/webrev.00/ Webrev - nashorn: http://cr.openjdk.java.net/~jlahoda/8131017/nashorn/webrev.00/ Thanks, Jan From jan.lahoda at oracle.com Fri May 20 11:43:58 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 20 May 2016 13:43:58 +0200 Subject: RFR 8157200: jshell tool: Add /retain command to persist settings In-Reply-To: <573E8B3B.3060409@oracle.com> References: <573E8B3B.3060409@oracle.com> Message-ID: <573EF87E.7090200@oracle.com> Hi Robert, Overall, seems OK to me. But I have a question: there appears to be no way to un-retain stuff like modes or editor - should there be a way to un-retain those? Thanks, Jan On 20.5.2016 05:57, Robert Field wrote: > Please review... > > Bugs: > 8157200: jshell tool: Add /retain command to persist settings > https://bugs.openjdk.java.net/browse/JDK-8157200 > > 8156910: jshell tool: crash when code with syntax error > contains format specifier > https://bugs.openjdk.java.net/browse/JDK-8156910 > > Webrev: > http://cr.openjdk.java.net/~rfield/8157200v0.webrev/ > > Thanks, > Robert > From sundararajan.athijegannathan at oracle.com Fri May 20 12:16:29 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 20 May 2016 17:46:29 +0530 Subject: RFR: 8131017: jshell tool: pasting code with tabs invokes tab completion In-Reply-To: <573EEAA4.9030307@oracle.com> References: <573EEAA4.9030307@oracle.com> Message-ID: Looks good. -Sundar On 5/20/2016 4:14 PM, Jan Lahoda wrote: > Please review. > > Problem: when pasting code that contains tab characters into both > jshell and jjs, the tab completion gets invoked on tabs instead of > using the tab character itself. > > The proposed solution is to set setCopyPasteDetection(true) on jline's > ConsoleReader, which should enable jline's copy-paste detection, and > avoid invoking the tab completion on paste. A limitation of the > detection is that it cannot detect trailing tab characters, only can > detect tab character followed by at least one more character. I hope > that shouldn't be a big problem. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8131017 > > Webrev - langtools: > http://cr.openjdk.java.net/~jlahoda/8131017/langtools/webrev.00/ > > Webrev - nashorn: > http://cr.openjdk.java.net/~jlahoda/8131017/nashorn/webrev.00/ > > Thanks, > Jan From brian.goetz at oracle.com Fri May 20 14:50:20 2016 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 20 May 2016 10:50:20 -0400 Subject: RFR 8157200: jshell tool: Add /retain command to persist settings In-Reply-To: <573EF87E.7090200@oracle.com> References: <573E8B3B.3060409@oracle.com> <573EF87E.7090200@oracle.com> Message-ID: <13396160-94bb-6d7d-f0fd-0a07dffd2a1a@oracle.com> Perhaps /reset xxx would be a way to set back to the default? On 5/20/2016 7:43 AM, Jan Lahoda wrote: > Hi Robert, > > Overall, seems OK to me. But I have a question: there appears to be no > way to un-retain stuff like modes or editor - should there be a way to > un-retain those? > > Thanks, > Jan > > On 20.5.2016 05:57, Robert Field wrote: >> Please review... >> >> Bugs: >> 8157200: jshell tool: Add /retain command to persist settings >> https://bugs.openjdk.java.net/browse/JDK-8157200 >> >> 8156910: jshell tool: crash when code with syntax error >> contains format specifier >> https://bugs.openjdk.java.net/browse/JDK-8156910 >> >> Webrev: >> http://cr.openjdk.java.net/~rfield/8157200v0.webrev/ >> >> Thanks, >> Robert >> From robert.field at oracle.com Fri May 20 16:18:31 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 20 May 2016 09:18:31 -0700 Subject: RFR 8157200: jshell tool: Add /retain command to persist settings In-Reply-To: <573EF87E.7090200@oracle.com> References: <573E8B3B.3060409@oracle.com> <573EF87E.7090200@oracle.com> Message-ID: <573F38D7.8060904@oracle.com> On 05/20/16 04:43, Jan Lahoda wrote: > Hi Robert, > > Overall, seems OK to me. But I have a question: there appears to be no > way to un-retain stuff like modes or editor - should there be a way to > un-retain those? Probably, yes. There are four things that can be retained: start: There is always a start-up file, even if it is empty (which is not the default). So, unsetting it or unretaining it would just be setting it to what you want. Having a -default, and maybe a -none option on /set and /retain would probably be good. editor: editor is either set or, if unset, is editpad. Having a -editpad or -default option would be good. feedback: feedback is always set to something. So unset and unretain are covered by /set feedback normal mode: Added modes you no longer use would just be bloat/clutter they wouldn't interfere with anything. Still, it would be nice to have a way to clean them up. A -delete option on /set and /retain would do that. Today I plan to work on these two bugs: https://bugs.openjdk.java.net/browse/JDK-8157395 https://bugs.openjdk.java.net/browse/JDK-8157393 Can we discuss this more today and fold the solution into that work? And push this now, since it is really additional functionality that is being requested? -Robert P.S. /reset zeroes the JShell state, I would not want to overload the meaning of that command with something utterly unrelated > > Thanks, > Jan > > On 20.5.2016 05:57, Robert Field wrote: >> Please review... >> >> Bugs: >> 8157200: jshell tool: Add /retain command to persist settings >> https://bugs.openjdk.java.net/browse/JDK-8157200 >> >> 8156910: jshell tool: crash when code with syntax error >> contains format specifier >> https://bugs.openjdk.java.net/browse/JDK-8156910 >> >> Webrev: >> http://cr.openjdk.java.net/~rfield/8157200v0.webrev/ >> >> Thanks, >> Robert >> From robert.field at oracle.com Fri May 20 17:12:16 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 20 May 2016 10:12:16 -0700 Subject: RFR: 8131017: jshell tool: pasting code with tabs invokes tab completion In-Reply-To: <573EEAA4.9030307@oracle.com> References: <573EEAA4.9030307@oracle.com> Message-ID: <573F4570.2080507@oracle.com> Thumbs up on langtools changes. -Robert On 05/20/16 03:44, Jan Lahoda wrote: > Please review. > > Problem: when pasting code that contains tab characters into both > jshell and jjs, the tab completion gets invoked on tabs instead of > using the tab character itself. > > The proposed solution is to set setCopyPasteDetection(true) on jline's > ConsoleReader, which should enable jline's copy-paste detection, and > avoid invoking the tab completion on paste. A limitation of the > detection is that it cannot detect trailing tab characters, only can > detect tab character followed by at least one more character. I hope > that shouldn't be a big problem. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8131017 > > Webrev - langtools: > http://cr.openjdk.java.net/~jlahoda/8131017/langtools/webrev.00/ > > Webrev - nashorn: > http://cr.openjdk.java.net/~jlahoda/8131017/nashorn/webrev.00/ > > Thanks, > Jan From jan.lahoda at oracle.com Fri May 20 17:13:41 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 20 May 2016 19:13:41 +0200 Subject: RFR 8157200: jshell tool: Add /retain command to persist settings In-Reply-To: <573F38D7.8060904@oracle.com> References: <573E8B3B.3060409@oracle.com> <573EF87E.7090200@oracle.com> <573F38D7.8060904@oracle.com> Message-ID: <573F45C5.8040305@oracle.com> I am OK with pushing the current state, and add un-retaining later. On 20.5.2016 18:18, Robert Field wrote: > > On 05/20/16 04:43, Jan Lahoda wrote: >> Hi Robert, >> >> Overall, seems OK to me. But I have a question: there appears to be no >> way to un-retain stuff like modes or editor - should there be a way to >> un-retain those? > > Probably, yes. > > There are four things that can be retained: > > start: > There is always a start-up file, even if it is empty (which is not the > default). So, unsetting it or unretaining it would just be setting it > to what you want. Having a -default, and maybe a -none option on /set > and /retain would probably be good. > > editor: > editor is either set or, if unset, is editpad. Having a -editpad or > -default option would be good. -default might be better. And /retain should persist even the default/null option. Thanks, Jan > > feedback: > feedback is always set to something. So unset and unretain are covered > by /set feedback normal > > mode: > Added modes you no longer use would just be bloat/clutter they wouldn't > interfere with anything. Still, it would be nice to have a way to clean > them up. A -delete option on /set and /retain would do that. > > Today I plan to work on these two bugs: > https://bugs.openjdk.java.net/browse/JDK-8157395 > https://bugs.openjdk.java.net/browse/JDK-8157393 > > Can we discuss this more today and fold the solution into that work? And > push this now, since it is really additional functionality that is being > requested? > > -Robert > > P.S. /reset zeroes the JShell state, I would not want to overload the > meaning of that command with something utterly unrelated > >> >> Thanks, >> Jan >> >> On 20.5.2016 05:57, Robert Field wrote: >>> Please review... >>> >>> Bugs: >>> 8157200: jshell tool: Add /retain command to persist settings >>> https://bugs.openjdk.java.net/browse/JDK-8157200 >>> >>> 8156910: jshell tool: crash when code with syntax error >>> contains format specifier >>> https://bugs.openjdk.java.net/browse/JDK-8156910 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rfield/8157200v0.webrev/ >>> >>> Thanks, >>> Robert >>> > From robert.field at oracle.com Mon May 23 05:17:34 2016 From: robert.field at oracle.com (Robert Field) Date: Sun, 22 May 2016 22:17:34 -0700 Subject: RFR 8157517 : jshell tool: allow undoing operations Message-ID: <5742926E.3020408@oracle.com> Please review ... Bugs: 8157517 : jshell tool: allow undoing operations https://bugs.openjdk.java.net/browse/JDK-8157517 8157395: jshell tool: allow the position of options on commands to be more flexible https://bugs.openjdk.java.net/browse/JDK-8157395 8157393: jshell tool: change /set newmode ... to be consistent with /retain mode https://bugs.openjdk.java.net/browse/JDK-8157393 Webrev: http://cr.openjdk.java.net/~rfield/8157517v0.webrev/ Thanks, Robert From jan.lahoda at oracle.com Mon May 23 16:15:37 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 23 May 2016 18:15:37 +0200 Subject: RFR 8157517 : jshell tool: allow undoing operations In-Reply-To: <5742926E.3020408@oracle.com> References: <5742926E.3020408@oracle.com> Message-ID: <57432CA9.70305@oracle.com> Seems Ok to me. Jan On 23.5.2016 07:17, Robert Field wrote: > Please review ... > > Bugs: > > 8157517 : jshell tool: allow undoing operations > https://bugs.openjdk.java.net/browse/JDK-8157517 > > 8157395: jshell tool: allow the position of options on commands to > be more flexible > https://bugs.openjdk.java.net/browse/JDK-8157395 > > 8157393: jshell tool: change /set newmode ... to be consistent with > /retain mode > https://bugs.openjdk.java.net/browse/JDK-8157393 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8157517v0.webrev/ > > Thanks, > Robert > From joe.darcy at oracle.com Mon May 23 16:36:56 2016 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 23 May 2016 09:36:56 -0700 Subject: JDK 9 RFR of JDK-8157597: Demote ExecutionControlTest.java to tier and mark as intermittent Message-ID: <1164cc7e-59e9-74fb-7383-f86b322c9c41@oracle.com> Hello, The test jdk/jshell/ExecutionControlTest.java intermittently fails (JDK-8157528). Until the instability is addressed, it should be marked as intermittently failing and demoted to tier 2. Please review the patch below which does this. Thanks, -Joe --- a/test/TEST.groups Mon May 23 15:07:10 2016 +0100 +++ b/test/TEST.groups Mon May 23 09:32:46 2016 -0700 @@ -28,11 +28,13 @@ jdk \ lib \ tools \ + -jdk/jshell/ExecutionControlTest.java \ -jdk/jshell/ToolReloadTest.java \ -jdk/jshell/ToolLocaleMessageTest.java # (Almost) no langtools tests are tier 2. tier2 = \ + jdk/jshell/ExecutionControlTest.java \ jdk/jshell/ToolReloadTest.java \ jdk/jshell/ToolLocaleMessageTest.java diff -r a8b7c9938b74 test/jdk/jshell/ExecutionControlTest.java --- a/test/jdk/jshell/ExecutionControlTest.java Mon May 23 15:07:10 2016 +0100 +++ b/test/jdk/jshell/ExecutionControlTest.java Mon May 23 09:32:46 2016 -0700 @@ -27,6 +27,7 @@ * @summary Tests for ExecutionControl SPI * @build KullaTesting LocalExecutionControl * @run testng ExecutionControlTest + * @key intermittent */ From robert.field at oracle.com Mon May 23 17:37:37 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 23 May 2016 10:37:37 -0700 Subject: JDK 9 RFR of JDK-8157597: Demote ExecutionControlTest.java to tier and mark as intermittent In-Reply-To: <1164cc7e-59e9-74fb-7383-f86b322c9c41@oracle.com> References: <1164cc7e-59e9-74fb-7383-f86b322c9c41@oracle.com> Message-ID: <57433FE1.8050504@oracle.com> Thanks Joe. I've asked the author, Grigory, if he wants to take a look. But it seems to me, at least for now, that this could be addressed with a simple null check. -Robert On 05/23/16 09:36, joe darcy wrote: > Hello, > > The test > > jdk/jshell/ExecutionControlTest.java > > intermittently fails (JDK-8157528). Until the instability is > addressed, it should be marked as intermittently failing and demoted > to tier 2. > > Please review the patch below which does this. > > Thanks, > > -Joe > > --- a/test/TEST.groups Mon May 23 15:07:10 2016 +0100 > +++ b/test/TEST.groups Mon May 23 09:32:46 2016 -0700 > @@ -28,11 +28,13 @@ > jdk \ > lib \ > tools \ > + -jdk/jshell/ExecutionControlTest.java \ > -jdk/jshell/ToolReloadTest.java \ > -jdk/jshell/ToolLocaleMessageTest.java > > # (Almost) no langtools tests are tier 2. > tier2 = \ > + jdk/jshell/ExecutionControlTest.java \ > jdk/jshell/ToolReloadTest.java \ > jdk/jshell/ToolLocaleMessageTest.java > > diff -r a8b7c9938b74 test/jdk/jshell/ExecutionControlTest.java > --- a/test/jdk/jshell/ExecutionControlTest.java Mon May 23 15:07:10 > 2016 +0100 > +++ b/test/jdk/jshell/ExecutionControlTest.java Mon May 23 09:32:46 > 2016 -0700 > @@ -27,6 +27,7 @@ > * @summary Tests for ExecutionControl SPI > * @build KullaTesting LocalExecutionControl > * @run testng ExecutionControlTest > + * @key intermittent > */ > > > From robert.field at oracle.com Mon May 23 19:53:51 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 23 May 2016 12:53:51 -0700 Subject: RFR 8157528: jdk/jshell/ExecutionControlTest.java failed intermittently with NPE Message-ID: <57435FCF.3030409@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8157528 snippetThread.start(); Thread[] threadList = new Thread[execThreadGroup.activeCount()]; execThreadGroup.enumerate(threadList); for (Thread thread : threadList) { + if (thread != null) thread.join(); } if (stopped.get()) { debug("Killed."); From jan.lahoda at oracle.com Mon May 23 20:01:39 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 23 May 2016 22:01:39 +0200 Subject: RFR 8157528: jdk/jshell/ExecutionControlTest.java failed intermittently with NPE In-Reply-To: <57435FCF.3030409@oracle.com> References: <57435FCF.3030409@oracle.com> Message-ID: <574361A3.409@oracle.com> Seems OK. (I take this is used for tests - it would probably be more reliable to repeat the joining until activeCount is 0, but no need to do that for this impl.) Jan On 23.5.2016 21:53, Robert Field wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8157528 > > > snippetThread.start(); > Thread[] threadList = new > Thread[execThreadGroup.activeCount()]; > execThreadGroup.enumerate(threadList); > for (Thread thread : threadList) { > + if (thread != null) > thread.join(); > } > > if (stopped.get()) { > debug("Killed."); > From marcus at lagergren.net Tue May 24 09:51:04 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Tue, 24 May 2016 11:51:04 +0200 Subject: RFR: 8131017: jshell tool: pasting code with tabs invokes tab completion In-Reply-To: <573EEAA4.9030307@oracle.com> References: <573EEAA4.9030307@oracle.com> Message-ID: <764A304A-8A9A-4D53-BD12-BB3830EE6834@lagergren.net> +1 > On 20 May 2016, at 12:44, Jan Lahoda wrote: > > Please review. > > Problem: when pasting code that contains tab characters into both jshell and jjs, the tab completion gets invoked on tabs instead of using the tab character itself. > > The proposed solution is to set setCopyPasteDetection(true) on jline's ConsoleReader, which should enable jline's copy-paste detection, and avoid invoking the tab completion on paste. A limitation of the detection is that it cannot detect trailing tab characters, only can detect tab character followed by at least one more character. I hope that shouldn't be a big problem. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8131017 > > Webrev - langtools: > http://cr.openjdk.java.net/~jlahoda/8131017/langtools/webrev.00/ > > Webrev - nashorn: > http://cr.openjdk.java.net/~jlahoda/8131017/nashorn/webrev.00/ > > Thanks, > Jan From robert.field at oracle.com Thu May 26 05:45:22 2016 From: robert.field at oracle.com (Robert Field) Date: Wed, 25 May 2016 22:45:22 -0700 Subject: RFR 8157917: JShell: shutdown could cause remote JDWP errors to be visible to users Message-ID: <57468D72.2090101@oracle.com> Please review Bugs: 8157917: JShell: shutdown could cause remote JDWP errors to be visible to users https://bugs.openjdk.java.net/browse/JDK-8157917 8157918: JShell tests: StartOptionTest displays insufficient information to diagnose failures https://bugs.openjdk.java.net/browse/JDK-8157918 Webrev: http://cr.openjdk.java.net/~rfield/8157917v0.webrev/ Thanks, Robert From vicente.romero at oracle.com Thu May 26 14:40:38 2016 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Thu, 26 May 2016 10:40:38 -0400 Subject: RFR 8157917: JShell: shutdown could cause remote JDWP errors to be visible to users In-Reply-To: <57468D72.2090101@oracle.com> References: <57468D72.2090101@oracle.com> Message-ID: <57470AE6.5050909@oracle.com> Looks good, Thanks, Vicente On 05/26/2016 01:45 AM, Robert Field wrote: > Please review > > Bugs: > > 8157917: JShell: shutdown could cause remote JDWP errors to be > visible to users > https://bugs.openjdk.java.net/browse/JDK-8157917 > > 8157918: JShell tests: StartOptionTest displays insufficient > information to diagnose failures > https://bugs.openjdk.java.net/browse/JDK-8157918 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8157917v0.webrev/ > > Thanks, > Robert > From robert.field at oracle.com Thu May 26 17:33:30 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 26 May 2016 10:33:30 -0700 Subject: RFR 8157953: JShell tests: reenable ToolBasicTest Message-ID: <5747336A.3080004@oracle.com> Please review. Bugs: 8157953: JShell tests: reenable ToolBasicTest https://bugs.openjdk.java.net/browse/JDK-8157953 8080883: JShell tool: tool does not report errors if -startup and -nostartup flags are specified https://bugs.openjdk.java.net/browse/JDK-8080883 Webrev: http://cr.openjdk.java.net/~rfield/8157953v0.webrev/ Thanks, Robert From nadeesh.tv at oracle.com Thu May 26 17:39:46 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Thu, 26 May 2016 23:09:46 +0530 Subject: RFR:JDK-8156984: JShell tool: for (FormatCase e : EnumSet.allOf(FormatCase.class)) Message-ID: <574734E2.30709@oracle.com> Hi all, Please review BugId: https://bugs.openjdk.java.net/browse/JDK-8156984 webrev : http://cr.openjdk.java.net/~ntv/kulla/8156984/webrev.00/ -- Thanks and Regards, Nadeesh TV From robert.field at oracle.com Thu May 26 17:42:20 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 26 May 2016 10:42:20 -0700 Subject: RFR:JDK-8156984: JShell tool: for (FormatCase e : EnumSet.allOf(FormatCase.class)) In-Reply-To: <574734E2.30709@oracle.com> References: <574734E2.30709@oracle.com> Message-ID: <5747357C.207@oracle.com> Thumbs up! -Robert On 05/26/16 10:39, nadeesh tv wrote: > Hi all, > > Please review > > BugId: https://bugs.openjdk.java.net/browse/JDK-8156984 > > webrev : http://cr.openjdk.java.net/~ntv/kulla/8156984/webrev.00/ > From vicente.romero at oracle.com Thu May 26 18:20:52 2016 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Thu, 26 May 2016 14:20:52 -0400 Subject: RFR 8157953: JShell tests: reenable ToolBasicTest In-Reply-To: <5747336A.3080004@oracle.com> References: <5747336A.3080004@oracle.com> Message-ID: <57473E84.1080008@oracle.com> Looks good, Vicente On 05/26/2016 01:33 PM, Robert Field wrote: > Please review. > > Bugs: > > 8157953: JShell tests: reenable ToolBasicTest > https://bugs.openjdk.java.net/browse/JDK-8157953 > > 8080883: JShell tool: tool does not report errors if -startup and > -nostartup flags are specified > https://bugs.openjdk.java.net/browse/JDK-8080883 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8157953v0.webrev/ > > Thanks, > Robert > From robert.field at oracle.com Fri May 27 00:16:01 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 26 May 2016 17:16:01 -0700 Subject: RFR 8157261: jshell tool: truncation for expressions is not consistent Message-ID: <574791C1.2020506@oracle.com> Please review. Bug: 8157261: jshell tool: truncation for expressions is not consistent Webrev: http://cr.openjdk.java.net/~rfield/8157261v0.webrev/ Thanks, Robert From nadeesh.tv at oracle.com Fri May 27 13:07:54 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Fri, 27 May 2016 18:37:54 +0530 Subject: RFR:JDK-8153897 : jshell tool: "not active" must be pulled from resource file Message-ID: <574846AA.4070106@oracle.com> HI all, Please review BugId : https://bugs.openjdk.java.net/browse/JDK-8153897 Webrev: http://cr.openjdk.java.net/~ntv/kulla/8153897/webrev.00/ -- Thanks and Regards, Nadeesh TV From vicente.romero at oracle.com Fri May 27 15:08:41 2016 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Fri, 27 May 2016 11:08:41 -0400 Subject: RFR 8157261: jshell tool: truncation for expressions is not consistent In-Reply-To: <574791C1.2020506@oracle.com> References: <574791C1.2020506@oracle.com> Message-ID: <574862F9.5@oracle.com> Looks good, Thanks, Vicente On 05/26/2016 08:16 PM, Robert Field wrote: > Please review. > > Bug: > 8157261: jshell tool: truncation for expressions is not consistent > > Webrev: > http://cr.openjdk.java.net/~rfield/8157261v0.webrev/ > > Thanks, > Robert > From robert.field at oracle.com Fri May 27 15:32:39 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 27 May 2016 08:32:39 -0700 Subject: RFR:JDK-8153897 : jshell tool: "not active" must be pulled from resource file In-Reply-To: <574846AA.4070106@oracle.com> References: <574846AA.4070106@oracle.com> Message-ID: <154f2d88dd8.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> The fix is good but the test still leaves the test disabled and does not add the bug ID to the bug list. Robert On May 27, 2016 6:09:00 AM nadeesh tv wrote: > HI all, > > Please review > > BugId : https://bugs.openjdk.java.net/browse/JDK-8153897 > > > Webrev: http://cr.openjdk.java.net/~ntv/kulla/8153897/webrev.00/ > > > -- > Thanks and Regards, > Nadeesh TV > From nadeesh.tv at oracle.com Fri May 27 17:58:20 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Fri, 27 May 2016 23:28:20 +0530 Subject: RFR:JDK-8153897 : jshell tool: "not active" must be pulled from resource file In-Reply-To: <154f2d88dd8.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> References: <574846AA.4070106@oracle.com> <154f2d88dd8.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Message-ID: <57488ABC.8030006@oracle.com> Hi Robert, Thanks for the comments. Please see the updated webrev http://cr.openjdk.java.net/~ntv/kulla/8153897/webrev.01/ Thanks and Regards, Nadeesh TV On 5/27/2016 9:02 PM, Robert Field wrote: > The fix is good but the test still leaves the test disabled and does > not add the bug ID to the bug list. > > Robert > > > > On May 27, 2016 6:09:00 AM nadeesh tv wrote: > >> HI all, >> >> Please review >> >> BugId : https://bugs.openjdk.java.net/browse/JDK-8153897 >> >> >> Webrev: http://cr.openjdk.java.net/~ntv/kulla/8153897/webrev.00/ >> >> >> -- >> Thanks and Regards, >> Nadeesh TV >> > > -- Thanks and Regards, Nadeesh TV From robert.field at oracle.com Fri May 27 18:11:00 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 27 May 2016 11:11:00 -0700 Subject: RFR:JDK-8153897 : jshell tool: "not active" must be pulled from resource file In-Reply-To: <57488ABC.8030006@oracle.com> References: <574846AA.4070106@oracle.com> <154f2d88dd8.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> <57488ABC.8030006@oracle.com> Message-ID: <154f3698720.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Assuming that the test now passes, thumbs up. Robert On May 27, 2016 10:58:40 AM nadeesh tv wrote: > Hi Robert, > Thanks for the comments. > Please see the updated webrev > http://cr.openjdk.java.net/~ntv/kulla/8153897/webrev.01/ > > Thanks and Regards, > Nadeesh TV > On 5/27/2016 9:02 PM, Robert Field wrote: >> The fix is good but the test still leaves the test disabled and does >> not add the bug ID to the bug list. >> >> Robert >> >> >> >> On May 27, 2016 6:09:00 AM nadeesh tv wrote: >> >>> HI all, >>> >>> Please review >>> >>> BugId : https://bugs.openjdk.java.net/browse/JDK-8153897 >>> >>> >>> Webrev: http://cr.openjdk.java.net/~ntv/kulla/8153897/webrev.00/ >>> >>> >>> -- >>> Thanks and Regards, >>> Nadeesh TV >>> >> >> > > -- > Thanks and Regards, > Nadeesh TV > From robert.field at oracle.com Fri May 27 20:19:28 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 27 May 2016 13:19:28 -0700 Subject: RFR 8139872: JShell tests: EditorPadTest failing on headless Message-ID: <5748ABD0.7020309@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8139872 Webrev: http://cr.openjdk.java.net/~rfield/8139872v0.webrev/ Thanks, Robert From vicente.romero at oracle.com Fri May 27 21:31:47 2016 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Fri, 27 May 2016 17:31:47 -0400 Subject: RFR 8139872: JShell tests: EditorPadTest failing on headless In-Reply-To: <5748ABD0.7020309@oracle.com> References: <5748ABD0.7020309@oracle.com> Message-ID: <5748BCC3.1000707@oracle.com> accepted, Thanks, Vicente On 05/27/2016 04:19 PM, Robert Field wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8139872 > > Webrev: > http://cr.openjdk.java.net/~rfield/8139872v0.webrev/ > > Thanks, > Robert > From robert.field at oracle.com Sat May 28 01:16:06 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 27 May 2016 18:16:06 -0700 Subject: RFR 8080843: JShell tool: invalid key error occurs when external editor is used Message-ID: <5748F156.8000702@oracle.com> Bug: (Note: I've put in the issue comments a description of the cause of the problem with references) https://bugs.openjdk.java.net/browse/JDK-8080843 Webrev: http://cr.openjdk.java.net/~rfield/8080843v0.webrev/ Thanks, Robert P.S. While there, I've updated the generated file names and added code comments From bitterfoxc at gmail.com Sun May 29 03:24:58 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Sun, 29 May 2016 12:24:58 +0900 Subject: RFR 8141415: JShell API: wrap erroneous with one-liner comment-outed imports In-Reply-To: References: Message-ID: Hi, Could someone review this? I've updated to current code base: http://cr.openjdk.java.net/~shinyafox/kulla/8141415/webrev.01/ Regards, shinyafox(Shinya Yoshida) 2015-11-04 20:54 GMT+09:00 ShinyaYoshida : > Hi Robert, > Please review this: > > Webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8141415/webrev.00/ > Bugs: https://bugs.openjdk.java.net/browse/JDK-8141415 > > Regards, > shinyafox(Shinya Yoshida) > From robert.field at oracle.com Sun May 29 07:09:12 2016 From: robert.field at oracle.com (Robert Field) Date: Sun, 29 May 2016 00:09:12 -0700 Subject: RFR 8141415: JShell API: wrap erroneous with one-liner comment-outed imports In-Reply-To: References: Message-ID: <154fb5859c0.2765.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Thumbs up! On May 28, 2016 8:25:00 PM ShinyaYoshida wrote: > Hi, > Could someone review this? > > I've updated to current code base: > http://cr.openjdk.java.net/~shinyafox/kulla/8141415/webrev.01/ > > Regards, > shinyafox(Shinya Yoshida) > > 2015-11-04 20:54 GMT+09:00 ShinyaYoshida : > >> Hi Robert, >> Please review this: >> >> Webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8141415/webrev.00/ >> Bugs: https://bugs.openjdk.java.net/browse/JDK-8141415 >> >> Regards, >> shinyafox(Shinya Yoshida) >> From bitterfoxc at gmail.com Sun May 29 14:51:38 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Sun, 29 May 2016 23:51:38 +0900 Subject: RFR 8141415: JShell API: wrap erroneous with one-liner comment-outed imports In-Reply-To: <154fb5859c0.2765.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> References: <154fb5859c0.2765.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Message-ID: Hi Robert, Thanks! I've pushed. Regards, shinyafox(Shinya Yoshida) 2016-05-29 16:09 GMT+09:00 Robert Field : > Thumbs up! > > On May 28, 2016 8:25:00 PM ShinyaYoshida wrote: > >> Hi, >> Could someone review this? >> >> I've updated to current code base: >> http://cr.openjdk.java.net/~shinyafox/kulla/8141415/webrev.01/ >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> 2015-11-04 20:54 GMT+09:00 ShinyaYoshida : >> >>> Hi Robert, >>> Please review this: >>> >>> Webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8141415/webrev.00/ >>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8141415 >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> >> >> From robert.field at oracle.com Sun May 29 15:42:24 2016 From: robert.field at oracle.com (Robert Field) Date: Sun, 29 May 2016 08:42:24 -0700 Subject: RFR 8141415: JShell API: wrap erroneous with one-liner comment-outed imports In-Reply-To: References: Message-ID: <154fd2e3300.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Thumbs up! Thanks, Robert On May 28, 2016 8:25:00 PM ShinyaYoshida wrote: > Hi, > Could someone review this? > > I've updated to current code base: > http://cr.openjdk.java.net/~shinyafox/kulla/8141415/webrev.01/ > > Regards, > shinyafox(Shinya Yoshida) > > 2015-11-04 20:54 GMT+09:00 ShinyaYoshida : > >> Hi Robert, >> Please review this: >> >> Webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8141415/webrev.00/ >> Bugs: https://bugs.openjdk.java.net/browse/JDK-8141415 >> >> Regards, >> shinyafox(Shinya Yoshida) >> From robert.field at oracle.com Tue May 31 16:06:06 2016 From: robert.field at oracle.com (Robert Field) Date: Tue, 31 May 2016 09:06:06 -0700 Subject: RFR 8141415: JShell API: wrap erroneous with one-liner comment-outed imports In-Reply-To: <154fd2e3300.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> References: <154fd2e3300.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Message-ID: <15507909db0.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Would you like me to push this? Thanks, Robert On May 29, 2016 8:43:44 AM Robert Field wrote: > Thumbs up! > > Thanks, > Robert > > > > On May 28, 2016 8:25:00 PM ShinyaYoshida wrote: > >> Hi, >> Could someone review this? >> >> I've updated to current code base: >> http://cr.openjdk.java.net/~shinyafox/kulla/8141415/webrev.01/ >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> 2015-11-04 20:54 GMT+09:00 ShinyaYoshida : >> >>> Hi Robert, >>> Please review this: >>> >>> Webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8141415/webrev.00/ >>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8141415 >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> From vicente.romero at oracle.com Tue May 31 19:22:50 2016 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Tue, 31 May 2016 15:22:50 -0400 Subject: RFR 8080843: JShell tool: invalid key error occurs when external editor is used In-Reply-To: <5748F156.8000702@oracle.com> References: <5748F156.8000702@oracle.com> Message-ID: <574DE48A.5000900@oracle.com> accepted, Thanks, Vicente On 05/27/2016 09:16 PM, Robert Field wrote: > Bug: (Note: I've put in the issue comments a description of the cause > of the problem with references) > > https://bugs.openjdk.java.net/browse/JDK-8080843 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8080843v0.webrev/ > > Thanks, > Robert > > P.S. While there, I've updated the generated file names and added > code comments >