From robert.field at oracle.com  Fri Mar  3 02:13:48 2017
From: robert.field at oracle.com (Robert Field)
Date: Thu, 02 Mar 2017 18:13:48 -0800
Subject: RFR 8175886: JShell: crash on tab-complete with NPE.
Message-ID: <58B8D15C.7080900@oracle.com>

Please review....

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8175886

Webrev:

     http://cr.openjdk.java.net/~rfield/8175886v0.webrev/

Thanks,
Robert


From jan.lahoda at oracle.com  Fri Mar  3 10:12:22 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 3 Mar 2017 11:12:22 +0100
Subject: RFR 8175886: JShell: crash on tab-complete with NPE.
In-Reply-To: <58B8D15C.7080900@oracle.com>
References: <58B8D15C.7080900@oracle.com>
Message-ID: <58B94186.2050108@oracle.com>

Seems OK to me.

Jan

On 3.3.2017 03:13, Robert Field wrote:
> Please review....
>
> Bug:
>
>      https://bugs.openjdk.java.net/browse/JDK-8175886
>
> Webrev:
>
>      http://cr.openjdk.java.net/~rfield/8175886v0.webrev/
>
> Thanks,
> Robert
>

From robert.field at oracle.com  Fri Mar  3 22:44:18 2017
From: robert.field at oracle.com (Robert Field)
Date: Fri, 03 Mar 2017 14:44:18 -0800
Subject: RFR 8175304: JShell tool: The /reset command hangs after setting
 a startup script
Message-ID: <58B9F1C2.4020207@oracle.com>

Please review...

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8175304

Webrev:

     http://cr.openjdk.java.net/~rfield/8175304v0.webrev/

Thanks,
Robert


From robert.field at oracle.com  Mon Mar  6 04:39:07 2017
From: robert.field at oracle.com (Robert Field)
Date: Sun, 05 Mar 2017 20:39:07 -0800
Subject: RFR (XS) 8176184: JShell tests:
 jdk/jshell/CompletionSuggestionTest.testImportStart(): failure
Message-ID: <58BCE7EB.4030808@oracle.com>

Please review....

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8176184

Webrev:

     http://cr.openjdk.java.net/~rfield/8176184v0.webrev/

Thanks,
Robert


From jan.lahoda at oracle.com  Mon Mar  6 16:00:51 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 6 Mar 2017 17:00:51 +0100
Subject: RFR (XS) 8176184: JShell tests:
 jdk/jshell/CompletionSuggestionTest.testImportStart(): failure
In-Reply-To: <58BCE7EB.4030808@oracle.com>
References: <58BCE7EB.4030808@oracle.com>
Message-ID: <58BD87B3.8080504@oracle.com>

Seems OK.

Jan

On 6.3.2017 05:39, Robert Field wrote:
> Please review....
>
> Bug:
>
>      https://bugs.openjdk.java.net/browse/JDK-8176184
>
> Webrev:
>
>      http://cr.openjdk.java.net/~rfield/8176184v0.webrev/
>
> Thanks,
> Robert
>

From jan.lahoda at oracle.com  Mon Mar  6 16:10:05 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 6 Mar 2017 17:10:05 +0100
Subject: RFR 8175304: JShell tool: The /reset command hangs after setting
 a startup script
In-Reply-To: <58B9F1C2.4020207@oracle.com>
References: <58B9F1C2.4020207@oracle.com>
Message-ID: <58BD89DD.8090407@oracle.com>

Seems OK.

Jan

On 3.3.2017 23:44, Robert Field wrote:
> Please review...
>
> Bug:
>
>      https://bugs.openjdk.java.net/browse/JDK-8175304
>
> Webrev:
>
>      http://cr.openjdk.java.net/~rfield/8175304v0.webrev/
>
> Thanks,
> Robert
>

From robert.field at oracle.com  Mon Mar  6 23:40:30 2017
From: robert.field at oracle.com (Robert Field)
Date: Mon, 06 Mar 2017 15:40:30 -0800
Subject: RFR (XXS ASAP) 8176241: JShell tests: on full builds
 CompletionSuggestionTest.testImportStart() fails
Message-ID: <58BDF36E.3090106@oracle.com>

Testing on full systems (with both open and closed) are failing because 
"import o<tab>" completes with "oracle" in addition to the expected "org".
There is already a test for "import c<tab>", so this case is not needed 
-- imply removing it addresses the issue.
Please review...

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8176241

Webrev:

     http://cr.openjdk.java.net/~rfield/8176241v0.webrev/

Diff...


diff -r 173dd02c493c test/jdk/jshell/CompletionSuggestionTest.java
--- a/test/jdk/jshell/CompletionSuggestionTest.java     Mon Mar 06 
08:36:05 2017 -0800
+++ b/test/jdk/jshell/CompletionSuggestionTest.java     Mon Mar 06 
15:33:52 2017 -0800
@@ -23,7 +23,7 @@

  /*
   * @test
- * @bug 8131025 8141092 8153761 8145263 8131019 8175886 8176184
+ * @bug 8131025 8141092 8153761 8145263 8131019 8175886 8176184 8176241
   * @summary Test Completion and Documentation
   * @library /tools/lib
   * @modules jdk.compiler/com.sun.tools.javac.api
@@ -297,7 +297,6 @@

      public void testImportStart() {
          assertCompletion("import c|", "com");
-        assertCompletion("import o|", "org");
      }

      public void testBrokenClassFile() throws Exception {


From joe.darcy at oracle.com  Mon Mar  6 23:43:17 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 6 Mar 2017 15:43:17 -0800
Subject: RFR (XXS ASAP) 8176241: JShell tests: on full builds
 CompletionSuggestionTest.testImportStart() fails
In-Reply-To: <58BDF36E.3090106@oracle.com>
References: <58BDF36E.3090106@oracle.com>
Message-ID: <0c133eb7-0ece-0d57-e92b-ba926ac7e3d4@oracle.com>

Looks fine; cheers,

-Joe


On 3/6/2017 3:40 PM, Robert Field wrote:
> Testing on full systems (with both open and closed) are failing 
> because "import o<tab>" completes with "oracle" in addition to the 
> expected "org".
> There is already a test for "import c<tab>", so this case is not 
> needed -- imply removing it addresses the issue.
> Please review...
>
> Bug:
>
>     https://bugs.openjdk.java.net/browse/JDK-8176241
>
> Webrev:
>
>     http://cr.openjdk.java.net/~rfield/8176241v0.webrev/
>
> Diff...
>
>
> diff -r 173dd02c493c test/jdk/jshell/CompletionSuggestionTest.java
> --- a/test/jdk/jshell/CompletionSuggestionTest.java     Mon Mar 06 
> 08:36:05 2017 -0800
> +++ b/test/jdk/jshell/CompletionSuggestionTest.java     Mon Mar 06 
> 15:33:52 2017 -0800
> @@ -23,7 +23,7 @@
>
>  /*
>   * @test
> - * @bug 8131025 8141092 8153761 8145263 8131019 8175886 8176184
> + * @bug 8131025 8141092 8153761 8145263 8131019 8175886 8176184 8176241
>   * @summary Test Completion and Documentation
>   * @library /tools/lib
>   * @modules jdk.compiler/com.sun.tools.javac.api
> @@ -297,7 +297,6 @@
>
>      public void testImportStart() {
>          assertCompletion("import c|", "com");
> -        assertCompletion("import o|", "org");
>      }
>
>      public void testBrokenClassFile() throws Exception {
>


From brian.oliver at oracle.com  Wed Mar  8 12:23:15 2017
From: brian.oliver at oracle.com (Brian Oliver)
Date: Wed, 8 Mar 2017 07:23:15 -0500
Subject: How to specify System Properties when launching JShell?
Message-ID: <39789108-9E4E-4AD1-829C-39269E5C8E02@oracle.com>

Hi All,

I?m starting to use JShell (awesome btw) but can?t find any documentation on how to specify a system property on start up.

Specifically I want to set:

	java.net.preferIPv4Stack=true

While I can specify a system property by invoking:

	System.setProperty(?);

This basically ignores all JVM-level properties.

Ideally I?d like to specify them when setting up the environment, but it?s not clear how to do this.

Thanks

? Brian

PS: My apologies if this has been answered, but I can?t find it or any documentation on the subject.

Brian Oliver | Architect | brian.oliver at oracle.com
Oracle Coherence Development
35 Network Dr | Burlington, MA 01803




From logan at gedanken.org  Wed Mar  8 15:45:34 2017
From: logan at gedanken.org (Logan O'Sullivan Bruns)
Date: Wed, 8 Mar 2017 07:45:34 -0800
Subject: dumb terminal support for jshell
Message-ID: <20170308074534.00006d14@gedanken.org>

Hi,

I just signed the OCA and had a couple of questions on how to best get
started. Most immediately there is a bug I was hoping to help fix.
Partly because it impacts folks like myself use Emacs heavily.

I've noticed that jshell in jdk9 doesn't currently work
well within the shell mode of Emacs. A very minor change to
the terminal handling fixes this and I have a patch for the change.

My trivial patch changes ConsoleIOContext to look at the TERM
environment variable and, if set to "dumb", to use the TestTerminal
instead of one of the platform specific terminals that won't work in an
Emacs buffer or comparable dumb terminal. I was tempted to make the
patch a little better by renaming the TestTerminal to DumbTerminal
since it would then be used for both the test case and the case where a
dumb terminal is requested explicitly via the TERM environment
variable.

I understand that it is probably too late to get it into jdk9 but I'm
wondering if there is someone I could work with to get this change into
jdk10 in either form proposed above and the perhaps into jdk9
eventually. I know the group of Emacs lovers in the world is dwindling
but I'm sure more than just myself would appreciate this being fixed.

For other projects I might find a bug or enhancement
possibility. Fix and test it. File a bug mentioning that I also have a
suggested fix. Then create a pull request referencing the bug.

In this case, I've signed the OCA but I don't see a way to create a
bug? There doesn't seem to be a way to create an account on the bug
database? Where would be the best place to start?

Thanks,
  logan

From logan at gedanken.org  Wed Mar  8 15:48:40 2017
From: logan at gedanken.org (Logan O'Sullivan Bruns)
Date: Wed, 8 Mar 2017 07:48:40 -0800
Subject: dumb terminal support for jshell
In-Reply-To: <20170308074534.00006d14@gedanken.org>
References: <20170308074534.00006d14@gedanken.org>
Message-ID: <20170308074840.00004803@gedanken.org>

Please ignore the last two paragraphs. Sorry. I accidentally reused part
of my email to discuss. Other folks have already explained the process
around bug reporting and such which lead me to this email list.

Thanks,
  logan

On Wed, 8 Mar 2017 07:45:34 -0800
Logan O'Sullivan Bruns <logan at gedanken.org> wrote:

> Hi,
> 
> I just signed the OCA and had a couple of questions on how to best get
> started. Most immediately there is a bug I was hoping to help fix.
> Partly because it impacts folks like myself use Emacs heavily.
> 
> I've noticed that jshell in jdk9 doesn't currently work
> well within the shell mode of Emacs. A very minor change to
> the terminal handling fixes this and I have a patch for the change.
> 
> My trivial patch changes ConsoleIOContext to look at the TERM
> environment variable and, if set to "dumb", to use the TestTerminal
> instead of one of the platform specific terminals that won't work in
> an Emacs buffer or comparable dumb terminal. I was tempted to make the
> patch a little better by renaming the TestTerminal to DumbTerminal
> since it would then be used for both the test case and the case where
> a dumb terminal is requested explicitly via the TERM environment
> variable.
> 
> I understand that it is probably too late to get it into jdk9 but I'm
> wondering if there is someone I could work with to get this change
> into jdk10 in either form proposed above and the perhaps into jdk9
> eventually. I know the group of Emacs lovers in the world is dwindling
> but I'm sure more than just myself would appreciate this being fixed.
> 
> For other projects I might find a bug or enhancement
> possibility. Fix and test it. File a bug mentioning that I also have a
> suggested fix. Then create a pull request referencing the bug.
> 
> In this case, I've signed the OCA but I don't see a way to create a
> bug? There doesn't seem to be a way to create an account on the bug
> database? Where would be the best place to start?
> 
> Thanks,
>   logan


From robert.field at oracle.com  Wed Mar  8 17:14:34 2017
From: robert.field at oracle.com (Robert Field)
Date: Wed, 8 Mar 2017 09:14:34 -0800
Subject: How to specify System Properties when launching JShell?
In-Reply-To: <39789108-9E4E-4AD1-829C-39269E5C8E02@oracle.com>
References: <39789108-9E4E-4AD1-829C-39269E5C8E02@oracle.com>
Message-ID: <92894B1D-E87D-4BF3-A294-4FCF4E8903F7@oracle.com>

Hi Brian,

JShell executes user code in a remote process.  To send arguments to that remote process use the ?-R? flag.

So, if you would launch:

    java -Djava.net.preferIPv4Stack=true MyProg

Then you would launch the jshell tool with:

    jshell -R-Djava.net.preferIPv4Stack=true

See:

    jshell ?help

Hope that helps,
Robert

> On Mar 8, 2017, at 4:23 AM, Brian Oliver <brian.oliver at oracle.com> wrote:
> 
> Hi All,
> 
> I?m starting to use JShell (awesome btw) but can?t find any documentation on how to specify a system property on start up.
> 
> Specifically I want to set:
> 
> 	java.net.preferIPv4Stack=true
> 
> While I can specify a system property by invoking:
> 
> 	System.setProperty(?);
> 
> This basically ignores all JVM-level properties.
> 
> Ideally I?d like to specify them when setting up the environment, but it?s not clear how to do this.
> 
> Thanks
> 
> ? Brian
> 
> PS: My apologies if this has been answered, but I can?t find it or any documentation on the subject.
> 
> Brian Oliver | Architect | brian.oliver at oracle.com
> Oracle Coherence Development
> 35 Network Dr | Burlington, MA 01803
> 
> 
> 


From brian.oliver at oracle.com  Wed Mar  8 17:41:04 2017
From: brian.oliver at oracle.com (Brian Oliver)
Date: Wed, 8 Mar 2017 12:41:04 -0500
Subject: How to specify System Properties when launching JShell?
In-Reply-To: <92894B1D-E87D-4BF3-A294-4FCF4E8903F7@oracle.com>
References: <39789108-9E4E-4AD1-829C-39269E5C8E02@oracle.com>
 <92894B1D-E87D-4BF3-A294-4FCF4E8903F7@oracle.com>
Message-ID: <4F3B30C1-A937-419D-A384-04DE0BCDAD92@oracle.com>

Hi Robert,

Thanks for getting back to be so quickly.   It worked perfectly!

Next step is to see if I can do some remote lambdas across a distributed collection (aka: Coherence)

? Brian

> On Mar 8, 2017, at 12:14 PM, Robert Field <robert.field at oracle.com> wrote:
> 
> Hi Brian,
> 
> JShell executes user code in a remote process.  To send arguments to that remote process use the ?-R? flag.
> 
> So, if you would launch:
> 
>    java -Djava.net.preferIPv4Stack=true MyProg
> 
> Then you would launch the jshell tool with:
> 
>    jshell -R-Djava.net.preferIPv4Stack=true
> 
> See:
> 
>    jshell ?help
> 
> Hope that helps,
> Robert
> 
>> On Mar 8, 2017, at 4:23 AM, Brian Oliver <brian.oliver at oracle.com> wrote:
>> 
>> Hi All,
>> 
>> I?m starting to use JShell (awesome btw) but can?t find any documentation on how to specify a system property on start up.
>> 
>> Specifically I want to set:
>> 
>> 	java.net.preferIPv4Stack=true
>> 
>> While I can specify a system property by invoking:
>> 
>> 	System.setProperty(?);
>> 
>> This basically ignores all JVM-level properties.
>> 
>> Ideally I?d like to specify them when setting up the environment, but it?s not clear how to do this.
>> 
>> Thanks
>> 
>> ? Brian
>> 
>> PS: My apologies if this has been answered, but I can?t find it or any documentation on the subject.
>> 
>> Brian Oliver | Architect | brian.oliver at oracle.com
>> Oracle Coherence Development
>> 35 Network Dr | Burlington, MA 01803
>> 
>> 
>> 
> 


From jan.lahoda at oracle.com  Wed Mar  8 17:53:07 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 8 Mar 2017 18:53:07 +0100
Subject: dumb terminal support for jshell
In-Reply-To: <20170308074534.00006d14@gedanken.org>
References: <20170308074534.00006d14@gedanken.org>
Message-ID: <58C04503.5050602@oracle.com>

Hi Logan,

I've filled:
https://bugs.openjdk.java.net/browse/JDK-8176391

Jan

On 8.3.2017 16:45, Logan O'Sullivan Bruns wrote:
> Hi,
>
> I just signed the OCA and had a couple of questions on how to best get
> started. Most immediately there is a bug I was hoping to help fix.
> Partly because it impacts folks like myself use Emacs heavily.
>
> I've noticed that jshell in jdk9 doesn't currently work
> well within the shell mode of Emacs. A very minor change to
> the terminal handling fixes this and I have a patch for the change.
>
> My trivial patch changes ConsoleIOContext to look at the TERM
> environment variable and, if set to "dumb", to use the TestTerminal
> instead of one of the platform specific terminals that won't work in an
> Emacs buffer or comparable dumb terminal. I was tempted to make the
> patch a little better by renaming the TestTerminal to DumbTerminal
> since it would then be used for both the test case and the case where a
> dumb terminal is requested explicitly via the TERM environment
> variable.
>
> I understand that it is probably too late to get it into jdk9 but I'm
> wondering if there is someone I could work with to get this change into
> jdk10 in either form proposed above and the perhaps into jdk9
> eventually. I know the group of Emacs lovers in the world is dwindling
> but I'm sure more than just myself would appreciate this being fixed.
>
> For other projects I might find a bug or enhancement
> possibility. Fix and test it. File a bug mentioning that I also have a
> suggested fix. Then create a pull request referencing the bug.
>
> In this case, I've signed the OCA but I don't see a way to create a
> bug? There doesn't seem to be a way to create an account on the bug
> database? Where would be the best place to start?
>
> Thanks,
>    logan
>

From brian.oliver at oracle.com  Wed Mar  8 17:54:47 2017
From: brian.oliver at oracle.com (Brian Oliver)
Date: Wed, 8 Mar 2017 11:54:47 -0600
Subject: RemoteClassLoader doesn't provide ClassFile information for Lambdas
In-Reply-To: <mailman.4098.1488994891.26058.kulla-dev@openjdk.java.net>
References: <mailman.4098.1488994891.26058.kulla-dev@openjdk.java.net>
Message-ID: <5760E4F2-A6A9-4127-849B-502CDD1AB51A@oracle.com>

I?m attempting to use JShell with Coherence (for distributed lambdas / distributed streams) and I?ve noticed that some lambda expressions defined by the Shell are not available / resolvable via the RemoteClassLoader as expected.

For example:  (assume RockStars is a Map<UID, String> where the String is ?firstname lastname?)

The following attempts to determine the distinct number of rockstar last names.

jshell> rockstars.stream().map(e -> e.getValue().split(" ")[1]).distinct().count();
|  java.lang.IllegalStateException thrown: ClassFile for the remote lambda could not be introspected. jdk.jshell.execution.DefaultLoaderDelegate$RemoteClassLoader at 91161c7.getResource(REPL/$JShell$20.class) unexpectedly returned null
|        at RemotableSupport.createRemoteConstructor (RemotableSupport.java:82)
|        at Lambdas.ensureRemotable (Lambdas.java:205)
|        at RemoteStream.map (RemoteStream.java:154)
|        at (#10:1)

Coherence is asking for the ClassFile instance in which a (remote) lambda is defined, but it?s not available via the RemoteClassLoader.

I?m wondering if the DefaultLoaderDelegate$RemoteClassLoader is missing support for resolving Lambdas?

Without this support we can?t really demonstrate using remote / distributed lambdas / distributed lambdas across a Cloud - which would be very helpful!

Thoughts?

? Brian

From logan at gedanken.org  Wed Mar  8 20:15:25 2017
From: logan at gedanken.org (Logan O'Sullivan Bruns)
Date: Wed, 08 Mar 2017 12:15:25 -0800
Subject: dumb terminal support for jshell
Message-ID: <ou8yeb3je0mgwic2trtoh0oq.1489004125026@email.android.com>


    
Thanks Jan. Would it be possible for me to work with you on a patch?
? - logan


Sent from my T-Mobile 4G LTE Device

-------- Original message --------
From: Jan Lahoda <jan.lahoda at oracle.com> 
Date: 3/8/17  9:53 AM  (GMT-08:00) 
To: Logan O'Sullivan Bruns <logan at gedanken.org>, kulla-dev at openjdk.java.net 
Subject: Re: dumb terminal support for jshell 

Hi Logan,

I've filled:
https://bugs.openjdk.java.net/browse/JDK-8176391

Jan

On 8.3.2017 16:45, Logan O'Sullivan Bruns wrote:
> Hi,
>
> I just signed the OCA and had a couple of questions on how to best get
> started. Most immediately there is a bug I was hoping to help fix.
> Partly because it impacts folks like myself use Emacs heavily.
>
> I've noticed that jshell in jdk9 doesn't currently work
> well within the shell mode of Emacs. A very minor change to
> the terminal handling fixes this and I have a patch for the change.
>
> My trivial patch changes ConsoleIOContext to look at the TERM
> environment variable and, if set to "dumb", to use the TestTerminal
> instead of one of the platform specific terminals that won't work in an
> Emacs buffer or comparable dumb terminal. I was tempted to make the
> patch a little better by renaming the TestTerminal to DumbTerminal
> since it would then be used for both the test case and the case where a
> dumb terminal is requested explicitly via the TERM environment
> variable.
>
> I understand that it is probably too late to get it into jdk9 but I'm
> wondering if there is someone I could work with to get this change into
> jdk10 in either form proposed above and the perhaps into jdk9
> eventually. I know the group of Emacs lovers in the world is dwindling
> but I'm sure more than just myself would appreciate this being fixed.
>
> For other projects I might find a bug or enhancement
> possibility. Fix and test it. File a bug mentioning that I also have a
> suggested fix. Then create a pull request referencing the bug.
>
> In this case, I've signed the OCA but I don't see a way to create a
> bug? There doesn't seem to be a way to create an account on the bug
> database? Where would be the best place to start?
>
> Thanks,
>??? logan
>

From robert.field at oracle.com  Thu Mar  9 03:16:07 2017
From: robert.field at oracle.com (Robert Field)
Date: Wed, 08 Mar 2017 19:16:07 -0800
Subject: RemoteClassLoader doesn't provide ClassFile information for
 Lambdas
In-Reply-To: <5760E4F2-A6A9-4127-849B-502CDD1AB51A@oracle.com>
References: <mailman.4098.1488994891.26058.kulla-dev@openjdk.java.net>
 <5760E4F2-A6A9-4127-849B-502CDD1AB51A@oracle.com>
Message-ID: <58C0C8F7.6080106@oracle.com>

Ah!

What is going on has nothing to do with lambdas.

The "RemotableSupport" code is requesting the URL (via getResource) of 
an internal generated JShell wrapper class (user code is wrapped up in a 
synthetic class).  This class file is intentionally never made visible 
(file system or otherwise).
It thus has no corresponding URL, and getResource returns null.

This can be seen with the following executed in a jshell started with 
--no-startup

     class C { }
C.class.getClassLoader().loadClass("REPL.$JShell$1").getDeclaredClasses()
     C.class.getClassLoader().getResource("REPL/$JShell$1.class")

I suspect it would be hard to work around this, but it would definitely 
be cool to be able to demo Coherence in JShell.

Robert



On 03/08/17 09:54, Brian Oliver wrote:
> I?m attempting to use JShell with Coherence (for distributed lambdas / distributed streams) and I?ve noticed that some lambda expressions defined by the Shell are not available / resolvable via the RemoteClassLoader as expected.
>
> For example:  (assume RockStars is a Map<UID, String> where the String is ?firstname lastname?)
>
> The following attempts to determine the distinct number of rockstar last names.
>
> jshell> rockstars.stream().map(e -> e.getValue().split(" ")[1]).distinct().count();
> |  java.lang.IllegalStateException thrown: ClassFile for the remote lambda could not be introspected. jdk.jshell.execution.DefaultLoaderDelegate$RemoteClassLoader at 91161c7.getResource(REPL/$JShell$20.class) unexpectedly returned null
> |        at RemotableSupport.createRemoteConstructor (RemotableSupport.java:82)
> |        at Lambdas.ensureRemotable (Lambdas.java:205)
> |        at RemoteStream.map (RemoteStream.java:154)
> |        at (#10:1)
>
> Coherence is asking for the ClassFile instance in which a (remote) lambda is defined, but it?s not available via the RemoteClassLoader.
>
> I?m wondering if the DefaultLoaderDelegate$RemoteClassLoader is missing support for resolving Lambdas?
>
> Without this support we can?t really demonstrate using remote / distributed lambdas / distributed lambdas across a Cloud - which would be very helpful!
>
> Thoughts?
>
> ? Brian


From robert.field at oracle.com  Thu Mar  9 04:13:59 2017
From: robert.field at oracle.com (Robert Field)
Date: Wed, 08 Mar 2017 20:13:59 -0800
Subject: RFR 8176412: jshell tool: automatic imports are excluded on /reload
 causing it to fail
Message-ID: <58C0D687.8070304@oracle.com>

Imports "automatically" added by <fix-shortcut> i or <fix-shortcut> v 
(where <fix-shortcut> is usually Alt-F1 or Alt-Enter) are not added to 
the history, and thus aren't reloaded on /reload or /env.
This causes such /reload or /env to fail with errors.
Fix by having the eval go through higher level entry points in the 
JShellTool.  Make the low-level JShell state private to the tool, by 
adding an access point for the one remaining state access "stop()".
Side-effects:
   In the unlikely/impossible case that the import fails, an error will 
be displayed (which is better than silent failure).
   If the user defines a feedback mode that gives feedback on import, 
the feedback will be displayed on auto-import.  This works fine (I have 
tested) since the line is redrawn.

Please review....

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8176412

Webrev:

     http://cr.openjdk.java.net/~rfield/8176412v0.webrev/

Thanks,
Robert


From benjamin.john.evans at gmail.com  Thu Mar  9 14:25:05 2017
From: benjamin.john.evans at gmail.com (Ben Evans)
Date: Thu, 9 Mar 2017 14:25:05 +0000
Subject: dumb terminal support for jshell
In-Reply-To: <ou8yeb3je0mgwic2trtoh0oq.1489004125026@email.android.com>
References: <ou8yeb3je0mgwic2trtoh0oq.1489004125026@email.android.com>
Message-ID: <CABKW8RgML5y9PD4a6Eka4MEKGho67ccrbrT8eULG4PVd4-5gJw@mail.gmail.com>

Hi Logan,

Looking at the bug, it's listed at P4. Now, if I'm reading the project
schedule right, that means it shouldn't be fixed in the JDK 9 repos
until after the GA release (end of July).

However, the JDK 10 repos are open. So, I suggest that you bring your
patch over to AdoptOpenJDK - where we can help you work on a patch and
get it into a decent shape so that when the committers are a bit less
hectic, we can hopefully get it into the JDK 10 repo, and then
backport to a 9 Update once the GA release of 9 is out (if
appropriate).

Does that work? It's a bit more complex than usual, but that's because
we're so close to the release of 9.

Thanks,

Ben

On Wed, Mar 8, 2017 at 8:15 PM, Logan O'Sullivan Bruns
<logan at gedanken.org> wrote:
>
>
> Thanks Jan. Would it be possible for me to work with you on a patch?
>   - logan
>
>
> Sent from my T-Mobile 4G LTE Device
>
> -------- Original message --------
> From: Jan Lahoda <jan.lahoda at oracle.com>
> Date: 3/8/17  9:53 AM  (GMT-08:00)
> To: Logan O'Sullivan Bruns <logan at gedanken.org>, kulla-dev at openjdk.java.net
> Subject: Re: dumb terminal support for jshell
>
> Hi Logan,
>
> I've filled:
> https://bugs.openjdk.java.net/browse/JDK-8176391
>
> Jan
>
> On 8.3.2017 16:45, Logan O'Sullivan Bruns wrote:
>> Hi,
>>
>> I just signed the OCA and had a couple of questions on how to best get
>> started. Most immediately there is a bug I was hoping to help fix.
>> Partly because it impacts folks like myself use Emacs heavily.
>>
>> I've noticed that jshell in jdk9 doesn't currently work
>> well within the shell mode of Emacs. A very minor change to
>> the terminal handling fixes this and I have a patch for the change.
>>
>> My trivial patch changes ConsoleIOContext to look at the TERM
>> environment variable and, if set to "dumb", to use the TestTerminal
>> instead of one of the platform specific terminals that won't work in an
>> Emacs buffer or comparable dumb terminal. I was tempted to make the
>> patch a little better by renaming the TestTerminal to DumbTerminal
>> since it would then be used for both the test case and the case where a
>> dumb terminal is requested explicitly via the TERM environment
>> variable.
>>
>> I understand that it is probably too late to get it into jdk9 but I'm
>> wondering if there is someone I could work with to get this change into
>> jdk10 in either form proposed above and the perhaps into jdk9
>> eventually. I know the group of Emacs lovers in the world is dwindling
>> but I'm sure more than just myself would appreciate this being fixed.
>>
>> For other projects I might find a bug or enhancement
>> possibility. Fix and test it. File a bug mentioning that I also have a
>> suggested fix. Then create a pull request referencing the bug.
>>
>> In this case, I've signed the OCA but I don't see a way to create a
>> bug? There doesn't seem to be a way to create an account on the bug
>> database? Where would be the best place to start?
>>
>> Thanks,
>>    logan
>>

From jan.lahoda at oracle.com  Thu Mar  9 14:33:54 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 9 Mar 2017 15:33:54 +0100
Subject: dumb terminal support for jshell
In-Reply-To: <ou8yeb3je0mgwic2trtoh0oq.1489004125026@email.android.com>
References: <ou8yeb3je0mgwic2trtoh0oq.1489004125026@email.android.com>
Message-ID: <58C167D2.9050109@oracle.com>

Hi Logan,

Sure - if you have something, please send it. May first need to go to 10 
and then be backported to a 9 update, though.

Jan

On 8.3.2017 21:15, Logan O'Sullivan Bruns wrote:
> Thanks Jan. Would it be possible for me to work with you on a patch?
>
>    - logan
>
>
>
> Sent from my T-Mobile 4G LTE Device
>
>
> -------- Original message --------
> From: Jan Lahoda <jan.lahoda at oracle.com>
> Date: 3/8/17 9:53 AM (GMT-08:00)
> To: Logan O'Sullivan Bruns <logan at gedanken.org>, kulla-dev at openjdk.java.net
> Subject: Re: dumb terminal support for jshell
>
> Hi Logan,
>
> I've filled:
> https://bugs.openjdk.java.net/browse/JDK-8176391
>
> Jan
>
> On 8.3.2017 16:45, Logan O'Sullivan Bruns wrote:
>  > Hi,
>  >
>  > I just signed the OCA and had a couple of questions on how to best get
>  > started. Most immediately there is a bug I was hoping to help fix.
>  > Partly because it impacts folks like myself use Emacs heavily.
>  >
>  > I've noticed that jshell in jdk9 doesn't currently work
>  > well within the shell mode of Emacs. A very minor change to
>  > the terminal handling fixes this and I have a patch for the change.
>  >
>  > My trivial patch changes ConsoleIOContext to look at the TERM
>  > environment variable and, if set to "dumb", to use the TestTerminal
>  > instead of one of the platform specific terminals that won't work in an
>  > Emacs buffer or comparable dumb terminal. I was tempted to make the
>  > patch a little better by renaming the TestTerminal to DumbTerminal
>  > since it would then be used for both the test case and the case where a
>  > dumb terminal is requested explicitly via the TERM environment
>  > variable.
>  >
>  > I understand that it is probably too late to get it into jdk9 but I'm
>  > wondering if there is someone I could work with to get this change into
>  > jdk10 in either form proposed above and the perhaps into jdk9
>  > eventually. I know the group of Emacs lovers in the world is dwindling
>  > but I'm sure more than just myself would appreciate this being fixed.
>  >
>  > For other projects I might find a bug or enhancement
>  > possibility. Fix and test it. File a bug mentioning that I also have a
>  > suggested fix. Then create a pull request referencing the bug.
>  >
>  > In this case, I've signed the OCA but I don't see a way to create a
>  > bug? There doesn't seem to be a way to create an account on the bug
>  > database? Where would be the best place to start?
>  >
>  > Thanks,
>  >    logan
>  >

From jan.lahoda at oracle.com  Thu Mar  9 16:16:30 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 9 Mar 2017 17:16:30 +0100
Subject: RFR 8176412: jshell tool: automatic imports are excluded on
 /reload causing it to fail
In-Reply-To: <58C0D687.8070304@oracle.com>
References: <58C0D687.8070304@oracle.com>
Message-ID: <58C17FDE.2090501@oracle.com>

Seems OK to me.

Jan

On 9.3.2017 05:13, Robert Field wrote:
> Imports "automatically" added by <fix-shortcut> i or <fix-shortcut> v
> (where <fix-shortcut> is usually Alt-F1 or Alt-Enter) are not added to
> the history, and thus aren't reloaded on /reload or /env.
> This causes such /reload or /env to fail with errors.
> Fix by having the eval go through higher level entry points in the
> JShellTool.  Make the low-level JShell state private to the tool, by
> adding an access point for the one remaining state access "stop()".
> Side-effects:
>    In the unlikely/impossible case that the import fails, an error will
> be displayed (which is better than silent failure).
>    If the user defines a feedback mode that gives feedback on import,
> the feedback will be displayed on auto-import.  This works fine (I have
> tested) since the line is redrawn.
>
> Please review....
>
> Bug:
>
>      https://bugs.openjdk.java.net/browse/JDK-8176412
>
> Webrev:
>
>      http://cr.openjdk.java.net/~rfield/8176412v0.webrev/
>
> Thanks,
> Robert
>

From brian.oliver at oracle.com  Fri Mar 10 23:04:07 2017
From: brian.oliver at oracle.com (Brian Oliver)
Date: Fri, 10 Mar 2017 18:04:07 -0500
Subject: RemoteClassLoader doesn't provide ClassFile information for
 Lambdas
Message-ID: <4804BA4D-F392-4173-AD7B-A656A679BC98@oracle.com>

Hi Robert,

So it?s seems that any dynamically created or referenced serializable class, abstract, anonymous, lambda, method reference can?t be serialized.

eg: I replaced by previous example with a simple stateless serializable anonymous inner-class and it failed to be loaded.  I also tried to use method references and they too failed to be located.   

I guess the synthetic wrapping of classes is causing this problem, which is unfortunate as these things work perfectly fine with ?regular? compiled Java.

I wonder if there?s some way around this?   Why can?t the RemoteClassLoader provide the underlying bytecode for the wrapped class?

As it stands, I don?t think we or anyone else that wants serializable lambdas can use JShell.

? Brian

people.compute("Brian", new Remote.BiFunction<String, String, String>() { public String apply(String key, String value) { return "Byrd"; } });
|  com.tangosol.util.WrapperException thrown: (Wrapped: Failed request execution for PartitionedCache service on Member(Id=2, Timestamp=2017-03-10 17:48:50.069, Address=127.0.0.1:50597, MachineId=10131, Location=machine:localhost,process:1563, Role=CoherenceServer) (Wrapped) readObject failed: java.lang.ClassNotFoundException: REPL.$JShell$22$1
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:533)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:186)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:476)
	at java.base/java.lang.Class.forName0(Native Method)
	at java.base/java.lang.Class.forName(Class.java:375)
	at java.base/java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:685)
	at com.tangosol.io.ResolvingObjectInputStream.resolveClass(ResolvingObjectInputStream.java:66)
	at java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1841)
	at java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1735)
	at java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2008)
	at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1557)
	at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:422)
	at com.tangosol.util.ExternalizableHelper.readSerializable(ExternalizableHelper.java:2445)
	at com.tangosol.util.ExternalizableHelper.readObjectInternal(ExternalizableHelper.java:2582)
	at com.tangosol.util.ExternalizableHelper.readObject(ExternalizableHelper.java:2524)
	at com.tangosol.util.ExternalizableHelper.readObject(ExternalizableHelper.java:2502)
	at com.tangosol.internal.util.invoke.RemoteConstructor.readExternal(RemoteConstructor.java:182)
	at com.tangosol.util.ExternalizableHelper.readExternalizableLite(ExternalizableHelper.java:2265)
	at com.tangosol.util.ExternalizableHelper.readObjectInternal(ExternalizableHelper.java:2579)
	at com.tangosol.util.ExternalizableHelper.deserializeInternal(ExternalizableHelper.java:3098)
	at com.tangosol.util.ExternalizableHelper.fromBinary(ExternalizableHelper.java:334)
	at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.partitionedService.PartitionedCache$InvokeRequest.deserializeProcessor(PartitionedCache.CDB:7)
	at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.partitionedService.PartitionedCache.onInvokeRequest(PartitionedCache.CDB:47)
	at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.partitionedService.PartitionedCache$InvokeRequest.run(PartitionedCache.CDB:1)
	at com.tangosol.coherence.component.util.DaemonPool$WrapperTask.run(DaemonPool.CDB:1)
	at com.tangosol.coherence.component.util.DaemonPool$WrapperTask.run(DaemonPool.CDB:32)
	at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.PartitionedService$DaemonPool$WrapperTask.run(PartitionedService.CDB:1)
	at com.tangosol.coherence.component.util.DaemonPool$Daemon.onNotify(DaemonPool.CDB:66)
	at com.tangosol.coherence.component.util.Daemon.run(Daemon.CDB:54)
	at java.base/java.lang.Thread.run(Thread.java:844)

ClassLoader: null) readObject failed: java.lang.ClassNotFoundException: REPL.$JShell$22$1
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:533)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:186)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:476)
	at java.base/java.lang.Class.forName0(Native Method)
	at java.base/java.lang.Class.forName(Class.java:375)
	at java.base/java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:685)
	at com.tangosol.io.ResolvingObjectInputStream.resolveClass(ResolvingObjectInputStream.java:66)
	at java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1841)
	at java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1735)
	at java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2008)
	at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1557)
	at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:422)
	at com.tangosol.util.ExternalizableHelper.readSerializable(ExternalizableHelper.java:2445)
	at com.tangosol.util.ExternalizableHelper.readObjectInternal(ExternalizableHelper.java:2582)
	at com.tangosol.util.ExternalizableHelper.readObject(ExternalizableHelper.java:2524)
	at com.tangosol.util.ExternalizableHelper.readObject(ExternalizableHelper.java:2502)
	at com.tangosol.internal.util.invoke.RemoteConstructor.readExternal(RemoteConstructor.java:182)
	at com.tangosol.util.ExternalizableHelper.readExternalizableLite(ExternalizableHelper.java:2265)
	at com.tangosol.util.ExternalizableHelper.readObjectInternal(ExternalizableHelper.java:2579)
	at com.tangosol.util.ExternalizableHelper.deserializeInternal(ExternalizableHelper.java:3098)
	at com.tangosol.util.ExternalizableHelper.fromBinary(ExternalizableHelper.java:334)
	at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.partitionedService.PartitionedCache$InvokeRequest.deserializeProcessor(PartitionedCache.CDB:7)
	at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.partitionedService.PartitionedCache.onInvokeRequest(PartitionedCache.CDB:47)
	at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.partitionedService.PartitionedCache$InvokeRequest.run(PartitionedCache.CDB:1)
	at com.tangosol.coherence.component.util.DaemonPool$WrapperTask.run(DaemonPool.CDB:1)
	at com.tangosol.coherence.component.util.DaemonPool$WrapperTask.run(DaemonPool.CDB:32)
	at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.PartitionedService$DaemonPool$WrapperTask.run(PartitionedService.CDB:1)
	at com.tangosol.coherence.component.util.DaemonPool$Daemon.onNotify(DaemonPool.CDB:66)
	at com.tangosol.coherence.component.util.Daemon.run(Daemon.CDB:54)
	at java.base/java.lang.Thread.run(Thread.java:844)

ClassLoader: null
|        at Base.ensureRuntimeException (Base.java:296)
|        at Grid.tagException (Grid.CDB:61)
|        at PartitionedCache.onInvokeRequest (PartitionedCache.CDB:92)
|        at PartitionedCache$InvokeRequest.run (PartitionedCache.CDB:1)
|        at DaemonPool$WrapperTask.run (DaemonPool.CDB:1)
|        at DaemonPool$WrapperTask.run (DaemonPool.CDB:32)
|        at PartitionedService$DaemonPool$WrapperTask.run (PartitionedService.CDB:1)
|        at DaemonPool$Daemon.onNotify (DaemonPool.CDB:66)
|        at Daemon.run (Daemon.CDB:54)
|        at Thread.run (Thread.java:844)












From robert.field at oracle.com  Sat Mar 18 18:39:56 2017
From: robert.field at oracle.com (Robert Field)
Date: Sat, 18 Mar 2017 11:39:56 -0700
Subject: jshell tool: survey on keystroke functionality -- your input requested
Message-ID: <58CD7EFC.4040100@oracle.com>

A usability question is being hotly debated internally.   I'd love 
community input.
I'll give background.  If you understand that you can skip to the question.
Please email your choice with or without discussion.

BACKGROUND

There are currently these JShell-specific 
completion/information/transformation keystrokes --

tab [complete]:  completes an identifier (if there is a unique 
completion), does no or partial completion and provides a list of 
possible completion (if there are multiple completions)

shift-tab [info]: when the cursor is positioned after the open 
parenthesis of a method call, lists the matching method signatures. if 
pressed again, displays the javadoc for the first matching signature 
(prompting to display further)

Alt-F1 or Alt-Enter (depending on platform) [codegen]:  when followed by 
"i", prompts to auto-import the identifier before the cursor.  when 
followed by "v" converts the expression before the cursor into a 
variable declaration with the expression as initializer

USER MODELS

Current:  tab does completion, shift-tab gives information

Alternative (tab is used for both [complete] and [info]) : tab helps me 
complete -- either directly completing or giving me information that 
helps me complete

ARGUMENTS

Current:
     cleanly separates a request to complete the characters in an 
identifier (which is often to save typing) from a request for information

Alternative:
     just want one key to help me code, not different ones in different 
contexts.  This gives better discovery.
     When there isn't a unique completion, tab currently gives 
information, so the distinction isn't that clean.
     Currently shift-tab only works in one specific context, in that 
context the tab completions are usually in the hundreds, thus not very 
useful.
     This frees-up shift-tab for [codegen], eliminating the awkward and 
platform-dependent Alt-F1 or Alt-Enter

QUESTION

Current

    or

Alternative

???



From john.r.rose at oracle.com  Sat Mar 18 19:08:35 2017
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 18 Mar 2017 12:08:35 -0700
Subject: jshell tool: survey on keystroke functionality -- your input
 requested
In-Reply-To: <58CD7EFC.4040100@oracle.com>
References: <58CD7EFC.4040100@oracle.com>
Message-ID: <2223B068-2D78-41BE-9D42-082747EEDF2D@oracle.com>

On Mar 18, 2017, at 11:39 AM, Robert Field <robert.field at oracle.com> wrote:
> 
> Please email your choice with or without discussion.

Vote: #2 alternative

Thanks.

(I'd think of it as:  Tab helps me make progress by either typing for me
or by giving information about what I can type next at the input cursor.
C-Tab helps me transform my code in other ways besides typing more
stuff at the input cursor.  Tab is what I type when I don't know what to
type next, or don't want to think about it because it's too routine.
C-Tab is for the non-routine stuff.)

From michael.mueller at mueller-bruehl.de  Sat Mar 18 19:37:51 2017
From: michael.mueller at mueller-bruehl.de (=?ISO-8859-1?Q?Michael_M=FCller?=)
Date: Sat, 18 Mar 2017 20:37:51 +0100
Subject: jshell tool: survey on keystroke functionality -- your input
 requested
In-Reply-To: <2223B068-2D78-41BE-9D42-082747EEDF2D@oracle.com>
References: <58CD7EFC.4040100@oracle.com>
 <2223B068-2D78-41BE-9D42-082747EEDF2D@oracle.com>
Message-ID: <C60B8BBC-C678-400F-BAF9-EAF542F0B756@mueller-bruehl.de>

Alternative 

Am 18. M?rz 2017 20:08:35 MEZ schrieb John Rose <john.r.rose at oracle.com>:
>On Mar 18, 2017, at 11:39 AM, Robert Field <robert.field at oracle.com>
>wrote:
>> 
>> Please email your choice with or without discussion.
>
>Vote: #2 alternative
>
>Thanks.
>
>(I'd think of it as:  Tab helps me make progress by either typing for
>me
>or by giving information about what I can type next at the input
>cursor.
>C-Tab helps me transform my code in other ways besides typing more
>stuff at the input cursor.  Tab is what I type when I don't know what
>to
>type next, or don't want to think about it because it's too routine.
>C-Tab is for the non-routine stuff.)



Herzliche Gr??e - Best Regards, 

Michael M?ller
Br?hl, Germany
blog.mueller-bruehl.de
it-rezension.de
@muellermi


Read my books
  "Web Development with Java and JSF": https://leanpub.com/jsf
  "Java Lambdas and Parallel Streams": http://www.apress.com/de/book/9781484224861
  "Visitors" a photographic image book: https://leanpub.com/visitors

From kishori.sharan at gmail.com  Sat Mar 18 22:40:04 2017
From: kishori.sharan at gmail.com (Kishori Sharan)
Date: Sat, 18 Mar 2017 17:40:04 -0500
Subject: jshell tool: survey on keystroke functionality -- your input
 requested
In-Reply-To: <58CD7EFC.4040100@oracle.com>
References: <58CD7EFC.4040100@oracle.com>
Message-ID: <CAKDNvg0ufDsJvQxbTN7tpw+68ZkYxBhBpzG3XVbQ526z6UyebA@mail.gmail.com>

Vote: Alternative

Thanks
Kishori


On Sat, Mar 18, 2017 at 1:39 PM, Robert Field <robert.field at oracle.com>
wrote:

> A usability question is being hotly debated internally.   I'd love
> community input.
> I'll give background.  If you understand that you can skip to the question.
> Please email your choice with or without discussion.
>
> BACKGROUND
>
> There are currently these JShell-specific completion/information/transformation
> keystrokes --
>
> tab [complete]:  completes an identifier (if there is a unique
> completion), does no or partial completion and provides a list of possible
> completion (if there are multiple completions)
>
> shift-tab [info]: when the cursor is positioned after the open parenthesis
> of a method call, lists the matching method signatures. if pressed again,
> displays the javadoc for the first matching signature (prompting to display
> further)
>
> Alt-F1 or Alt-Enter (depending on platform) [codegen]:  when followed by
> "i", prompts to auto-import the identifier before the cursor.  when
> followed by "v" converts the expression before the cursor into a variable
> declaration with the expression as initializer
>
> USER MODELS
>
> Current:  tab does completion, shift-tab gives information
>
> Alternative (tab is used for both [complete] and [info]) : tab helps me
> complete -- either directly completing or giving me information that helps
> me complete
>
> ARGUMENTS
>
> Current:
>     cleanly separates a request to complete the characters in an
> identifier (which is often to save typing) from a request for information
>
> Alternative:
>     just want one key to help me code, not different ones in different
> contexts.  This gives better discovery.
>     When there isn't a unique completion, tab currently gives information,
> so the distinction isn't that clean.
>     Currently shift-tab only works in one specific context, in that
> context the tab completions are usually in the hundreds, thus not very
> useful.
>     This frees-up shift-tab for [codegen], eliminating the awkward and
> platform-dependent Alt-F1 or Alt-Enter
>
> QUESTION
>
> Current
>
>    or
>
> Alternative
>
> ???
>
>
>

From michael.mueller at mueller-bruehl.de  Sun Mar 19 07:48:43 2017
From: michael.mueller at mueller-bruehl.de (=?UTF-8?Q?Michael_M=c3=bcller?=)
Date: Sun, 19 Mar 2017 08:48:43 +0100
Subject: List of snippet events
In-Reply-To: <58CD7EFC.4040100@oracle.com>
References: <58CD7EFC.4040100@oracle.com>
Message-ID: <28605ced-5ca8-33a8-ee9e-8c3f1282c6c4@mueller-bruehl.de>

List<SnippetEvent> events = js.eval(input);


input: "int i = 4;" --> one snippet event

input: "for (int i = 1; i < 10; i++) {System.out.println(i);}" --> one 
snippet event

Till now, I every call to eval I made resulted in a list with exactly 
one element. In which situationwill the eval method return a different 
count of elemts?

Or is is one element every time? If yes, why need the result to be a list?


Herzliche Gr??e - Best Regards,

Michael M?ller
Br?hl, Germany
blog.mueller-bruehl.de <http://blog.mueller-bruehl.de/>
it-rezension.de <http://it-rezension.de/>
@muellermi


Read my books
   "Web Development with Java and JSF": https://leanpub.com/jsf
   "Java Lambdas and Parallel Streams": 
http://www.apress.com/de/book/9781484224861
   "Visitors" a photographic image book: https://leanpub.com/visitors


From robert.field at oracle.com  Sun Mar 19 08:37:05 2017
From: robert.field at oracle.com (Robert Field)
Date: Sun, 19 Mar 2017 01:37:05 -0700
Subject: List of snippet events
In-Reply-To: <28605ced-5ca8-33a8-ee9e-8c3f1282c6c4@mueller-bruehl.de>
References: <58CD7EFC.4040100@oracle.com>
 <28605ced-5ca8-33a8-ee9e-8c3f1282c6c4@mueller-bruehl.de>
Message-ID: <15ae5b67768.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>

Good question.

int x, y, z;

Robert




On March 19, 2017 12:48:51 AM Michael M?ller 
<michael.mueller at mueller-bruehl.de> wrote:

> List<SnippetEvent> events = js.eval(input);
>
>
> input: "int i = 4;" --> one snippet event
>
> input: "for (int i = 1; i < 10; i++) {System.out.println(i);}" --> one
> snippet event
>
> Till now, I every call to eval I made resulted in a list with exactly
> one element. In which situationwill the eval method return a different
> count of elemts?
>
> Or is is one element every time? If yes, why need the result to be a list?
>
>
> Herzliche Gr??e - Best Regards,
>
> Michael M?ller
> Br?hl, Germany
> blog.mueller-bruehl.de <http://blog.mueller-bruehl.de/>
> it-rezension.de <http://it-rezension.de/>
> @muellermi
>
>
> Read my books
>    "Web Development with Java and JSF": https://leanpub.com/jsf
>    "Java Lambdas and Parallel Streams":
> http://www.apress.com/de/book/9781484224861
>    "Visitors" a photographic image book: https://leanpub.com/visitors
>

From michael.mueller at mueller-bruehl.de  Sun Mar 19 10:03:34 2017
From: michael.mueller at mueller-bruehl.de (=?UTF-8?Q?Michael_M=c3=bcller?=)
Date: Sun, 19 Mar 2017 11:03:34 +0100
Subject: List of snippet events
In-Reply-To: <15ae5b67768.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
References: <58CD7EFC.4040100@oracle.com>
 <28605ced-5ca8-33a8-ee9e-8c3f1282c6c4@mueller-bruehl.de>
 <15ae5b67768.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
Message-ID: <8969677a-e021-457a-e287-164fd44da4f5@mueller-bruehl.de>

Why generates

int x=3, y=4;

two snippet events, whilst

int x=3; int y=4;

is only one?


Herzliche Gr??e - Best Regards,

Michael M?ller
Br?hl, Germany
blog.mueller-bruehl.de <http://blog.mueller-bruehl.de/>
it-rezension.de <http://it-rezension.de/>
@muellermi


Read my books
   "Web Development with Java and JSF": https://leanpub.com/jsf
   "Java Lambdas and Parallel Streams": 
http://www.apress.com/de/book/9781484224861
   "Visitors" a photographic image book: https://leanpub.com/visitors


On 03/19/2017 09:37 AM, Robert Field wrote:
>
> Good question.
>
> int x, y, z;
>
> Robert
>
> On March 19, 2017 12:48:51 AM Michael M?ller 
> <michael.mueller at mueller-bruehl.de> wrote:
>
>> List<SnippetEvent> events = js.eval(input);
>>
>>
>> input: "int i = 4;" --> one snippet event
>>
>> input: "for (int i = 1; i < 10; i++) {System.out.println(i);}" --> 
>> one snippet event
>>
>> Till now, I every call to eval I made resulted in a list with exactly 
>> one element. In which situationwill the eval method return a 
>> different count of elemts?
>>
>> Or is is one element every time? If yes, why need the result to be a 
>> list?
>>
>>
>> Herzliche Gr??e - Best Regards,
>>
>> Michael M?ller
>> Br?hl, Germany
>> blog.mueller-bruehl.de <http://blog.mueller-bruehl.de/>
>> it-rezension.de <http://it-rezension.de/>
>> @muellermi
>>
>>
>> Read my books
>>   "Web Development with Java and JSF": https://leanpub.com/jsf
>>   "Java Lambdas and Parallel Streams": 
>> http://www.apress.com/de/book/9781484224861
>>   "Visitors" a photographic image book: https://leanpub.com/visitors
>>


From robert.field at oracle.com  Sun Mar 19 14:41:56 2017
From: robert.field at oracle.com (Robert Field)
Date: Sun, 19 Mar 2017 07:41:56 -0700
Subject: List of snippet events
In-Reply-To: <8969677a-e021-457a-e287-164fd44da4f5@mueller-bruehl.de>
References: <58CD7EFC.4040100@oracle.com>
 <28605ced-5ca8-33a8-ee9e-8c3f1282c6c4@mueller-bruehl.de>
 <15ae5b67768.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
 <8969677a-e021-457a-e287-164fd44da4f5@mueller-bruehl.de>
Message-ID: <15ae7047f20.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>

Only the first snippet, int x=3;
Is processed.


On March 19, 2017 3:03:43 AM Michael M?ller 
<michael.mueller at mueller-bruehl.de> wrote:

> Why generates
>
> int x=3, y=4;
>
> two snippet events, whilst
>
> int x=3; int y=4;
>
> is only one?
>
>
> Herzliche Gr??e - Best Regards,
>
> Michael M?ller
> Br?hl, Germany
> blog.mueller-bruehl.de <http://blog.mueller-bruehl.de/>
> it-rezension.de <http://it-rezension.de/>
> @muellermi
>
>
> Read my books
>    "Web Development with Java and JSF": https://leanpub.com/jsf
>    "Java Lambdas and Parallel Streams":
> http://www.apress.com/de/book/9781484224861
>    "Visitors" a photographic image book: https://leanpub.com/visitors
>
>
> On 03/19/2017 09:37 AM, Robert Field wrote:
>>
>> Good question.
>>
>> int x, y, z;
>>
>> Robert
>>
>> On March 19, 2017 12:48:51 AM Michael M?ller
>> <michael.mueller at mueller-bruehl.de> wrote:
>>
>>> List<SnippetEvent> events = js.eval(input);
>>>
>>>
>>> input: "int i = 4;" --> one snippet event
>>>
>>> input: "for (int i = 1; i < 10; i++) {System.out.println(i);}" -->
>>> one snippet event
>>>
>>> Till now, I every call to eval I made resulted in a list with exactly
>>> one element. In which situationwill the eval method return a
>>> different count of elemts?
>>>
>>> Or is is one element every time? If yes, why need the result to be a
>>> list?
>>>
>>>
>>> Herzliche Gr??e - Best Regards,
>>>
>>> Michael M?ller
>>> Br?hl, Germany
>>> blog.mueller-bruehl.de <http://blog.mueller-bruehl.de/>
>>> it-rezension.de <http://it-rezension.de/>
>>> @muellermi
>>>
>>>
>>> Read my books
>>>   "Web Development with Java and JSF": https://leanpub.com/jsf
>>>   "Java Lambdas and Parallel Streams":
>>> http://www.apress.com/de/book/9781484224861
>>>   "Visitors" a photographic image book: https://leanpub.com/visitors
>>>
>

From robert.field at oracle.com  Sun Mar 19 20:47:47 2017
From: robert.field at oracle.com (Robert Field)
Date: Sun, 19 Mar 2017 13:47:47 -0700
Subject: RFR 8177079: jshell tool: usability of /help for commands and
 sub-commands
Message-ID: <58CEEE73.8020009@oracle.com>

Please review...

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8177079

Webrev:

     http://cr.openjdk.java.net/~rfield/8177079v0.webrev/

Thanks,
Robert


From bitterfoxc at gmail.com  Mon Mar 20 05:12:04 2017
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Mon, 20 Mar 2017 14:12:04 +0900
Subject: Sharing integration plugins for maven, gradle, JavaFX
Message-ID: <CAHjBcHMxHgU9c6O_hj_gQvDPTEm_Q3sdRUhK306Rm4YT5pe-4w@mail.gmail.com>

Hi,
Let me share my integration plugins for maven, gradle, JavaFX.

jshell-maven-plugin:
https://github.com/bitterfox/jshell-maven-plugin

jshell-gradle-plugin:
https://github.com/bitterfox/jshell-gradle-plugin

These plugins aim to integrate jshell with maven/gradle to explore in your
codes and dependencies.
When you use these plugins in your maven/gradle project, you can try jshell
with your classes and dependencies.

JavaFXSupportsForJShell
https://github.com/bitterfox/JavaFXSupportsForJShell

This is a library to try JavaFX with jshell, including ExecutionControl and
startup.jsh.

These are still now under developing and early versions like alpha,
prototype or PoC.
Please give me feedback  or comment via github's issue or something like
that.

Thanks,
shinyafox(Shinya Yoshida)

From forax at univ-mlv.fr  Mon Mar 20 09:50:14 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 20 Mar 2017 10:50:14 +0100 (CET)
Subject: Sharing integration plugins for maven, gradle, JavaFX
In-Reply-To: <CAHjBcHMxHgU9c6O_hj_gQvDPTEm_Q3sdRUhK306Rm4YT5pe-4w@mail.gmail.com>
References: <CAHjBcHMxHgU9c6O_hj_gQvDPTEm_Q3sdRUhK306Rm4YT5pe-4w@mail.gmail.com>
Message-ID: <317720166.146344.1490003414743.JavaMail.zimbra@u-pem.fr>

Hi Shinya,
I've done something very similar with my own build tool,
this is really a great way to understand when something goes wrong during the build.

I think those plugins should be integrated/available with gradle/maven,
do you have proposed these enhencement to gradle/maven guys ?

regards,
R?mi

----- Mail original -----
> De: "ShinyaYoshida" <bitterfoxc at gmail.com>
> ?: "Kulla" <kulla-dev at openjdk.java.net>
> Envoy?: Lundi 20 Mars 2017 06:12:04
> Objet: Sharing integration plugins for maven, gradle, JavaFX

> Hi,
> Let me share my integration plugins for maven, gradle, JavaFX.
> 
> jshell-maven-plugin:
> https://github.com/bitterfox/jshell-maven-plugin
> 
> jshell-gradle-plugin:
> https://github.com/bitterfox/jshell-gradle-plugin
> 
> These plugins aim to integrate jshell with maven/gradle to explore in your
> codes and dependencies.
> When you use these plugins in your maven/gradle project, you can try jshell
> with your classes and dependencies.
> 
> JavaFXSupportsForJShell
> https://github.com/bitterfox/JavaFXSupportsForJShell
> 
> This is a library to try JavaFX with jshell, including ExecutionControl and
> startup.jsh.
> 
> These are still now under developing and early versions like alpha,
> prototype or PoC.
> Please give me feedback  or comment via github's issue or something like
> that.
> 
> Thanks,
> shinyafox(Shinya Yoshida)

From bitterfoxc at gmail.com  Mon Mar 20 10:26:49 2017
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Mon, 20 Mar 2017 19:26:49 +0900
Subject: Sharing integration plugins for maven, gradle, JavaFX
In-Reply-To: <317720166.146344.1490003414743.JavaMail.zimbra@u-pem.fr>
References: <CAHjBcHMxHgU9c6O_hj_gQvDPTEm_Q3sdRUhK306Rm4YT5pe-4w@mail.gmail.com>
 <317720166.146344.1490003414743.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAHjBcHNTn5zTLPKj2JkbORxqtY5PmaWLxbVHNSr799YyOH5n0g@mail.gmail.com>

Hi R?mi,
Thank you for your comment.

I also think so, but I've not proposed yet.
I'm planning to do so to maven community because they have some official
plugins which is related JDK tool like jlink, jdeps, jmods, etc.
On the other hand, I'm not now planning it to gradle because it seems that
gradle community leaves a lot parts of plugins to third party.

Regards,
shinyafox(Shinya Yoshida)

2017-03-20 18:50 GMT+09:00 Remi Forax <forax at univ-mlv.fr>:

> Hi Shinya,
> I've done something very similar with my own build tool,
> this is really a great way to understand when something goes wrong during
> the build.
>
> I think those plugins should be integrated/available with gradle/maven,
> do you have proposed these enhencement to gradle/maven guys ?
>
> regards,
> R?mi
>
> ----- Mail original -----
> > De: "ShinyaYoshida" <bitterfoxc at gmail.com>
> > ?: "Kulla" <kulla-dev at openjdk.java.net>
> > Envoy?: Lundi 20 Mars 2017 06:12:04
> > Objet: Sharing integration plugins for maven, gradle, JavaFX
>
> > Hi,
> > Let me share my integration plugins for maven, gradle, JavaFX.
> >
> > jshell-maven-plugin:
> > https://github.com/bitterfox/jshell-maven-plugin
> >
> > jshell-gradle-plugin:
> > https://github.com/bitterfox/jshell-gradle-plugin
> >
> > These plugins aim to integrate jshell with maven/gradle to explore in
> your
> > codes and dependencies.
> > When you use these plugins in your maven/gradle project, you can try
> jshell
> > with your classes and dependencies.
> >
> > JavaFXSupportsForJShell
> > https://github.com/bitterfox/JavaFXSupportsForJShell
> >
> > This is a library to try JavaFX with jshell, including ExecutionControl
> and
> > startup.jsh.
> >
> > These are still now under developing and early versions like alpha,
> > prototype or PoC.
> > Please give me feedback  or comment via github's issue or something like
> > that.
> >
> > Thanks,
> > shinyafox(Shinya Yoshida)
>

From paul.sandoz at oracle.com  Mon Mar 20 17:50:13 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 20 Mar 2017 10:50:13 -0700
Subject: jshell tool: survey on keystroke functionality -- your input
 requested
In-Reply-To: <2223B068-2D78-41BE-9D42-082747EEDF2D@oracle.com>
References: <58CD7EFC.4040100@oracle.com>
 <2223B068-2D78-41BE-9D42-082747EEDF2D@oracle.com>
Message-ID: <DF3964B9-45B3-4E27-9AAC-588B5FF2632F@oracle.com>


> On 18 Mar 2017, at 12:08, John Rose <john.r.rose at oracle.com> wrote:
> 
> On Mar 18, 2017, at 11:39 AM, Robert Field <robert.field at oracle.com> wrote:
>> 
>> Please email your choice with or without discussion.
> 
> Vote: #2 alternative
> 

+1 for the alternative.

The powerful Alt-F1 is indeed a little awkward, having it closer to tab will i think make it far more accessible and i think should just work without additional input if the context is unambiguous, otherwise present the choice to the user.

Paul.

> Thanks.
> 
> (I'd think of it as:  Tab helps me make progress by either typing for me
> or by giving information about what I can type next at the input cursor.
> C-Tab helps me transform my code in other ways besides typing more
> stuff at the input cursor.  Tab is what I type when I don't know what to
> type next, or don't want to think about it because it's too routine.
> C-Tab is for the non-routine stuff.)


From jan.lahoda at oracle.com  Thu Mar 23 18:49:48 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 23 Mar 2017 19:49:48 +0100
Subject: RFR 8177079: jshell tool: usability of /help for commands and
 sub-commands
In-Reply-To: <58CEEE73.8020009@oracle.com>
References: <58CEEE73.8020009@oracle.com>
Message-ID: <58D418CC.4090106@oracle.com>

Seems OK to me.

Jan

On 19.3.2017 21:47, Robert Field wrote:
> Please review...
>
> Bug:
>
>      https://bugs.openjdk.java.net/browse/JDK-8177079
>
> Webrev:
>
>      http://cr.openjdk.java.net/~rfield/8177079v0.webrev/
>
> Thanks,
> Robert
>

From kishori.sharan at gmail.com  Mon Mar 27 03:19:49 2017
From: kishori.sharan at gmail.com (Kishori Sharan)
Date: Sun, 26 Mar 2017 22:19:49 -0500
Subject: A typo in the output of the /help /help command in jshell
Message-ID: <CAKDNvg1jzma1DHndi0U_wTQgJEMdsmjSO2ft2ft8mZsDU7B5BA@mail.gmail.com>

Hello,
I am using 9-ea b162. The output of the "/help /help" command in jshell
contains a typo. The word "command" is spelled as "comand" - an 'm' is
missing.


jshell> /help /help
|
|  /help
|
|  Display information about jshell.
|  /help
|       List the jshell commands and help subjects.
|
|  /help <command>
|       Display information about the specified *comand*. The slash must be
included.
|       Only the first few letters of the command are needed -- if more
than one
|       each will be displayed.  Example:  /help /li
|
|  /help <subject>
|       Display information about the specified help subject. Example:
/help intro


Thanks
Kishori

From jan.lahoda at oracle.com  Mon Mar 27 08:39:27 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 27 Mar 2017 10:39:27 +0200
Subject: RFR 9: JDK-8177076: jshell tool: usability of completion
Message-ID: <58D8CFBF.8050502@oracle.com>

Hello,

I'd like to ask for a review of a patch that merges shift-tab and tab 
completions, and changes the fix shortcut to shift-tab:
Bug: https://bugs.openjdk.java.net/browse/JDK-8177076
Webrev: http://cr.openjdk.java.net/~jlahoda/8177076/webrev.00/

Any feedback is welcome,
      Jan

From robert.field at oracle.com  Mon Mar 27 21:20:24 2017
From: robert.field at oracle.com (Robert Field)
Date: Mon, 27 Mar 2017 14:20:24 -0700
Subject: RFR 9: JDK-8177076: jshell tool: usability of completion
In-Reply-To: <58D8CFBF.8050502@oracle.com>
References: <58D8CFBF.8050502@oracle.com>
Message-ID: <58D98218.2030000@oracle.com>

ConsoleIOContext.java
----------------------------

One of the key pieces of usability feedback was to step away from modal 
prompts.
Where, the cycle is on-tab: next-info/redraw.
These changes move to that mechanism.
However, the "too many completions" case uses a modal prompt (556).
Seems this could be handled the same way.

Nit: the variable declared on line 211: "String test", is that intended 
to be "text"?

SourceCodeAnalysisImpl.java
------------------------------------

These changes appear to be incomplete or abandoned.  They introduce a 
variable that is never set.

User Interface
------------------

jshell> List li
l ==> null

jshell> li.<tab>
add(               addAll(            clear() contains(          
containsAll(       equals( forEach(           get(               getClass()
hashCode()         indexOf(           isEmpty() iterator()         
lastIndexOf(       listIterator( notify()           notifyAll()        
parallelStream()
remove(            removeAll(         removeIf( replaceAll(        
retainAll(         set( size()             sort(              spliterator()
stream()           subList(           toArray( toString()         wait(

jshell> li.add<tab>
add(      addAll(

jshell> li.add(<tab>
Current signatures:
boolean List<E extends Object>.add(E e)
void List<E extends Object>.add(int index, E element)

Possible completions:

l     xxx   xyz

<press tab again to see documentation>

jshell> li.add(

The first and second tab used in the example above give possible 
completions without a leading header "Possible completions:" of the 
third case. This should be consistent.
The header could be added everywhere, but I think that would be noisy.  
The change in ordering is confusing anyhow.
The prompt "<press tab again to see documentation>" would be more 
intuitive grouped with the method signatures.
The header "Current signatures:", I think would be better 
"Signatures:",  "Method signatures:", or "Signatures of add:".
Applying these:

jshell> li.add(<tab>
l     xxx   xyz

Method signatures:
boolean List<E extends Object>.add(E e)
void List<E extends Object>.add(int index, E element)

<press tab again to see documentation>

jshell> li.add(

See above, under ConsoleIOContext.java, additionally, the inlining of 
more text makes this more confusing, as no indication of what to do if 
you don't want it --

jshell> 4 + <tab>

Gets replaced with:

jshell> 4 + 542 possible completions. Press <tab> or y to see them all.

I'd opt for consistency (which also uses this prompt that is used in the 
after documentation case):

jshell> 4 + <tab>
<press tab again to see all possible completions; total possible completions: 542>

jshell> 4 +

I see also that if documentation is displayed and there are smart items, 
then the last tab choice is all items.  In no other case are all items 
offered if there are smart items.

The command help is a very nice feature.

I'm unsure of the "<press tab again to see synopsis>" prompt line as the 
synopsis is also one line.

Overall
---------

Perhaps it would be good to lay this out as a UI design before turning 
it into code.

Naively (as I haven't done it), I think it may be possible to regularize 
the processing (starting as pseudo-code derived from the UI design).
I note 19 conditionals in the new code. I'm concerned about the 
branching complexity not only for code maintenance and testing but for 
what it implies about the user model.

I will be available to help on this tomorrow, if you would like.

-Robert


On 03/27/17 01:39, Jan Lahoda wrote:
> Hello,
>
> I'd like to ask for a review of a patch that merges shift-tab and tab 
> completions, and changes the fix shortcut to shift-tab:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8177076
> Webrev: http://cr.openjdk.java.net/~jlahoda/8177076/webrev.00/
>
> Any feedback is welcome,
>      Jan


From jan.lahoda at oracle.com  Tue Mar 28 16:56:01 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 28 Mar 2017 18:56:01 +0200
Subject: RFR 9: JDK-8177076: jshell tool: usability of completion
In-Reply-To: <58D98218.2030000@oracle.com>
References: <58D8CFBF.8050502@oracle.com> <58D98218.2030000@oracle.com>
Message-ID: <58DA95A1.1010701@oracle.com>

Hi Robert,

An updated version of the patch:
http://cr.openjdk.java.net/~jlahoda/8177076/webrev.01/

On 27.3.2017 23:20, Robert Field wrote:
> ConsoleIOContext.java
> ----------------------------
>
> One of the key pieces of usability feedback was to step away from modal
> prompts.
> Where, the cycle is on-tab: next-info/redraw.
> These changes move to that mechanism.
> However, the "too many completions" case uses a modal prompt (556).
> Seems this could be handled the same way.

Not sure if there's a modal prompt on ConsoleIOContext:556, rev.00 - 
there is a single read and after that the execution continues one way or 
another? It is true the code looked a little bit different that in the 
other cases. Anyway, this code does not exist in rev.01.

>
> Nit: the variable declared on line 211: "String test", is that intended
> to be "text"?

Yes, thanks. Fixed.

>
> SourceCodeAnalysisImpl.java
> ------------------------------------
>
> These changes appear to be incomplete or abandoned.  They introduce a
> variable that is never set.

Used by tests. Comment added.

>
> User Interface
> ------------------
>
> jshell> List li
> l ==> null
>
> jshell> li.<tab>
> add(               addAll(            clear() contains(
> containsAll(       equals( forEach(           get(               getClass()
> hashCode()         indexOf(           isEmpty() iterator()
> lastIndexOf(       listIterator( notify()           notifyAll()
> parallelStream()
> remove(            removeAll(         removeIf( replaceAll(
> retainAll(         set( size()             sort(              spliterator()
> stream()           subList(           toArray( toString()         wait(
>
> jshell> li.add<tab>
> add(      addAll(
>
> jshell> li.add(<tab>
> Current signatures:
> boolean List<E extends Object>.add(E e)
> void List<E extends Object>.add(int index, E element)
>
> Possible completions:
>
> l     xxx   xyz
>
> <press tab again to see documentation>
>
> jshell> li.add(
>
> The first and second tab used in the example above give possible
> completions without a leading header "Possible completions:" of the
> third case. This should be consistent.
> The header could be added everywhere, but I think that would be noisy.
> The change in ordering is confusing anyhow.
> The prompt "<press tab again to see documentation>" would be more
> intuitive grouped with the method signatures.
> The header "Current signatures:", I think would be better
> "Signatures:",  "Method signatures:", or "Signatures of add:".
> Applying these:
>
> jshell> li.add(<tab>
> l     xxx   xyz
>
> Method signatures:
> boolean List<E extends Object>.add(E e)
> void List<E extends Object>.add(int index, E element)
>
> <press tab again to see documentation>

Done. (The caption is "Signatures:", as in general, it is not always 
method signatures there.)

>
> jshell> li.add(
>
> See above, under ConsoleIOContext.java, additionally, the inlining of
> more text makes this more confusing, as no indication of what to do if
> you don't want it --

Sorry, but I am not sure what is the action requested here.

>
> jshell> 4 + <tab>
>
> Gets replaced with:
>
> jshell> 4 + 542 possible completions. Press <tab> or y to see them all.
>
> I'd opt for consistency (which also uses this prompt that is used in the
> after documentation case):
>
> jshell> 4 + <tab>
> <press tab again to see all possible completions; total possible
> completions: 542>

Done. To do that, I re-wrote the support a little (as this basically 
introduces a new state in the state "graph".)

>
> jshell> 4 +
>
> I see also that if documentation is displayed and there are smart items,
> then the last tab choice is all items.  In no other case are all items
> offered if there are smart items.

I believe all items may be shown where smart items exist and there's no 
documnetation:
jshell> String str = new Str<tab>
String(

<press tab again to see all possible completions>

jshell> String str = new Str<tab>
StreamCorruptedException(          StreamTokenizer( 
String(                            StringBuffer( 
StringBufferInputStream(           StringBuilder(
StringIndexOutOfBoundsException(   StringJoiner( 
StringReader(                      StringTokenizer( 
StringWriter(

jshell> String str = new Str

>
> The command help is a very nice feature.
>
> I'm unsure of the "<press tab again to see synopsis>" prompt line as the
> synopsis is also one line.

There may be multiple lines with synopsis, I believe:
jshell> /e<tab>
/edit    /env     /exit

<press tab again to see synopsis>

jshell> /e<tab>
/edit
edit a source entry referenced by name or id

/env
view or change the evaluation context

/exit
exit jshell

<press tab again to see full documentation>

jshell> /e

>
> Overall
> ---------
>
> Perhaps it would be good to lay this out as a UI design before turning
> it into code.
>
> Naively (as I haven't done it), I think it may be possible to regularize
> the processing (starting as pseudo-code derived from the UI design).
> I note 19 conditionals in the new code. I'm concerned about the
> branching complexity not only for code maintenance and testing but for
> what it implies about the user model.

I think the primary question is if it works well for the users. Not sure 
if the # of conditionals is so significant. I didn't really try to 
minimize the # of conditions, I tried to make the code understandable, 
making it simpler to say "if the situation is this, then the outcome 
will be that". (The new revision goes one more step in that direction, I 
think.)

(Having this in the code also helps to cover all the corners, which are 
easy to miss otherwise.)

Anyway - if there's a UI design covering all the cases 
(command/expression, has/hasn't doc, has/hasn't smart items, has/hasn't 
additional items, there are/aren't too many items), I can implement it.

Jan

>
> I will be available to help on this tomorrow, if you would like.
>
> -Robert
>
>
> On 03/27/17 01:39, Jan Lahoda wrote:
>> Hello,
>>
>> I'd like to ask for a review of a patch that merges shift-tab and tab
>> completions, and changes the fix shortcut to shift-tab:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177076
>> Webrev: http://cr.openjdk.java.net/~jlahoda/8177076/webrev.00/
>>
>> Any feedback is welcome,
>>      Jan
>

From robert.field at oracle.com  Tue Mar 28 19:31:19 2017
From: robert.field at oracle.com (Robert Field)
Date: Tue, 28 Mar 2017 12:31:19 -0700
Subject: RFR 9: JDK-8177076: jshell tool: usability of completion
In-Reply-To: <58DA95A1.1010701@oracle.com>
References: <58D8CFBF.8050502@oracle.com> <58D98218.2030000@oracle.com>
 <58DA95A1.1010701@oracle.com>
Message-ID: <58DABA07.2030007@oracle.com>


On 03/28/17 09:56, Jan Lahoda wrote:
> Hi Robert,
>
> An updated version of the patch:
> http://cr.openjdk.java.net/~jlahoda/8177076/webrev.01/

I like the new CompletionTask design!

ConsoleIOContext.java
----------------------------
Copyright need update.

l10n.properties
------------------
156 jshell.console.see.next.page = <press space for next page, any other 
key to quit>
tab also works, so should be "tab or space"

157 jshell.console.see.next.javadoc = <press tab or space for next 
javadoc, any other key to quit>
If this remains (see below suggestion to change this), then it should be 
"documentation" rather than "javadoc", as elsewhere.

493         If there is more than one completion, show possible 
completions.\n\t\t\
" then possible completions will be shown"

496         After a complete expression, press "Shift-<tab> v" to 
introduce a new variable\n\t\t\
It may not be clear to people what those keyboard actions are
"After a complete expression, hold down <shift> while pressing <tab>, 
then release and press "v", the expression will be converted to a 
variable declaration"

498 Shift-<tab> i\n\t\t\
Same treatment.  And maybe "propose possible imports which will resolve 
the name..."

MergedTabShiftTabTest.java
---------------------------------
No bug ID on test.


User Interface
------------------

I'm wondering, would it be more consistent, when displaying javadoc, if 
instead of displaying this prompt between pages:

     <press tab or space for next javadoc, any other key to quit>

That it did a redrawLine()?

      <press tab again for next documentation>

      jshell> l.add(

Implementation-wise, that each doc page was an item in the the todo list.
Basically, I think getting rid of all prompts would be cleanest.

-------

What a tease, tell me there is documentation, and then... ;-)

jshell> l
l      long

Signatures:
l:java.util.List

<press tab again to see documentation>

jshell> l
l:java.util.List
<no javadoc found>

jshell> l

-------

What to do when there are no completions?  Like:

jshell> /zz<tab>

or

jshell> zz<tab>

Before it did nothing, which is confusing.
It could print "No completions" and redraw, but that would probably be 
noisy.
I think what it does with this patch, which is redraw right below, is 
probably just right for snippets.

jshell> /zz<tab>
jshell> /zz

Though, for commands (but not command arguments), maybe "No such 
command" and a redraw???

-------

shift-tab for fixes sure is nice.

--------------

Nice work!

-Robert



>
> On 27.3.2017 23:20, Robert Field wrote:
>> ConsoleIOContext.java
>> ----------------------------
>>
>> One of the key pieces of usability feedback was to step away from modal
>> prompts.
>> Where, the cycle is on-tab: next-info/redraw.
>> These changes move to that mechanism.
>> However, the "too many completions" case uses a modal prompt (556).
>> Seems this could be handled the same way.
>
> Not sure if there's a modal prompt on ConsoleIOContext:556, rev.00 - 
> there is a single read and after that the execution continues one way 
> or another? It is true the code looked a little bit different that in 
> the other cases. Anyway, this code does not exist in rev.01.
>
>>
>> Nit: the variable declared on line 211: "String test", is that intended
>> to be "text"?
>
> Yes, thanks. Fixed.
>
>>
>> SourceCodeAnalysisImpl.java
>> ------------------------------------
>>
>> These changes appear to be incomplete or abandoned.  They introduce a
>> variable that is never set.
>
> Used by tests. Comment added.
>
>>
>> User Interface
>> ------------------
>>
>> jshell> List li
>> l ==> null
>>
>> jshell> li.<tab>
>> add(               addAll(            clear() contains(
>> containsAll(       equals( forEach(           get( getClass()
>> hashCode()         indexOf(           isEmpty() iterator()
>> lastIndexOf(       listIterator( notify()           notifyAll()
>> parallelStream()
>> remove(            removeAll(         removeIf( replaceAll(
>> retainAll(         set( size()             sort( spliterator()
>> stream()           subList(           toArray( toString()         wait(
>>
>> jshell> li.add<tab>
>> add(      addAll(
>>
>> jshell> li.add(<tab>
>> Current signatures:
>> boolean List<E extends Object>.add(E e)
>> void List<E extends Object>.add(int index, E element)
>>
>> Possible completions:
>>
>> l     xxx   xyz
>>
>> <press tab again to see documentation>
>>
>> jshell> li.add(
>>
>> The first and second tab used in the example above give possible
>> completions without a leading header "Possible completions:" of the
>> third case. This should be consistent.
>> The header could be added everywhere, but I think that would be noisy.
>> The change in ordering is confusing anyhow.
>> The prompt "<press tab again to see documentation>" would be more
>> intuitive grouped with the method signatures.
>> The header "Current signatures:", I think would be better
>> "Signatures:",  "Method signatures:", or "Signatures of add:".
>> Applying these:
>>
>> jshell> li.add(<tab>
>> l     xxx   xyz
>>
>> Method signatures:
>> boolean List<E extends Object>.add(E e)
>> void List<E extends Object>.add(int index, E element)
>>
>> <press tab again to see documentation>
>
> Done. (The caption is "Signatures:", as in general, it is not always 
> method signatures there.)
>
>>
>> jshell> li.add(
>>
>> See above, under ConsoleIOContext.java, additionally, the inlining of
>> more text makes this more confusing, as no indication of what to do if
>> you don't want it --
>
> Sorry, but I am not sure what is the action requested here.
>
>>
>> jshell> 4 + <tab>
>>
>> Gets replaced with:
>>
>> jshell> 4 + 542 possible completions. Press <tab> or y to see them all.
>>
>> I'd opt for consistency (which also uses this prompt that is used in the
>> after documentation case):
>>
>> jshell> 4 + <tab>
>> <press tab again to see all possible completions; total possible
>> completions: 542>
>
> Done. To do that, I re-wrote the support a little (as this basically 
> introduces a new state in the state "graph".)
>
>>
>> jshell> 4 +
>>
>> I see also that if documentation is displayed and there are smart items,
>> then the last tab choice is all items.  In no other case are all items
>> offered if there are smart items.
>
> I believe all items may be shown where smart items exist and there's 
> no documnetation:
> jshell> String str = new Str<tab>
> String(
>
> <press tab again to see all possible completions>
>
> jshell> String str = new Str<tab>
> StreamCorruptedException(          StreamTokenizer( 
> String(                            StringBuffer( 
> StringBufferInputStream(           StringBuilder(
> StringIndexOutOfBoundsException(   StringJoiner( 
> StringReader(                      StringTokenizer( StringWriter(
>
> jshell> String str = new Str
>
>>
>> The command help is a very nice feature.
>>
>> I'm unsure of the "<press tab again to see synopsis>" prompt line as the
>> synopsis is also one line.
>
> There may be multiple lines with synopsis, I believe:
> jshell> /e<tab>
> /edit    /env     /exit
>
> <press tab again to see synopsis>
>
> jshell> /e<tab>
> /edit
> edit a source entry referenced by name or id
>
> /env
> view or change the evaluation context
>
> /exit
> exit jshell
>
> <press tab again to see full documentation>
>
> jshell> /e
>
>>
>> Overall
>> ---------
>>
>> Perhaps it would be good to lay this out as a UI design before turning
>> it into code.
>>
>> Naively (as I haven't done it), I think it may be possible to regularize
>> the processing (starting as pseudo-code derived from the UI design).
>> I note 19 conditionals in the new code. I'm concerned about the
>> branching complexity not only for code maintenance and testing but for
>> what it implies about the user model.
>
> I think the primary question is if it works well for the users. Not 
> sure if the # of conditionals is so significant. I didn't really try 
> to minimize the # of conditions, I tried to make the code 
> understandable, making it simpler to say "if the situation is this, 
> then the outcome will be that". (The new revision goes one more step 
> in that direction, I think.)
>
> (Having this in the code also helps to cover all the corners, which 
> are easy to miss otherwise.)
>
> Anyway - if there's a UI design covering all the cases 
> (command/expression, has/hasn't doc, has/hasn't smart items, 
> has/hasn't additional items, there are/aren't too many items), I can 
> implement it.
>
> Jan
>
>>
>> I will be available to help on this tomorrow, if you would like.
>>
>> -Robert
>>
>>
>> On 03/27/17 01:39, Jan Lahoda wrote:
>>> Hello,
>>>
>>> I'd like to ask for a review of a patch that merges shift-tab and tab
>>> completions, and changes the fix shortcut to shift-tab:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177076
>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8177076/webrev.00/
>>>
>>> Any feedback is welcome,
>>>      Jan
>>


From robert.field at oracle.com  Tue Mar 28 20:07:29 2017
From: robert.field at oracle.com (Robert Field)
Date: Tue, 28 Mar 2017 13:07:29 -0700
Subject: A typo in the output of the /help /help command in jshell
In-Reply-To: <CAKDNvg1jzma1DHndi0U_wTQgJEMdsmjSO2ft2ft8mZsDU7B5BA@mail.gmail.com>
References: <CAKDNvg1jzma1DHndi0U_wTQgJEMdsmjSO2ft2ft8mZsDU7B5BA@mail.gmail.com>
Message-ID: <58DAC281.1060000@oracle.com>

Thanks!

I've filed:

     https://bugs.openjdk.java.net/browse/JDK-8177735

-Robert

On 03/26/17 20:19, Kishori Sharan wrote:
> Hello,
> I am using 9-ea b162. The output of the "/help /help" command in jshell
> contains a typo. The word "command" is spelled as "comand" - an 'm' is
> missing.
>
>
> jshell> /help /help
> |
> |  /help
> |
> |  Display information about jshell.
> |  /help
> |       List the jshell commands and help subjects.
> |
> |  /help <command>
> |       Display information about the specified *comand*. The slash must be
> included.
> |       Only the first few letters of the command are needed -- if more
> than one
> |       each will be displayed.  Example:  /help /li
> |
> |  /help <subject>
> |       Display information about the specified help subject. Example:
> /help intro
>
>
> Thanks
> Kishori


From robert.field at oracle.com  Wed Mar 29 05:18:24 2017
From: robert.field at oracle.com (Robert Field)
Date: Tue, 28 Mar 2017 22:18:24 -0700
Subject: jshell tool: survey on keystroke functionality -- your input
 requested
In-Reply-To: <58CD7EFC.4040100@oracle.com>
References: <58CD7EFC.4040100@oracle.com>
Message-ID: <58DB43A0.9050408@oracle.com>

An update: corresponding to the unanimous feedback we received, we are 
in the process of implementing the "Alternative" keystroke mapping (see 
Jan's RFRs).
Despite being late in the game, we hope to get approval for these to go 
into JDK 9.

Thanks for the feedback.

-Robert

On 03/18/17 11:39, Robert Field wrote:
> A usability question is being hotly debated internally.   I'd love 
> community input.
> I'll give background.  If you understand that you can skip to the 
> question.
> Please email your choice with or without discussion.
>
> BACKGROUND
>
> There are currently these JShell-specific 
> completion/information/transformation keystrokes --
>
> tab [complete]:  completes an identifier (if there is a unique 
> completion), does no or partial completion and provides a list of 
> possible completion (if there are multiple completions)
>
> shift-tab [info]: when the cursor is positioned after the open 
> parenthesis of a method call, lists the matching method signatures. if 
> pressed again, displays the javadoc for the first matching signature 
> (prompting to display further)
>
> Alt-F1 or Alt-Enter (depending on platform) [codegen]:  when followed 
> by "i", prompts to auto-import the identifier before the cursor.  when 
> followed by "v" converts the expression before the cursor into a 
> variable declaration with the expression as initializer
>
> USER MODELS
>
> Current:  tab does completion, shift-tab gives information
>
> Alternative (tab is used for both [complete] and [info]) : tab helps 
> me complete -- either directly completing or giving me information 
> that helps me complete
>
> ARGUMENTS
>
> Current:
>     cleanly separates a request to complete the characters in an 
> identifier (which is often to save typing) from a request for information
>
> Alternative:
>     just want one key to help me code, not different ones in different 
> contexts.  This gives better discovery.
>     When there isn't a unique completion, tab currently gives 
> information, so the distinction isn't that clean.
>     Currently shift-tab only works in one specific context, in that 
> context the tab completions are usually in the hundreds, thus not very 
> useful.
>     This frees-up shift-tab for [codegen], eliminating the awkward and 
> platform-dependent Alt-F1 or Alt-Enter
>
> QUESTION
>
> Current
>
>    or
>
> Alternative
>
> ???
>
>


From robert.field at oracle.com  Wed Mar 29 05:30:53 2017
From: robert.field at oracle.com (Robert Field)
Date: Tue, 28 Mar 2017 22:30:53 -0700
Subject: RFR 8177078 et. al. : three /help fixes
Message-ID: <58DB468D.1090808@oracle.com>

Please review:

Bugs:

     8177078: jshell tool: fix documentation of /help shortcuts
     https://bugs.openjdk.java.net/browse/JDK-8177078

     8177735: jshell tool: /help /help -- typo "comand"
     https://bugs.openjdk.java.net/browse/JDK-8177735

     8177308: jshell tool: documentation: multiple start-up files and 
predefines not documented
     https://bugs.openjdk.java.net/browse/JDK-8177308

Webrev:

     http://cr.openjdk.java.net/~rfield/8177078v0.webrev/

Thanks,
Robert


From jan.lahoda at oracle.com  Wed Mar 29 17:33:32 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 29 Mar 2017 19:33:32 +0200
Subject: RFR 9: JDK-8177076: jshell tool: usability of completion
In-Reply-To: <58DABA07.2030007@oracle.com>
References: <58D8CFBF.8050502@oracle.com> <58D98218.2030000@oracle.com>
 <58DA95A1.1010701@oracle.com> <58DABA07.2030007@oracle.com>
Message-ID: <58DBEFEC.6010304@oracle.com>

An updated version of the patch addressing the comments is here:
http://cr.openjdk.java.net/~jlahoda/8177076/webrev.02/

On 28.3.2017 21:31, Robert Field wrote:
>
> On 03/28/17 09:56, Jan Lahoda wrote:
>> Hi Robert,
>>
>> An updated version of the patch:
>> http://cr.openjdk.java.net/~jlahoda/8177076/webrev.01/
>
> I like the new CompletionTask design!
>
> ConsoleIOContext.java
> ----------------------------
> Copyright need update.

Fixed.

>
> l10n.properties
> ------------------
> 156 jshell.console.see.next.page = <press space for next page, any other
> key to quit>
> tab also works, so should be "tab or space"

The text is different now.

>
> 157 jshell.console.see.next.javadoc = <press tab or space for next
> javadoc, any other key to quit>
> If this remains (see below suggestion to change this), then it should be
> "documentation" rather than "javadoc", as elsewhere.

Done.

>
> 493         If there is more than one completion, show possible
> completions.\n\t\t\
> " then possible completions will be shown"

Done.

>
> 496         After a complete expression, press "Shift-<tab> v" to
> introduce a new variable\n\t\t\
> It may not be clear to people what those keyboard actions are
> "After a complete expression, hold down <shift> while pressing <tab>,
> then release and press "v", the expression will be converted to a
> variable declaration"

Done.

>
> 498 Shift-<tab> i\n\t\t\
> Same treatment.  And maybe "propose possible imports which will resolve
> the name..."
>

Done.

> MergedTabShiftTabTest.java
> ---------------------------------
> No bug ID on test.

Fixed.

>
>
> User Interface
> ------------------
>
> I'm wondering, would it be more consistent, when displaying javadoc, if
> instead of displaying this prompt between pages:
>
>      <press tab or space for next javadoc, any other key to quit>
>
> That it did a redrawLine()?
>
>       <press tab again for next documentation>
>
>       jshell> l.add(
>
> Implementation-wise, that each doc page was an item in the the todo list.
> Basically, I think getting rid of all prompts would be cleanest.

Done.

>
> -------
>
> What a tease, tell me there is documentation, and then... ;-)

Unfortunately, detecting whether there will be an actual javadoc is 
costly, so I don't think we would want to do that upfront.

>
> jshell> l
> l      long
>
> Signatures:
> l:java.util.List
>
> <press tab again to see documentation>
>
> jshell> l
> l:java.util.List
> <no javadoc found>
>
> jshell> l
>
> -------
>
> What to do when there are no completions?  Like:
>
> jshell> /zz<tab>
>
> or
>
> jshell> zz<tab>
>
> Before it did nothing, which is confusing.
> It could print "No completions" and redraw, but that would probably be
> noisy.
> I think what it does with this patch, which is redraw right below, is
> probably just right for snippets.
>
> jshell> /zz<tab>
> jshell> /zz
>
> Though, for commands (but not command arguments), maybe "No such
> command" and a redraw???

Done.

Jan

>
> -------
>
> shift-tab for fixes sure is nice.
>
> --------------
>
> Nice work!
>
> -Robert
>
>
>
>>
>> On 27.3.2017 23:20, Robert Field wrote:
>>> ConsoleIOContext.java
>>> ----------------------------
>>>
>>> One of the key pieces of usability feedback was to step away from modal
>>> prompts.
>>> Where, the cycle is on-tab: next-info/redraw.
>>> These changes move to that mechanism.
>>> However, the "too many completions" case uses a modal prompt (556).
>>> Seems this could be handled the same way.
>>
>> Not sure if there's a modal prompt on ConsoleIOContext:556, rev.00 -
>> there is a single read and after that the execution continues one way
>> or another? It is true the code looked a little bit different that in
>> the other cases. Anyway, this code does not exist in rev.01.
>>
>>>
>>> Nit: the variable declared on line 211: "String test", is that intended
>>> to be "text"?
>>
>> Yes, thanks. Fixed.
>>
>>>
>>> SourceCodeAnalysisImpl.java
>>> ------------------------------------
>>>
>>> These changes appear to be incomplete or abandoned.  They introduce a
>>> variable that is never set.
>>
>> Used by tests. Comment added.
>>
>>>
>>> User Interface
>>> ------------------
>>>
>>> jshell> List li
>>> l ==> null
>>>
>>> jshell> li.<tab>
>>> add(               addAll(            clear() contains(
>>> containsAll(       equals( forEach(           get( getClass()
>>> hashCode()         indexOf(           isEmpty() iterator()
>>> lastIndexOf(       listIterator( notify()           notifyAll()
>>> parallelStream()
>>> remove(            removeAll(         removeIf( replaceAll(
>>> retainAll(         set( size()             sort( spliterator()
>>> stream()           subList(           toArray( toString()         wait(
>>>
>>> jshell> li.add<tab>
>>> add(      addAll(
>>>
>>> jshell> li.add(<tab>
>>> Current signatures:
>>> boolean List<E extends Object>.add(E e)
>>> void List<E extends Object>.add(int index, E element)
>>>
>>> Possible completions:
>>>
>>> l     xxx   xyz
>>>
>>> <press tab again to see documentation>
>>>
>>> jshell> li.add(
>>>
>>> The first and second tab used in the example above give possible
>>> completions without a leading header "Possible completions:" of the
>>> third case. This should be consistent.
>>> The header could be added everywhere, but I think that would be noisy.
>>> The change in ordering is confusing anyhow.
>>> The prompt "<press tab again to see documentation>" would be more
>>> intuitive grouped with the method signatures.
>>> The header "Current signatures:", I think would be better
>>> "Signatures:",  "Method signatures:", or "Signatures of add:".
>>> Applying these:
>>>
>>> jshell> li.add(<tab>
>>> l     xxx   xyz
>>>
>>> Method signatures:
>>> boolean List<E extends Object>.add(E e)
>>> void List<E extends Object>.add(int index, E element)
>>>
>>> <press tab again to see documentation>
>>
>> Done. (The caption is "Signatures:", as in general, it is not always
>> method signatures there.)
>>
>>>
>>> jshell> li.add(
>>>
>>> See above, under ConsoleIOContext.java, additionally, the inlining of
>>> more text makes this more confusing, as no indication of what to do if
>>> you don't want it --
>>
>> Sorry, but I am not sure what is the action requested here.
>>
>>>
>>> jshell> 4 + <tab>
>>>
>>> Gets replaced with:
>>>
>>> jshell> 4 + 542 possible completions. Press <tab> or y to see them all.
>>>
>>> I'd opt for consistency (which also uses this prompt that is used in the
>>> after documentation case):
>>>
>>> jshell> 4 + <tab>
>>> <press tab again to see all possible completions; total possible
>>> completions: 542>
>>
>> Done. To do that, I re-wrote the support a little (as this basically
>> introduces a new state in the state "graph".)
>>
>>>
>>> jshell> 4 +
>>>
>>> I see also that if documentation is displayed and there are smart items,
>>> then the last tab choice is all items.  In no other case are all items
>>> offered if there are smart items.
>>
>> I believe all items may be shown where smart items exist and there's
>> no documnetation:
>> jshell> String str = new Str<tab>
>> String(
>>
>> <press tab again to see all possible completions>
>>
>> jshell> String str = new Str<tab>
>> StreamCorruptedException(          StreamTokenizer(
>> String(                            StringBuffer(
>> StringBufferInputStream(           StringBuilder(
>> StringIndexOutOfBoundsException(   StringJoiner(
>> StringReader(                      StringTokenizer( StringWriter(
>>
>> jshell> String str = new Str
>>
>>>
>>> The command help is a very nice feature.
>>>
>>> I'm unsure of the "<press tab again to see synopsis>" prompt line as the
>>> synopsis is also one line.
>>
>> There may be multiple lines with synopsis, I believe:
>> jshell> /e<tab>
>> /edit    /env     /exit
>>
>> <press tab again to see synopsis>
>>
>> jshell> /e<tab>
>> /edit
>> edit a source entry referenced by name or id
>>
>> /env
>> view or change the evaluation context
>>
>> /exit
>> exit jshell
>>
>> <press tab again to see full documentation>
>>
>> jshell> /e
>>
>>>
>>> Overall
>>> ---------
>>>
>>> Perhaps it would be good to lay this out as a UI design before turning
>>> it into code.
>>>
>>> Naively (as I haven't done it), I think it may be possible to regularize
>>> the processing (starting as pseudo-code derived from the UI design).
>>> I note 19 conditionals in the new code. I'm concerned about the
>>> branching complexity not only for code maintenance and testing but for
>>> what it implies about the user model.
>>
>> I think the primary question is if it works well for the users. Not
>> sure if the # of conditionals is so significant. I didn't really try
>> to minimize the # of conditions, I tried to make the code
>> understandable, making it simpler to say "if the situation is this,
>> then the outcome will be that". (The new revision goes one more step
>> in that direction, I think.)
>>
>> (Having this in the code also helps to cover all the corners, which
>> are easy to miss otherwise.)
>>
>> Anyway - if there's a UI design covering all the cases
>> (command/expression, has/hasn't doc, has/hasn't smart items,
>> has/hasn't additional items, there are/aren't too many items), I can
>> implement it.
>>
>> Jan
>>
>>>
>>> I will be available to help on this tomorrow, if you would like.
>>>
>>> -Robert
>>>
>>>
>>> On 03/27/17 01:39, Jan Lahoda wrote:
>>>> Hello,
>>>>
>>>> I'd like to ask for a review of a patch that merges shift-tab and tab
>>>> completions, and changes the fix shortcut to shift-tab:
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177076
>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8177076/webrev.00/
>>>>
>>>> Any feedback is welcome,
>>>>      Jan
>>>
>

From robert.field at oracle.com  Wed Mar 29 22:49:02 2017
From: robert.field at oracle.com (Robert Field)
Date: Wed, 29 Mar 2017 15:49:02 -0700
Subject: RFR 9: JDK-8177076: jshell tool: usability of completion
In-Reply-To: <58DBEFEC.6010304@oracle.com>
References: <58D8CFBF.8050502@oracle.com> <58D98218.2030000@oracle.com>
 <58DA95A1.1010701@oracle.com> <58DABA07.2030007@oracle.com>
 <58DBEFEC.6010304@oracle.com>
Message-ID: <58DC39DE.7070805@oracle.com>

Looks really good.

Two small things which don't need another round of review --

503         which will resolve the identifiers based on the content of 
the specified classpath.\n\t\t\

should be "identifier" not "identifiers"

163 jshell.console.no.javadoc = <no javadoc found>

Should, like the other cases, be "documentation" rather than "javadoc".


Thanks,
Robert


On 03/29/17 10:33, Jan Lahoda wrote:
> An updated version of the patch addressing the comments is here:
> http://cr.openjdk.java.net/~jlahoda/8177076/webrev.02/
>
> On 28.3.2017 21:31, Robert Field wrote:
>>
>> On 03/28/17 09:56, Jan Lahoda wrote:
>>> Hi Robert,
>>>
>>> An updated version of the patch:
>>> http://cr.openjdk.java.net/~jlahoda/8177076/webrev.01/
>>
>> I like the new CompletionTask design!
>>
>> ConsoleIOContext.java
>> ----------------------------
>> Copyright need update.
>
> Fixed.
>
>>
>> l10n.properties
>> ------------------
>> 156 jshell.console.see.next.page = <press space for next page, any other
>> key to quit>
>> tab also works, so should be "tab or space"
>
> The text is different now.
>
>>
>> 157 jshell.console.see.next.javadoc = <press tab or space for next
>> javadoc, any other key to quit>
>> If this remains (see below suggestion to change this), then it should be
>> "documentation" rather than "javadoc", as elsewhere.
>
> Done.
>
>>
>> 493         If there is more than one completion, show possible
>> completions.\n\t\t\
>> " then possible completions will be shown"
>
> Done.
>
>>
>> 496         After a complete expression, press "Shift-<tab> v" to
>> introduce a new variable\n\t\t\
>> It may not be clear to people what those keyboard actions are
>> "After a complete expression, hold down <shift> while pressing <tab>,
>> then release and press "v", the expression will be converted to a
>> variable declaration"
>
> Done.
>
>>
>> 498 Shift-<tab> i\n\t\t\
>> Same treatment.  And maybe "propose possible imports which will resolve
>> the name..."
>>
>
> Done.
>
>> MergedTabShiftTabTest.java
>> ---------------------------------
>> No bug ID on test.
>
> Fixed.
>
>>
>>
>> User Interface
>> ------------------
>>
>> I'm wondering, would it be more consistent, when displaying javadoc, if
>> instead of displaying this prompt between pages:
>>
>>      <press tab or space for next javadoc, any other key to quit>
>>
>> That it did a redrawLine()?
>>
>>       <press tab again for next documentation>
>>
>>       jshell> l.add(
>>
>> Implementation-wise, that each doc page was an item in the the todo 
>> list.
>> Basically, I think getting rid of all prompts would be cleanest.
>
> Done.
>
>>
>> -------
>>
>> What a tease, tell me there is documentation, and then... ;-)
>
> Unfortunately, detecting whether there will be an actual javadoc is 
> costly, so I don't think we would want to do that upfront.
>
>>
>> jshell> l
>> l      long
>>
>> Signatures:
>> l:java.util.List
>>
>> <press tab again to see documentation>
>>
>> jshell> l
>> l:java.util.List
>> <no javadoc found>
>>
>> jshell> l
>>
>> -------
>>
>> What to do when there are no completions?  Like:
>>
>> jshell> /zz<tab>
>>
>> or
>>
>> jshell> zz<tab>
>>
>> Before it did nothing, which is confusing.
>> It could print "No completions" and redraw, but that would probably be
>> noisy.
>> I think what it does with this patch, which is redraw right below, is
>> probably just right for snippets.
>>
>> jshell> /zz<tab>
>> jshell> /zz
>>
>> Though, for commands (but not command arguments), maybe "No such
>> command" and a redraw???
>
> Done.
>
> Jan
>
>>
>> -------
>>
>> shift-tab for fixes sure is nice.
>>
>> --------------
>>
>> Nice work!
>>
>> -Robert
>>
>>
>>
>>>
>>> On 27.3.2017 23:20, Robert Field wrote:
>>>> ConsoleIOContext.java
>>>> ----------------------------
>>>>
>>>> One of the key pieces of usability feedback was to step away from 
>>>> modal
>>>> prompts.
>>>> Where, the cycle is on-tab: next-info/redraw.
>>>> These changes move to that mechanism.
>>>> However, the "too many completions" case uses a modal prompt (556).
>>>> Seems this could be handled the same way.
>>>
>>> Not sure if there's a modal prompt on ConsoleIOContext:556, rev.00 -
>>> there is a single read and after that the execution continues one way
>>> or another? It is true the code looked a little bit different that in
>>> the other cases. Anyway, this code does not exist in rev.01.
>>>
>>>>
>>>> Nit: the variable declared on line 211: "String test", is that 
>>>> intended
>>>> to be "text"?
>>>
>>> Yes, thanks. Fixed.
>>>
>>>>
>>>> SourceCodeAnalysisImpl.java
>>>> ------------------------------------
>>>>
>>>> These changes appear to be incomplete or abandoned.  They introduce a
>>>> variable that is never set.
>>>
>>> Used by tests. Comment added.
>>>
>>>>
>>>> User Interface
>>>> ------------------
>>>>
>>>> jshell> List li
>>>> l ==> null
>>>>
>>>> jshell> li.<tab>
>>>> add(               addAll(            clear() contains(
>>>> containsAll(       equals( forEach(           get( getClass()
>>>> hashCode()         indexOf(           isEmpty() iterator()
>>>> lastIndexOf(       listIterator( notify() notifyAll()
>>>> parallelStream()
>>>> remove(            removeAll(         removeIf( replaceAll(
>>>> retainAll(         set( size()             sort( spliterator()
>>>> stream()           subList(           toArray( toString()         
>>>> wait(
>>>>
>>>> jshell> li.add<tab>
>>>> add(      addAll(
>>>>
>>>> jshell> li.add(<tab>
>>>> Current signatures:
>>>> boolean List<E extends Object>.add(E e)
>>>> void List<E extends Object>.add(int index, E element)
>>>>
>>>> Possible completions:
>>>>
>>>> l     xxx   xyz
>>>>
>>>> <press tab again to see documentation>
>>>>
>>>> jshell> li.add(
>>>>
>>>> The first and second tab used in the example above give possible
>>>> completions without a leading header "Possible completions:" of the
>>>> third case. This should be consistent.
>>>> The header could be added everywhere, but I think that would be noisy.
>>>> The change in ordering is confusing anyhow.
>>>> The prompt "<press tab again to see documentation>" would be more
>>>> intuitive grouped with the method signatures.
>>>> The header "Current signatures:", I think would be better
>>>> "Signatures:",  "Method signatures:", or "Signatures of add:".
>>>> Applying these:
>>>>
>>>> jshell> li.add(<tab>
>>>> l     xxx   xyz
>>>>
>>>> Method signatures:
>>>> boolean List<E extends Object>.add(E e)
>>>> void List<E extends Object>.add(int index, E element)
>>>>
>>>> <press tab again to see documentation>
>>>
>>> Done. (The caption is "Signatures:", as in general, it is not always
>>> method signatures there.)
>>>
>>>>
>>>> jshell> li.add(
>>>>
>>>> See above, under ConsoleIOContext.java, additionally, the inlining of
>>>> more text makes this more confusing, as no indication of what to do if
>>>> you don't want it --
>>>
>>> Sorry, but I am not sure what is the action requested here.
>>>
>>>>
>>>> jshell> 4 + <tab>
>>>>
>>>> Gets replaced with:
>>>>
>>>> jshell> 4 + 542 possible completions. Press <tab> or y to see them 
>>>> all.
>>>>
>>>> I'd opt for consistency (which also uses this prompt that is used 
>>>> in the
>>>> after documentation case):
>>>>
>>>> jshell> 4 + <tab>
>>>> <press tab again to see all possible completions; total possible
>>>> completions: 542>
>>>
>>> Done. To do that, I re-wrote the support a little (as this basically
>>> introduces a new state in the state "graph".)
>>>
>>>>
>>>> jshell> 4 +
>>>>
>>>> I see also that if documentation is displayed and there are smart 
>>>> items,
>>>> then the last tab choice is all items.  In no other case are all items
>>>> offered if there are smart items.
>>>
>>> I believe all items may be shown where smart items exist and there's
>>> no documnetation:
>>> jshell> String str = new Str<tab>
>>> String(
>>>
>>> <press tab again to see all possible completions>
>>>
>>> jshell> String str = new Str<tab>
>>> StreamCorruptedException(          StreamTokenizer(
>>> String(                            StringBuffer(
>>> StringBufferInputStream(           StringBuilder(
>>> StringIndexOutOfBoundsException(   StringJoiner(
>>> StringReader(                      StringTokenizer( StringWriter(
>>>
>>> jshell> String str = new Str
>>>
>>>>
>>>> The command help is a very nice feature.
>>>>
>>>> I'm unsure of the "<press tab again to see synopsis>" prompt line 
>>>> as the
>>>> synopsis is also one line.
>>>
>>> There may be multiple lines with synopsis, I believe:
>>> jshell> /e<tab>
>>> /edit    /env     /exit
>>>
>>> <press tab again to see synopsis>
>>>
>>> jshell> /e<tab>
>>> /edit
>>> edit a source entry referenced by name or id
>>>
>>> /env
>>> view or change the evaluation context
>>>
>>> /exit
>>> exit jshell
>>>
>>> <press tab again to see full documentation>
>>>
>>> jshell> /e
>>>
>>>>
>>>> Overall
>>>> ---------
>>>>
>>>> Perhaps it would be good to lay this out as a UI design before turning
>>>> it into code.
>>>>
>>>> Naively (as I haven't done it), I think it may be possible to 
>>>> regularize
>>>> the processing (starting as pseudo-code derived from the UI design).
>>>> I note 19 conditionals in the new code. I'm concerned about the
>>>> branching complexity not only for code maintenance and testing but for
>>>> what it implies about the user model.
>>>
>>> I think the primary question is if it works well for the users. Not
>>> sure if the # of conditionals is so significant. I didn't really try
>>> to minimize the # of conditions, I tried to make the code
>>> understandable, making it simpler to say "if the situation is this,
>>> then the outcome will be that". (The new revision goes one more step
>>> in that direction, I think.)
>>>
>>> (Having this in the code also helps to cover all the corners, which
>>> are easy to miss otherwise.)
>>>
>>> Anyway - if there's a UI design covering all the cases
>>> (command/expression, has/hasn't doc, has/hasn't smart items,
>>> has/hasn't additional items, there are/aren't too many items), I can
>>> implement it.
>>>
>>> Jan
>>>
>>>>
>>>> I will be available to help on this tomorrow, if you would like.
>>>>
>>>> -Robert
>>>>
>>>>
>>>> On 03/27/17 01:39, Jan Lahoda wrote:
>>>>> Hello,
>>>>>
>>>>> I'd like to ask for a review of a patch that merges shift-tab and tab
>>>>> completions, and changes the fix shortcut to shift-tab:
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177076
>>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8177076/webrev.00/
>>>>>
>>>>> Any feedback is welcome,
>>>>>      Jan
>>>>
>>


From jan.lahoda at oracle.com  Thu Mar 30 12:45:25 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 30 Mar 2017 14:45:25 +0200
Subject: RFR 8177078 et. al. : three /help fixes
In-Reply-To: <58DB468D.1090808@oracle.com>
References: <58DB468D.1090808@oracle.com>
Message-ID: <58DCFDE5.3080209@oracle.com>

Seems OK.

Jan

On 29.3.2017 07:30, Robert Field wrote:
> Please review:
>
> Bugs:
>
>      8177078: jshell tool: fix documentation of /help shortcuts
>      https://bugs.openjdk.java.net/browse/JDK-8177078
>
>      8177735: jshell tool: /help /help -- typo "comand"
>      https://bugs.openjdk.java.net/browse/JDK-8177735
>
>      8177308: jshell tool: documentation: multiple start-up files and
> predefines not documented
>      https://bugs.openjdk.java.net/browse/JDK-8177308
>
> Webrev:
>
>      http://cr.openjdk.java.net/~rfield/8177078v0.webrev/
>
> Thanks,
> Robert
>

From jan.lahoda at oracle.com  Thu Mar 30 12:48:07 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 30 Mar 2017 14:48:07 +0200
Subject: RFR 9: JDK-8177076: jshell tool: usability of completion
In-Reply-To: <58DC39DE.7070805@oracle.com>
References: <58D8CFBF.8050502@oracle.com> <58D98218.2030000@oracle.com>
 <58DA95A1.1010701@oracle.com> <58DABA07.2030007@oracle.com>
 <58DBEFEC.6010304@oracle.com> <58DC39DE.7070805@oracle.com>
Message-ID: <58DCFE87.6000102@oracle.com>

Thanks. Fixed the two below here:
http://cr.openjdk.java.net/~jlahoda/8177076/webrev.03/

Thanks,
    Jan

On 30.3.2017 00:49, Robert Field wrote:
> Looks really good.
>
> Two small things which don't need another round of review --
>
> 503         which will resolve the identifiers based on the content of
> the specified classpath.\n\t\t\
>
> should be "identifier" not "identifiers"
>
> 163 jshell.console.no.javadoc = <no javadoc found>
>
> Should, like the other cases, be "documentation" rather than "javadoc".
>
>
> Thanks,
> Robert
>
>
> On 03/29/17 10:33, Jan Lahoda wrote:
>> An updated version of the patch addressing the comments is here:
>> http://cr.openjdk.java.net/~jlahoda/8177076/webrev.02/
>>
>> On 28.3.2017 21:31, Robert Field wrote:
>>>
>>> On 03/28/17 09:56, Jan Lahoda wrote:
>>>> Hi Robert,
>>>>
>>>> An updated version of the patch:
>>>> http://cr.openjdk.java.net/~jlahoda/8177076/webrev.01/
>>>
>>> I like the new CompletionTask design!
>>>
>>> ConsoleIOContext.java
>>> ----------------------------
>>> Copyright need update.
>>
>> Fixed.
>>
>>>
>>> l10n.properties
>>> ------------------
>>> 156 jshell.console.see.next.page = <press space for next page, any other
>>> key to quit>
>>> tab also works, so should be "tab or space"
>>
>> The text is different now.
>>
>>>
>>> 157 jshell.console.see.next.javadoc = <press tab or space for next
>>> javadoc, any other key to quit>
>>> If this remains (see below suggestion to change this), then it should be
>>> "documentation" rather than "javadoc", as elsewhere.
>>
>> Done.
>>
>>>
>>> 493         If there is more than one completion, show possible
>>> completions.\n\t\t\
>>> " then possible completions will be shown"
>>
>> Done.
>>
>>>
>>> 496         After a complete expression, press "Shift-<tab> v" to
>>> introduce a new variable\n\t\t\
>>> It may not be clear to people what those keyboard actions are
>>> "After a complete expression, hold down <shift> while pressing <tab>,
>>> then release and press "v", the expression will be converted to a
>>> variable declaration"
>>
>> Done.
>>
>>>
>>> 498 Shift-<tab> i\n\t\t\
>>> Same treatment.  And maybe "propose possible imports which will resolve
>>> the name..."
>>>
>>
>> Done.
>>
>>> MergedTabShiftTabTest.java
>>> ---------------------------------
>>> No bug ID on test.
>>
>> Fixed.
>>
>>>
>>>
>>> User Interface
>>> ------------------
>>>
>>> I'm wondering, would it be more consistent, when displaying javadoc, if
>>> instead of displaying this prompt between pages:
>>>
>>>      <press tab or space for next javadoc, any other key to quit>
>>>
>>> That it did a redrawLine()?
>>>
>>>       <press tab again for next documentation>
>>>
>>>       jshell> l.add(
>>>
>>> Implementation-wise, that each doc page was an item in the the todo
>>> list.
>>> Basically, I think getting rid of all prompts would be cleanest.
>>
>> Done.
>>
>>>
>>> -------
>>>
>>> What a tease, tell me there is documentation, and then... ;-)
>>
>> Unfortunately, detecting whether there will be an actual javadoc is
>> costly, so I don't think we would want to do that upfront.
>>
>>>
>>> jshell> l
>>> l      long
>>>
>>> Signatures:
>>> l:java.util.List
>>>
>>> <press tab again to see documentation>
>>>
>>> jshell> l
>>> l:java.util.List
>>> <no javadoc found>
>>>
>>> jshell> l
>>>
>>> -------
>>>
>>> What to do when there are no completions?  Like:
>>>
>>> jshell> /zz<tab>
>>>
>>> or
>>>
>>> jshell> zz<tab>
>>>
>>> Before it did nothing, which is confusing.
>>> It could print "No completions" and redraw, but that would probably be
>>> noisy.
>>> I think what it does with this patch, which is redraw right below, is
>>> probably just right for snippets.
>>>
>>> jshell> /zz<tab>
>>> jshell> /zz
>>>
>>> Though, for commands (but not command arguments), maybe "No such
>>> command" and a redraw???
>>
>> Done.
>>
>> Jan
>>
>>>
>>> -------
>>>
>>> shift-tab for fixes sure is nice.
>>>
>>> --------------
>>>
>>> Nice work!
>>>
>>> -Robert
>>>
>>>
>>>
>>>>
>>>> On 27.3.2017 23:20, Robert Field wrote:
>>>>> ConsoleIOContext.java
>>>>> ----------------------------
>>>>>
>>>>> One of the key pieces of usability feedback was to step away from
>>>>> modal
>>>>> prompts.
>>>>> Where, the cycle is on-tab: next-info/redraw.
>>>>> These changes move to that mechanism.
>>>>> However, the "too many completions" case uses a modal prompt (556).
>>>>> Seems this could be handled the same way.
>>>>
>>>> Not sure if there's a modal prompt on ConsoleIOContext:556, rev.00 -
>>>> there is a single read and after that the execution continues one way
>>>> or another? It is true the code looked a little bit different that in
>>>> the other cases. Anyway, this code does not exist in rev.01.
>>>>
>>>>>
>>>>> Nit: the variable declared on line 211: "String test", is that
>>>>> intended
>>>>> to be "text"?
>>>>
>>>> Yes, thanks. Fixed.
>>>>
>>>>>
>>>>> SourceCodeAnalysisImpl.java
>>>>> ------------------------------------
>>>>>
>>>>> These changes appear to be incomplete or abandoned.  They introduce a
>>>>> variable that is never set.
>>>>
>>>> Used by tests. Comment added.
>>>>
>>>>>
>>>>> User Interface
>>>>> ------------------
>>>>>
>>>>> jshell> List li
>>>>> l ==> null
>>>>>
>>>>> jshell> li.<tab>
>>>>> add(               addAll(            clear() contains(
>>>>> containsAll(       equals( forEach(           get( getClass()
>>>>> hashCode()         indexOf(           isEmpty() iterator()
>>>>> lastIndexOf(       listIterator( notify() notifyAll()
>>>>> parallelStream()
>>>>> remove(            removeAll(         removeIf( replaceAll(
>>>>> retainAll(         set( size()             sort( spliterator()
>>>>> stream()           subList(           toArray( toString() wait(
>>>>>
>>>>> jshell> li.add<tab>
>>>>> add(      addAll(
>>>>>
>>>>> jshell> li.add(<tab>
>>>>> Current signatures:
>>>>> boolean List<E extends Object>.add(E e)
>>>>> void List<E extends Object>.add(int index, E element)
>>>>>
>>>>> Possible completions:
>>>>>
>>>>> l     xxx   xyz
>>>>>
>>>>> <press tab again to see documentation>
>>>>>
>>>>> jshell> li.add(
>>>>>
>>>>> The first and second tab used in the example above give possible
>>>>> completions without a leading header "Possible completions:" of the
>>>>> third case. This should be consistent.
>>>>> The header could be added everywhere, but I think that would be noisy.
>>>>> The change in ordering is confusing anyhow.
>>>>> The prompt "<press tab again to see documentation>" would be more
>>>>> intuitive grouped with the method signatures.
>>>>> The header "Current signatures:", I think would be better
>>>>> "Signatures:",  "Method signatures:", or "Signatures of add:".
>>>>> Applying these:
>>>>>
>>>>> jshell> li.add(<tab>
>>>>> l     xxx   xyz
>>>>>
>>>>> Method signatures:
>>>>> boolean List<E extends Object>.add(E e)
>>>>> void List<E extends Object>.add(int index, E element)
>>>>>
>>>>> <press tab again to see documentation>
>>>>
>>>> Done. (The caption is "Signatures:", as in general, it is not always
>>>> method signatures there.)
>>>>
>>>>>
>>>>> jshell> li.add(
>>>>>
>>>>> See above, under ConsoleIOContext.java, additionally, the inlining of
>>>>> more text makes this more confusing, as no indication of what to do if
>>>>> you don't want it --
>>>>
>>>> Sorry, but I am not sure what is the action requested here.
>>>>
>>>>>
>>>>> jshell> 4 + <tab>
>>>>>
>>>>> Gets replaced with:
>>>>>
>>>>> jshell> 4 + 542 possible completions. Press <tab> or y to see them
>>>>> all.
>>>>>
>>>>> I'd opt for consistency (which also uses this prompt that is used
>>>>> in the
>>>>> after documentation case):
>>>>>
>>>>> jshell> 4 + <tab>
>>>>> <press tab again to see all possible completions; total possible
>>>>> completions: 542>
>>>>
>>>> Done. To do that, I re-wrote the support a little (as this basically
>>>> introduces a new state in the state "graph".)
>>>>
>>>>>
>>>>> jshell> 4 +
>>>>>
>>>>> I see also that if documentation is displayed and there are smart
>>>>> items,
>>>>> then the last tab choice is all items.  In no other case are all items
>>>>> offered if there are smart items.
>>>>
>>>> I believe all items may be shown where smart items exist and there's
>>>> no documnetation:
>>>> jshell> String str = new Str<tab>
>>>> String(
>>>>
>>>> <press tab again to see all possible completions>
>>>>
>>>> jshell> String str = new Str<tab>
>>>> StreamCorruptedException(          StreamTokenizer(
>>>> String(                            StringBuffer(
>>>> StringBufferInputStream(           StringBuilder(
>>>> StringIndexOutOfBoundsException(   StringJoiner(
>>>> StringReader(                      StringTokenizer( StringWriter(
>>>>
>>>> jshell> String str = new Str
>>>>
>>>>>
>>>>> The command help is a very nice feature.
>>>>>
>>>>> I'm unsure of the "<press tab again to see synopsis>" prompt line
>>>>> as the
>>>>> synopsis is also one line.
>>>>
>>>> There may be multiple lines with synopsis, I believe:
>>>> jshell> /e<tab>
>>>> /edit    /env     /exit
>>>>
>>>> <press tab again to see synopsis>
>>>>
>>>> jshell> /e<tab>
>>>> /edit
>>>> edit a source entry referenced by name or id
>>>>
>>>> /env
>>>> view or change the evaluation context
>>>>
>>>> /exit
>>>> exit jshell
>>>>
>>>> <press tab again to see full documentation>
>>>>
>>>> jshell> /e
>>>>
>>>>>
>>>>> Overall
>>>>> ---------
>>>>>
>>>>> Perhaps it would be good to lay this out as a UI design before turning
>>>>> it into code.
>>>>>
>>>>> Naively (as I haven't done it), I think it may be possible to
>>>>> regularize
>>>>> the processing (starting as pseudo-code derived from the UI design).
>>>>> I note 19 conditionals in the new code. I'm concerned about the
>>>>> branching complexity not only for code maintenance and testing but for
>>>>> what it implies about the user model.
>>>>
>>>> I think the primary question is if it works well for the users. Not
>>>> sure if the # of conditionals is so significant. I didn't really try
>>>> to minimize the # of conditions, I tried to make the code
>>>> understandable, making it simpler to say "if the situation is this,
>>>> then the outcome will be that". (The new revision goes one more step
>>>> in that direction, I think.)
>>>>
>>>> (Having this in the code also helps to cover all the corners, which
>>>> are easy to miss otherwise.)
>>>>
>>>> Anyway - if there's a UI design covering all the cases
>>>> (command/expression, has/hasn't doc, has/hasn't smart items,
>>>> has/hasn't additional items, there are/aren't too many items), I can
>>>> implement it.
>>>>
>>>> Jan
>>>>
>>>>>
>>>>> I will be available to help on this tomorrow, if you would like.
>>>>>
>>>>> -Robert
>>>>>
>>>>>
>>>>> On 03/27/17 01:39, Jan Lahoda wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I'd like to ask for a review of a patch that merges shift-tab and tab
>>>>>> completions, and changes the fix shortcut to shift-tab:
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177076
>>>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8177076/webrev.00/
>>>>>>
>>>>>> Any feedback is welcome,
>>>>>>      Jan
>>>>>
>>>
>

From robert.field at oracle.com  Fri Mar 31 01:21:44 2017
From: robert.field at oracle.com (Robert Field)
Date: Thu, 30 Mar 2017 18:21:44 -0700
Subject: JShell tool tutorial
Message-ID: <58DDAF28.3040205@oracle.com>

I'm working on a better web location, but here is the tutorial I've been 
working on:

     http://cr.openjdk.java.net/~rfield/tutorial/JShellTutorial.html

It is still a work-in-progress, but it still has a lot of information 
that isn't available anywhere else.

I'd love feedback, at any granularity, from subjects that should be 
added to grammar/spelling.

Enjoy,
Robert


From john.r.rose at oracle.com  Fri Mar 31 23:57:06 2017
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 31 Mar 2017 16:57:06 -0700
Subject: RFR 9: JDK-8177076: jshell tool: usability of completion
In-Reply-To: <58D8CFBF.8050502@oracle.com>
References: <58D8CFBF.8050502@oracle.com>
Message-ID: <EB210BCB-2641-4FA9-9E8E-CF3804F1E6F5@oracle.com>

On Mar 27, 2017, at 1:39 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:
> 
> Hello,
> 
> I'd like to ask for a review of a patch that merges shift-tab and tab completions, and changes the fix shortcut to shift-tab:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8177076
> Webrev: http://cr.openjdk.java.net/~jlahoda/8177076/webrev.00/
> 
> Any feedback is welcome,
>     Jan


A couple of comments (on webrev.03):

This help string has the wrong whitespace:

+        a variable declaration whose type is based on the type of the expression.\n\t\t\
+Shift-<tab> i\n\t\t\

The first \n\t\t\ should be \n\n.

Help strings should not mention <fix> anymore:

+Invalid <fix> character.  Use "i" for auto-import or "v" for variable creation.  For more information see:\n\
+   /help shortcuts

I suggest:  Unexpected character after Shift-Tab.  Use "i" ?

I built your patch and tried it out.  I like the new behavior very much.
The "Shift-Tab i" command is more friendly.

Thanks!

I noticed a couple of oddities.

First of all, "/help /set <Tab>" prints the "/set" subcommands, but "/help set <Tab>" does not.

jshell> /help /set <Tab>
editor       feedback     format       mode         prompt       start        truncation   
jshell> /help set <Tab>
get information about jshell   <==== YES, I THOUGHT I WAS DOING THAT?


Second, when completing inside help subcommands, the "todo" list is packed with generic
"help on help", which promises information but isn't that useful.  If you are already saying
"/help intro <Tab>" it doesn't seem very helpful to back up to the same help text as
"/help <Tab><Tab>".

A further example of the odd help-doc is below.

? John

jshell> /help /set tr<Tab>
===REDRAW===>
jshell> /help /set truncation<Tab>
<press tab again to see synopsis>

jshell> /help /set truncation<Tab>
get information about jshell   <==== NOT A SYNOPSIS OF "truncation"

<press tab again to see full documentation>

jshell> /help /set truncation<Tab>
Display information about jshell.   <==== NOT FULL DOC OF "truncation"
/help
    List the jshell commands and help subjects.

/help <command>
    Display information about the specified command. The slash must be included.
    Only the first few letters of the command are needed -- if more than one
    each will be displayed.  Example:  /help /li

/help <subject>
    Display information about the specified help subject. Example: /help intro

jshell>