From jan.lahoda at oracle.com  Mon Oct  3 20:04:13 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 3 Oct 2016 22:04:13 +0200
Subject: RFR 8145263: JShell API: Change the format of
	SourceCodeAnalysis#documentation
In-Reply-To: <1577bb420e8.2765.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
References: <CAHjBcHOSbneONaCRjWStxCXYENvyoOxp5RuAStfnBp4-+wZJxw@mail.gmail.com>
	<566ED116.3080502@oracle.com>
	<CAHjBcHN3bMNw+xZ96EOXHNFYVMhT7PxX5PQDdjueE10N+7gg2w@mail.gmail.com>
	<56707E7E.4020704@oracle.com>
	<CAHjBcHMXDQHb-xVnpqG7yGa7Y5tzbUqzug-Y-+gPy0DrUND8nQ@mail.gmail.com>
	<57E979DC.2060007@oracle.com>
	<CAHjBcHOrmtYjiMQ=gPbEKYTTxLDJKT+b7cORPJDuzOXHgi4V1w@mail.gmail.com>
	<CAHjBcHPh3KWx6E+d=_noepg6qfb8Wzh4j1sEWNKf8SFZDWAHng@mail.gmail.com>
	<1577bb420e8.2765.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
Message-ID: <57F2B9BD.30202@oracle.com>

Looks OK to me too. I don't have a strong opinion on the throws clause.

Jan

On 30.9.2016 17:26, Robert Field wrote:
> Nice!
>
> Includes a lot of touches to make it more readable and useful.
>
> Passing on one bit of feedback from Brian, put into my words: since we
> are going to be adding full javadoc access, we want this signature
> output crisp. So, the throws clause is probably overkill.
>
> Thanks,
> Robert
>
> On September 30, 2016 4:04:03 AM ShinyaYoshida <bitterfoxc at gmail.com> wrote:
>
>> Hi Robert and Jan,
>> I've updated the webrev to current code base:
>> http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.10/
>>
>> Could you review this?
>>
>> Regards,
>> shinyafox(Shinya Yoshida)
>>
>>
>> 2016-09-27 4:51 GMT+09:00 ShinyaYoshida <bitterfoxc at gmail.com
>> <mailto:bitterfoxc at gmail.com>>:
>>
>>     Hi Robert,
>>     Never mind! And I'm also sorry for having left this.
>>
>>     I'll try updating webrev to current code base until 1/Oct.
>>
>>     BTW, currently a lot of things in jshell are configurable, could
>>     signature of documentation also be configurable in future(JDK10 or
>>     9.1 or ...)?
>>
>>     Thank you,
>>     shinyafox(Shinya Yoshida)
>>
>>     2016-09-26 12:41 GMT-07:00 Robert Field <robert.field at oracle.com
>>     <mailto:robert.field at oracle.com>>:
>>
>>         In reviewing outstanding issues, we discovered this RFR which
>>         was left hanging.
>>
>>         Our sincere apologies for dropping the ball on this.
>>
>>         We are juggling a lot, if we miss something like this in the
>>         future, please let us know.
>>
>>         I have made some changes in the issue, please note them.  I
>>         know there have been some underlying changes as well
>>         (parameter names from source).
>>
>>         If you would be willing to update this RFR we will review
>>         promptly.
>>
>>         Thank you and sorry,
>>         Robert
>>
>>
>>         On 12/15/15 17:07, ShinyaYoshida wrote:
>>>         Hi Jan and Robert,
>>>         Thank you.
>>>
>>>         I've filed:
>>>         https://bugs.openjdk.java.net/browse/JDK-8145473
>>>         <https://bugs.openjdk.java.net/browse/JDK-8145473>
>>>
>>>         Ok, I put the type parameters for the constructor before the
>>>         traditional(current) form:
>>>         http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.01/ <http://cr.openjdk.java.net/%7Eshinyafox/kulla/8145263/webrev.01/>
>>>
>>>         Please review it again.
>>>
>>>         Regards,
>>>         shinyafox(Shinya Yoshida)
>>>
>>>
>>>         2015-12-16 5:56 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com
>>>         <mailto:jan.lahoda at oracle.com>>:
>>>
>>>             Hi Shinya,
>>>
>>>             On 14.12.2015 15:40, ShinyaYoshida wrote:
>>>
>>>                 Hi Jan,
>>>                 Thank you for your review.
>>>
>>>                 2015-12-14 23:24 GMT+09:00 Jan Lahoda
>>>                 <jan.lahoda at oracle.com <mailto:jan.lahoda at oracle.com>
>>>                 <mailto:jan.lahoda at oracle.com
>>>                 <mailto:jan.lahoda at oracle.com>>>:
>>>
>>>                     Hi Shinya,
>>>
>>>                     Generally, looks good, thanks for looking at
>>>                 this! Two comments:
>>>                     -for parameter names, I was hoping we could get
>>>                 them from the
>>>                     sources (if/when available), but we are not doing
>>>                 that now, and
>>>                     hiding synthetic parameter names makes sense to
>>>                 me. So this is OK,
>>>                     and if we at some point start to parse parameter
>>>                 names from the
>>>                     sources, we can tweak the code to do the right thing.
>>>
>>>                 I think that there should be the issue for the
>>>                 parameter names.
>>>                 Do you have the issue for that?
>>>
>>>
>>>             No issue for this yet.
>>>
>>>                 If not, should I create it?
>>>
>>>
>>>             Sure, thanks.
>>>
>>>
>>>
>>>                     -not sure if marking constructors with ".new"
>>>                     ("type-name.new(<parameters>)") will be clear -
>>>                 do you think the
>>>                     traditional form ("type-name(<parameters>)") is
>>>                 unclear?
>>>
>>>
>>>                 When I consider the constructor with the generics
>>>                 like following, I
>>>                 notice that the traditional(current) form is
>>>                 difficult to represent it.
>>>                 class C<T> { <U> C(U u) {} }
>>>                 So I choose that format which is like the constructor
>>>                 reference.
>>>
>>>
>>>             I think generic constructors (i.e. constructors that
>>>             themselves have type parameters) are very uncommon, so I
>>>             wouldn't optimize for those. Having the format nice for
>>>             usual constructors is more important, I think, even if
>>>             the format for these uncommon constructors would be uglier.
>>>
>>>             Thanks,
>>>                 Jan
>>>
>>>
>>>
>>>                 Another possible representation is "new <Generics>
>>>                 type-name<Generics>(<parameters>)" which is similar
>>>                 to the invocation of
>>>                 the constructor with generics.
>>>
>>>                 What do you think?
>>>
>>>                 Regards,
>>>                 shinyafox(Shinya Yoshida)
>>>
>>>
>>>                     Thanks,
>>>                          Jan
>>>
>>>
>>>                     On 13.12.2015 07:33, ShinyaYoshida wrote:
>>>
>>>                         Hi Jan and Robert,
>>>                         I'd like to propose changing the format of
>>>                         SourceCodeAnalysis#documentation.
>>>
>>>                         The detail of the change is on the issue 8145263:
>>>                 https://bugs.openjdk.java.net/browse/JDK-8145263
>>>                 <https://bugs.openjdk.java.net/browse/JDK-8145263>
>>>                         Please see it.
>>>
>>>                         You can see the more example in the test of
>>>                 my patch.
>>>
>>>                         Patch is here:
>>>                 http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.00/
>>>                 <http://cr.openjdk.java.net/%7Eshinyafox/kulla/8145263/webrev.00/>
>>>
>>>                         Please consider my proposal and review the patch.
>>>
>>>                         Regards,
>>>                         shinyafox(Shinya Yoshida)
>>>
>>>
>>>
>>
>>
>>

From bitterfoxc at gmail.com  Thu Oct  6 05:02:16 2016
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Thu, 6 Oct 2016 14:02:16 +0900
Subject: RFR 8145263: JShell API: Change the format of
	SourceCodeAnalysis#documentation
In-Reply-To: <57F2B9BD.30202@oracle.com>
References: <CAHjBcHOSbneONaCRjWStxCXYENvyoOxp5RuAStfnBp4-+wZJxw@mail.gmail.com>
	<566ED116.3080502@oracle.com>
	<CAHjBcHN3bMNw+xZ96EOXHNFYVMhT7PxX5PQDdjueE10N+7gg2w@mail.gmail.com>
	<56707E7E.4020704@oracle.com>
	<CAHjBcHMXDQHb-xVnpqG7yGa7Y5tzbUqzug-Y-+gPy0DrUND8nQ@mail.gmail.com>
	<57E979DC.2060007@oracle.com>
	<CAHjBcHOrmtYjiMQ=gPbEKYTTxLDJKT+b7cORPJDuzOXHgi4V1w@mail.gmail.com>
	<CAHjBcHPh3KWx6E+d=_noepg6qfb8Wzh4j1sEWNKf8SFZDWAHng@mail.gmail.com>
	<1577bb420e8.2765.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<57F2B9BD.30202@oracle.com>
Message-ID: <CAHjBcHOZo-55TZHhnC8UkWpzxeHtvgkw_v9VwkSTSfra2i_Z6g@mail.gmail.com>

Hi Robert, Brian and Jan,
Thank you for your review and sorry for late reply.

I think throws-clause is still necessary information even if javadoc is
implemented because some of methods doesn't provide javadoc, such as user
defined methods or methods in user loaded jars.
What do you think?
If you think it's still overkill, I'll drop it.

Regards,
shinyafox(Shinya Yoshida)


2016-10-04 5:04 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com>:

> Looks OK to me too. I don't have a strong opinion on the throws clause.
>
> Jan
>
> On 30.9.2016 17:26, Robert Field wrote:
>
>> Nice!
>>
>> Includes a lot of touches to make it more readable and useful.
>>
>> Passing on one bit of feedback from Brian, put into my words: since we
>> are going to be adding full javadoc access, we want this signature
>> output crisp. So, the throws clause is probably overkill.
>>
>> Thanks,
>> Robert
>>
>> On September 30, 2016 4:04:03 AM ShinyaYoshida <bitterfoxc at gmail.com>
>> wrote:
>>
>> Hi Robert and Jan,
>>> I've updated the webrev to current code base:
>>> http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.10/
>>>
>>> Could you review this?
>>>
>>> Regards,
>>> shinyafox(Shinya Yoshida)
>>>
>>>
>>> 2016-09-27 4:51 GMT+09:00 ShinyaYoshida <bitterfoxc at gmail.com
>>> <mailto:bitterfoxc at gmail.com>>:
>>>
>>>     Hi Robert,
>>>     Never mind! And I'm also sorry for having left this.
>>>
>>>     I'll try updating webrev to current code base until 1/Oct.
>>>
>>>     BTW, currently a lot of things in jshell are configurable, could
>>>     signature of documentation also be configurable in future(JDK10 or
>>>     9.1 or ...)?
>>>
>>>     Thank you,
>>>     shinyafox(Shinya Yoshida)
>>>
>>>     2016-09-26 12:41 GMT-07:00 Robert Field <robert.field at oracle.com
>>>     <mailto:robert.field at oracle.com>>:
>>>
>>>         In reviewing outstanding issues, we discovered this RFR which
>>>         was left hanging.
>>>
>>>         Our sincere apologies for dropping the ball on this.
>>>
>>>         We are juggling a lot, if we miss something like this in the
>>>         future, please let us know.
>>>
>>>         I have made some changes in the issue, please note them.  I
>>>         know there have been some underlying changes as well
>>>         (parameter names from source).
>>>
>>>         If you would be willing to update this RFR we will review
>>>         promptly.
>>>
>>>         Thank you and sorry,
>>>         Robert
>>>
>>>
>>>         On 12/15/15 17:07, ShinyaYoshida wrote:
>>>
>>>>         Hi Jan and Robert,
>>>>         Thank you.
>>>>
>>>>         I've filed:
>>>>         https://bugs.openjdk.java.net/browse/JDK-8145473
>>>>         <https://bugs.openjdk.java.net/browse/JDK-8145473>
>>>>
>>>>         Ok, I put the type parameters for the constructor before the
>>>>         traditional(current) form:
>>>>         http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.01/
>>>> <http://cr.openjdk.java.net/%7Eshinyafox/kulla/8145263/webrev.01/>
>>>>
>>>>         Please review it again.
>>>>
>>>>         Regards,
>>>>         shinyafox(Shinya Yoshida)
>>>>
>>>>
>>>>         2015-12-16 5:56 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com
>>>>         <mailto:jan.lahoda at oracle.com>>:
>>>>
>>>>             Hi Shinya,
>>>>
>>>>             On 14.12.2015 15:40, ShinyaYoshida wrote:
>>>>
>>>>                 Hi Jan,
>>>>                 Thank you for your review.
>>>>
>>>>                 2015-12-14 23:24 GMT+09:00 Jan Lahoda
>>>>                 <jan.lahoda at oracle.com <mailto:jan.lahoda at oracle.com>
>>>>                 <mailto:jan.lahoda at oracle.com
>>>>
>>>>                 <mailto:jan.lahoda at oracle.com>>>:
>>>>
>>>>                     Hi Shinya,
>>>>
>>>>                     Generally, looks good, thanks for looking at
>>>>                 this! Two comments:
>>>>                     -for parameter names, I was hoping we could get
>>>>                 them from the
>>>>                     sources (if/when available), but we are not doing
>>>>                 that now, and
>>>>                     hiding synthetic parameter names makes sense to
>>>>                 me. So this is OK,
>>>>                     and if we at some point start to parse parameter
>>>>                 names from the
>>>>                     sources, we can tweak the code to do the right
>>>> thing.
>>>>
>>>>                 I think that there should be the issue for the
>>>>                 parameter names.
>>>>                 Do you have the issue for that?
>>>>
>>>>
>>>>             No issue for this yet.
>>>>
>>>>                 If not, should I create it?
>>>>
>>>>
>>>>             Sure, thanks.
>>>>
>>>>
>>>>
>>>>                     -not sure if marking constructors with ".new"
>>>>                     ("type-name.new(<parameters>)") will be clear -
>>>>                 do you think the
>>>>                     traditional form ("type-name(<parameters>)") is
>>>>                 unclear?
>>>>
>>>>
>>>>                 When I consider the constructor with the generics
>>>>                 like following, I
>>>>                 notice that the traditional(current) form is
>>>>                 difficult to represent it.
>>>>                 class C<T> { <U> C(U u) {} }
>>>>                 So I choose that format which is like the constructor
>>>>                 reference.
>>>>
>>>>
>>>>             I think generic constructors (i.e. constructors that
>>>>             themselves have type parameters) are very uncommon, so I
>>>>             wouldn't optimize for those. Having the format nice for
>>>>             usual constructors is more important, I think, even if
>>>>             the format for these uncommon constructors would be uglier.
>>>>
>>>>             Thanks,
>>>>                 Jan
>>>>
>>>>
>>>>
>>>>                 Another possible representation is "new <Generics>
>>>>                 type-name<Generics>(<parameters>)" which is similar
>>>>                 to the invocation of
>>>>                 the constructor with generics.
>>>>
>>>>                 What do you think?
>>>>
>>>>                 Regards,
>>>>                 shinyafox(Shinya Yoshida)
>>>>
>>>>
>>>>                     Thanks,
>>>>                          Jan
>>>>
>>>>
>>>>                     On 13.12.2015 07:33, ShinyaYoshida wrote:
>>>>
>>>>                         Hi Jan and Robert,
>>>>                         I'd like to propose changing the format of
>>>>                         SourceCodeAnalysis#documentation.
>>>>
>>>>                         The detail of the change is on the issue
>>>> 8145263:
>>>>                 https://bugs.openjdk.java.net/browse/JDK-8145263
>>>>                 <https://bugs.openjdk.java.net/browse/JDK-8145263>
>>>>                         Please see it.
>>>>
>>>>                         You can see the more example in the test of
>>>>                 my patch.
>>>>
>>>>                         Patch is here:
>>>>                 http://cr.openjdk.java.net/~sh
>>>> inyafox/kulla/8145263/webrev.00/
>>>>                 <http://cr.openjdk.java.net/%7
>>>> Eshinyafox/kulla/8145263/webrev.00/>
>>>>
>>>>                         Please consider my proposal and review the
>>>> patch.
>>>>
>>>>                         Regards,
>>>>                         shinyafox(Shinya Yoshida)
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>

From robert.field at oracle.com  Thu Oct  6 20:40:39 2016
From: robert.field at oracle.com (Robert Field)
Date: Thu, 06 Oct 2016 13:40:39 -0700
Subject: RFR 8163840: jshell tool: provide way to display configuration
	settings
Message-ID: <57F6B6C7.8020905@oracle.com>

Please review this change which allows all settings to be shown.

Bug:
     https://bugs.openjdk.java.net/browse/JDK-8163840

Webrev:
     http://cr.openjdk.java.net/~rfield/8163840v2.webrev/

Thanks,
Robert


From bitterfoxc at gmail.com  Fri Oct  7 15:45:26 2016
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Sat, 8 Oct 2016 00:45:26 +0900
Subject: RFR 8167343: JShell: Completeness analysis infers an incomplete
	declaration as COMPLETE_WITH_SEMI, which is a first line of Allman style
Message-ID: <CAHjBcHNFwr9z2fYUXdh+Kort64PST5YUeAz=TDm-oZo08gPqng@mail.gmail.com>

Hi all,
Could you review this?

webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8167343/webrev.00/
bugs: https://bugs.openjdk.java.net/browse/JDK-8167343

Regards,
shinyafox(Shinya Yoshida)

From robert.field at oracle.com  Fri Oct  7 17:19:40 2016
From: robert.field at oracle.com (Robert Field)
Date: Fri, 07 Oct 2016 10:19:40 -0700
Subject: RFR 8167128: jshell tool: /drop of statement gives confusing output
Message-ID: <57F7D92C.4040102@oracle.com>

Using /drop on anything other than a declaration in the jshell tool 
gives an error (and a confusing one at that).
For example, dropping a statement or variable value query causes an error.
The underlying cause is that drop() in the API only has semantic impact 
when declarations are changed and so was restricted to declarations.
If does however also change the status and the tool uses the status, for 
example to determine which snippets are saved or, by default, listed.
There is no advantage to this restriction and it reduces symmetry. This 
change allows drop (at all levels) for all kinds of snippets.

Bug:
     https://bugs.openjdk.java.net/browse/JDK-8167128

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

API:
     http://cr.openjdk.java.net/~rfield/8167128v0.API/

The API changes are minor and include:
http://cr.openjdk.java.net/~rfield/8167128v0.API/jdk/jshell/JShell.html#drop-jdk.jshell.Snippet-
http://cr.openjdk.java.net/~rfield/8167128v0.API/jdk/jshell/PersistentSnippet.html
http://cr.openjdk.java.net/~rfield/8167128v0.API/jdk/jshell/Snippet.Status.html

Thanks,
Robert


From robert.field at oracle.com  Fri Oct  7 18:07:35 2016
From: robert.field at oracle.com (Robert Field)
Date: Fri, 07 Oct 2016 11:07:35 -0700
Subject: RFR 8167343: JShell: Completeness analysis infers an incomplete
	declaration as COMPLETE_WITH_SEMI, which is a first line of Allman style
In-Reply-To: <CAHjBcHNFwr9z2fYUXdh+Kort64PST5YUeAz=TDm-oZo08gPqng@mail.gmail.com>
References: <CAHjBcHNFwr9z2fYUXdh+Kort64PST5YUeAz=TDm-oZo08gPqng@mail.gmail.com>
Message-ID: <57F7E467.3060002@oracle.com>


On 10/07/16 08:45, ShinyaYoshida wrote:
> Hi all,
> Could you review this?
>
> webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8167343/webrev.00/
> bugs: https://bugs.openjdk.java.net/browse/JDK-8167343
>
> Regards,
> shinyafox(Shinya Yoshida)

This looks good.

We need to keep in mind that the completion analysis is only a guess, 
and cannot always be correct -- we need to be careful not to infinitely 
chase perfection.
This case though is an important one -- good catch.

I have only very minor nits which you can choose to address, or not, 
without need for re-review:

169: The name is rather hard to read when used and doesn't match the 
tokens, at this level it is BRACES not LBRACE -- maybe XBRACESNEEDED

651-653:  Purely personal style.  Could be written:   expectBrace |= 
token.kind.expectBrace();

678: The style in this file would generally have the '?' and the ':' on 
their own lines.

Thumbs up to push!

Thanks,
Robert


From jan.lahoda at oracle.com  Mon Oct 10 10:21:32 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 10 Oct 2016 12:21:32 +0200
Subject: RFR JDK-8166890: JShell: locks forever when input is piped
Message-ID: <57FB6BAC.5020200@oracle.com>

Hi,

When an input is redirected to jshell, like:
echo "1" | jshell

Then jshell locks, as it waits for the terminal to report the cursor 
position. Also, when the input is fully read, the 
StopDetectingInputStream is set to the CLOSED state, but the state may 
be cleared using setState, causing the readers from the 
StopDetectingInputStream to wait indefinitely.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8166890

Webrevs:
jdk:
http://cr.openjdk.java.net/~jlahoda/8166890/jdk.00/
langtools:
http://cr.openjdk.java.net/~jlahoda/8166890/langtools.00/

Any feedback is welcome.

Thanks,
    Jan

From bitterfoxc at gmail.com  Mon Oct 10 13:20:22 2016
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Mon, 10 Oct 2016 22:20:22 +0900
Subject: RFR JDK-8166890: JShell: locks forever when input is piped
In-Reply-To: <57FB6BAC.5020200@oracle.com>
References: <57FB6BAC.5020200@oracle.com>
Message-ID: <CAHjBcHPpn2Wz986DNPoY+9Nb9pD_g8yX27UxrfWKRW7Oj45D_Q@mail.gmail.com>

Hi Jan,

Thank you for fixing this!
Your patch works well on my environment!
Couldn't we write a test case for this?

Trivial:
  synchronized (StopDetectingInputStream.this) {
-     state = StopDetectingInputStream.State.CLOSED;
+     shutdown();
  }

Is this synchronized block still necessary?
Could it be removed because shutdown() is a synchronized method?

Regards,
shinyafox(Shinya Yoshida)


2016-10-10 19:21 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com>:

> Hi,
>
> When an input is redirected to jshell, like:
> echo "1" | jshell
>
> Then jshell locks, as it waits for the terminal to report the cursor
> position. Also, when the input is fully read, the StopDetectingInputStream
> is set to the CLOSED state, but the state may be cleared using setState,
> causing the readers from the StopDetectingInputStream to wait indefinitely.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8166890
>
> Webrevs:
> jdk:
> http://cr.openjdk.java.net/~jlahoda/8166890/jdk.00/
> langtools:
> http://cr.openjdk.java.net/~jlahoda/8166890/langtools.00/
>
> Any feedback is welcome.
>
> Thanks,
>    Jan
>

From peter.levart at gmail.com  Mon Oct 10 13:55:22 2016
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 10 Oct 2016 15:55:22 +0200
Subject: using jshell in executable UNIX scripts
Message-ID: <80a6b79b-296b-3251-e027-3a1483f8e5b4@gmail.com>

Hi,

"jshell" command is a very nice interactive Java shell, but it could 
also be used for scripting. An executable script in any major UNIX OS is 
a textual file with executable permissions that starts with the 
following two characters: #!
The rest of the 1st line is the path to the interpreter executable and 
any arguments passed to it. The last argument passed to the interpreter 
is the path to the executable script. In case of jshell, one would want 
such script to be written like:

#!/home/peter/Apps64/jdk9/bin/jshell

System.out.println("Hello World!");

/exit


The problem is that jshell tries to parse the 1st line using jshell 
syntax and the result of running above executable script is:

| Error:
|  illegal character: '#'
| #!/home/peter/Apps64/jdk9/bin/jshell
|  ^
|  Error:
|  illegal start of expression
|  #!/home/peter/Apps64/jdk9/bin/jshell
|    ^
Hello World!


The script is actually executed, but the syntax error encountered in the 
1st line is printed too.

Would it be possible for jshell to skip 1st line if it starts with 
characters #! like other shells do?


Regards, Peter


From jan.lahoda at oracle.com  Mon Oct 10 14:19:19 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 10 Oct 2016 16:19:19 +0200
Subject: RFR JDK-8166890: JShell: locks forever when input is piped
In-Reply-To: <CAHjBcHPpn2Wz986DNPoY+9Nb9pD_g8yX27UxrfWKRW7Oj45D_Q@mail.gmail.com>
References: <57FB6BAC.5020200@oracle.com>
	<CAHjBcHPpn2Wz986DNPoY+9Nb9pD_g8yX27UxrfWKRW7Oj45D_Q@mail.gmail.com>
Message-ID: <57FBA367.6040608@oracle.com>

HI Shinya,

Thanks for the comments!

On 10.10.2016 15:20, ShinyaYoshida wrote:
> Hi Jan,
>
> Thank you for fixing this!
> Your patch works well on my environment!
> Couldn't we write a test case for this?

I was thinking of that, but wasn't sure how to test this.

>
> Trivial:
>    synchronized (StopDetectingInputStream.this) {
> -     state = StopDetectingInputStream.State.CLOSED;
> +     shutdown();
>    }
>
> Is this synchronized block still necessary?
> Could it be removed because shutdown() is a synchronized method?

Oops, right - I mean to remove it, but forgot. Thanks noticing. Updated 
webrev:
http://cr.openjdk.java.net/~jlahoda/8166890/langtools.01/

Jan

>
> Regards,
> shinyafox(Shinya Yoshida)
>
> 2016-10-10 19:21 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com
> <mailto:jan.lahoda at oracle.com>>:
>
>     Hi,
>
>     When an input is redirected to jshell, like:
>     echo "1" | jshell
>
>     Then jshell locks, as it waits for the terminal to report the cursor
>     position. Also, when the input is fully read, the
>     StopDetectingInputStream is set to the CLOSED state, but the state
>     may be cleared using setState, causing the readers from the
>     StopDetectingInputStream to wait indefinitely.
>
>     Bug:
>     https://bugs.openjdk.java.net/browse/JDK-8166890
>     <https://bugs.openjdk.java.net/browse/JDK-8166890>
>
>     Webrevs:
>     jdk:
>     http://cr.openjdk.java.net/~jlahoda/8166890/jdk.00/
>     <http://cr.openjdk.java.net/~jlahoda/8166890/jdk.00/>
>     langtools:
>     http://cr.openjdk.java.net/~jlahoda/8166890/langtools.00/
>     <http://cr.openjdk.java.net/~jlahoda/8166890/langtools.00/>
>
>     Any feedback is welcome.
>
>     Thanks,
>         Jan
>
>

From robert.field at oracle.com  Mon Oct 10 15:14:26 2016
From: robert.field at oracle.com (Robert Field)
Date: Mon, 10 Oct 2016 08:14:26 -0700
Subject: RFR JDK-8166890: JShell: locks forever when input is piped
In-Reply-To: <57FBA367.6040608@oracle.com>
References: <57FB6BAC.5020200@oracle.com>	<CAHjBcHPpn2Wz986DNPoY+9Nb9pD_g8yX27UxrfWKRW7Oj45D_Q@mail.gmail.com>
	<57FBA367.6040608@oracle.com>
Message-ID: <57FBB052.8020005@oracle.com>

Thumbs up

-Robert

On 10/10/16 07:19, Jan Lahoda wrote:
> HI Shinya,
>
> Thanks for the comments!
>
> On 10.10.2016 15:20, ShinyaYoshida wrote:
>> Hi Jan,
>>
>> Thank you for fixing this!
>> Your patch works well on my environment!
>> Couldn't we write a test case for this?
>
> I was thinking of that, but wasn't sure how to test this.
>
>>
>> Trivial:
>>    synchronized (StopDetectingInputStream.this) {
>> -     state = StopDetectingInputStream.State.CLOSED;
>> +     shutdown();
>>    }
>>
>> Is this synchronized block still necessary?
>> Could it be removed because shutdown() is a synchronized method?
>
> Oops, right - I mean to remove it, but forgot. Thanks noticing. 
> Updated webrev:
> http://cr.openjdk.java.net/~jlahoda/8166890/langtools.01/
>
> Jan
>
>>
>> Regards,
>> shinyafox(Shinya Yoshida)
>>
>> 2016-10-10 19:21 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com
>> <mailto:jan.lahoda at oracle.com>>:
>>
>>     Hi,
>>
>>     When an input is redirected to jshell, like:
>>     echo "1" | jshell
>>
>>     Then jshell locks, as it waits for the terminal to report the cursor
>>     position. Also, when the input is fully read, the
>>     StopDetectingInputStream is set to the CLOSED state, but the state
>>     may be cleared using setState, causing the readers from the
>>     StopDetectingInputStream to wait indefinitely.
>>
>>     Bug:
>>     https://bugs.openjdk.java.net/browse/JDK-8166890
>>     <https://bugs.openjdk.java.net/browse/JDK-8166890>
>>
>>     Webrevs:
>>     jdk:
>>     http://cr.openjdk.java.net/~jlahoda/8166890/jdk.00/
>>     <http://cr.openjdk.java.net/~jlahoda/8166890/jdk.00/>
>>     langtools:
>>     http://cr.openjdk.java.net/~jlahoda/8166890/langtools.00/
>> <http://cr.openjdk.java.net/~jlahoda/8166890/langtools.00/>
>>
>>     Any feedback is welcome.
>>
>>     Thanks,
>>         Jan
>>
>>


From bitterfoxc at gmail.com  Mon Oct 10 15:19:29 2016
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Tue, 11 Oct 2016 00:19:29 +0900
Subject: RFR JDK-8166890: JShell: locks forever when input is piped
In-Reply-To: <57FBA367.6040608@oracle.com>
References: <57FB6BAC.5020200@oracle.com>
	<CAHjBcHPpn2Wz986DNPoY+9Nb9pD_g8yX27UxrfWKRW7Oj45D_Q@mail.gmail.com>
	<57FBA367.6040608@oracle.com>
Message-ID: <CAHjBcHMy4Q01W8p2HmDxML_zGK4321xcYoYbnpim4MVgbWJqcg@mail.gmail.com>

Hi Jan,
Thank you for your reply!

I see. I've added noreg-hard label.
Looks good to me!

Regards,
shinyafox(Shinya Yoshida)


2016-10-10 23:19 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com>:

> HI Shinya,
>
> Thanks for the comments!
>
> On 10.10.2016 15:20, ShinyaYoshida wrote:
>
>> Hi Jan,
>>
>> Thank you for fixing this!
>> Your patch works well on my environment!
>> Couldn't we write a test case for this?
>>
>
> I was thinking of that, but wasn't sure how to test this.
>
>
>> Trivial:
>>    synchronized (StopDetectingInputStream.this) {
>> -     state = StopDetectingInputStream.State.CLOSED;
>> +     shutdown();
>>    }
>>
>> Is this synchronized block still necessary?
>> Could it be removed because shutdown() is a synchronized method?
>>
>
> Oops, right - I mean to remove it, but forgot. Thanks noticing. Updated
> webrev:
> http://cr.openjdk.java.net/~jlahoda/8166890/langtools.01/
>
> Jan
>
>
>> Regards,
>> shinyafox(Shinya Yoshida)
>>
>> 2016-10-10 19:21 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com
>> <mailto:jan.lahoda at oracle.com>>:
>>
>>     Hi,
>>
>>     When an input is redirected to jshell, like:
>>     echo "1" | jshell
>>
>>     Then jshell locks, as it waits for the terminal to report the cursor
>>     position. Also, when the input is fully read, the
>>     StopDetectingInputStream is set to the CLOSED state, but the state
>>     may be cleared using setState, causing the readers from the
>>     StopDetectingInputStream to wait indefinitely.
>>
>>     Bug:
>>     https://bugs.openjdk.java.net/browse/JDK-8166890
>>     <https://bugs.openjdk.java.net/browse/JDK-8166890>
>>
>>     Webrevs:
>>     jdk:
>>     http://cr.openjdk.java.net/~jlahoda/8166890/jdk.00/
>>     <http://cr.openjdk.java.net/~jlahoda/8166890/jdk.00/>
>>     langtools:
>>     http://cr.openjdk.java.net/~jlahoda/8166890/langtools.00/
>>     <http://cr.openjdk.java.net/~jlahoda/8166890/langtools.00/>
>>
>>     Any feedback is welcome.
>>
>>     Thanks,
>>         Jan
>>
>>
>>

From bitterfoxc at gmail.com  Mon Oct 10 15:30:19 2016
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Tue, 11 Oct 2016 00:30:19 +0900
Subject: RFR 8167343: JShell: Completeness analysis infers an incomplete
	declaration as COMPLETE_WITH_SEMI, which is a first line of Allman style
In-Reply-To: <57F7E467.3060002@oracle.com>
References: <CAHjBcHNFwr9z2fYUXdh+Kort64PST5YUeAz=TDm-oZo08gPqng@mail.gmail.com>
	<57F7E467.3060002@oracle.com>
Message-ID: <CAHjBcHOANTLuUatyXPvjCBf9XWd2YX0ACRpCi9hdSE7L+JApLA@mail.gmail.com>

Hi Robert,
Thank you!
I've pushed.
http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2254cb8b3247

Regards,
shinyafox(Shinya Yoshida)

2016-10-08 3:07 GMT+09:00 Robert Field <robert.field at oracle.com>:

>
> On 10/07/16 08:45, ShinyaYoshida wrote:
>
>> Hi all,
>> Could you review this?
>>
>> webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8167343/webrev.00/
>> bugs: https://bugs.openjdk.java.net/browse/JDK-8167343
>>
>> Regards,
>> shinyafox(Shinya Yoshida)
>>
>
> This looks good.
>
> We need to keep in mind that the completion analysis is only a guess, and
> cannot always be correct -- we need to be careful not to infinitely chase
> perfection.
> This case though is an important one -- good catch.
>
> I have only very minor nits which you can choose to address, or not,
> without need for re-review:
>
> 169: The name is rather hard to read when used and doesn't match the
> tokens, at this level it is BRACES not LBRACE -- maybe XBRACESNEEDED
>
> 651-653:  Purely personal style.  Could be written:   expectBrace |=
> token.kind.expectBrace();
>
> 678: The style in this file would generally have the '?' and the ':' on
> their own lines.
>
> Thumbs up to push!
>
> Thanks,
> Robert
>
>

From jan.lahoda at oracle.com  Mon Oct 10 15:43:06 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 10 Oct 2016 17:43:06 +0200
Subject: RFR 8167128: jshell tool: /drop of statement gives confusing
	output
In-Reply-To: <57F7D92C.4040102@oracle.com>
References: <57F7D92C.4040102@oracle.com>
Message-ID: <57FBB70A.4010707@oracle.com>

Makes sense to me, seem fine.

Jan

On 7.10.2016 19:19, Robert Field wrote:
> Using /drop on anything other than a declaration in the jshell tool
> gives an error (and a confusing one at that).
> For example, dropping a statement or variable value query causes an error.
> The underlying cause is that drop() in the API only has semantic impact
> when declarations are changed and so was restricted to declarations.
> If does however also change the status and the tool uses the status, for
> example to determine which snippets are saved or, by default, listed.
> There is no advantage to this restriction and it reduces symmetry. This
> change allows drop (at all levels) for all kinds of snippets.
>
> Bug:
>      https://bugs.openjdk.java.net/browse/JDK-8167128
>
> Webrev:
>      http://cr.openjdk.java.net/~rfield/8167128v0.webrev/
>
> API:
>      http://cr.openjdk.java.net/~rfield/8167128v0.API/
>
> The API changes are minor and include:
> http://cr.openjdk.java.net/~rfield/8167128v0.API/jdk/jshell/JShell.html#drop-jdk.jshell.Snippet-
>
> http://cr.openjdk.java.net/~rfield/8167128v0.API/jdk/jshell/PersistentSnippet.html
>
> http://cr.openjdk.java.net/~rfield/8167128v0.API/jdk/jshell/Snippet.Status.html
>
>
> Thanks,
> Robert
>

From bitterfoxc at gmail.com  Mon Oct 10 15:47:51 2016
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Tue, 11 Oct 2016 00:47:51 +0900
Subject: using jshell in executable UNIX scripts
In-Reply-To: <80a6b79b-296b-3251-e027-3a1483f8e5b4@gmail.com>
References: <80a6b79b-296b-3251-e027-3a1483f8e5b4@gmail.com>
Message-ID: <CAHjBcHOQPMh+Yq6axe_8g1shzS6B1LsY_0n+qQoR66pKgwf0LA@mail.gmail.com>

Hi Peter,
Thank you for your nice feedback!
I also think it is cool if it's supported. I've got a similar feedback from
Japanese community when I've talked about jshell.

I've filed it:
https://bugs.openjdk.java.net/browse/JDK-8167440

Regards,
shinyafox(Shinya Yoshida)

2016-10-10 22:55 GMT+09:00 Peter Levart <peter.levart at gmail.com>:

> Hi,
>
>
> "jshell" command is a very nice interactive Java shell, but it could also
> be used for scripting. An executable script in any major UNIX OS is a
> textual file with executable permissions that starts with the following two
> characters: #!
> The rest of the 1st line is the path to the interpreter executable and any
> arguments passed to it. The last argument passed to the interpreter is the
> path to the executable script. In case of jshell, one would want such
> script to be written like:
>
> #!/home/peter/Apps64/jdk9/bin/jshell
>
> System.out.println("Hello World!");
>
> /exit
>
>
> The problem is that jshell tries to parse the 1st line using jshell syntax
> and the result of running above executable script is:
>
> | Error:
> |  illegal character: '#'
> | #!/home/peter/Apps64/jdk9/bin/jshell
> |  ^
> |  Error:
> |  illegal start of expression
> |  #!/home/peter/Apps64/jdk9/bin/jshell
> |    ^
> Hello World!
>
>
> The script is actually executed, but the syntax error encountered in the
> 1st line is printed too.
>
> Would it be possible for jshell to skip 1st line if it starts with
> characters #! like other shells do?
>
>
> Regards, Peter
>
>

From robert.field at oracle.com  Mon Oct 10 20:22:43 2016
From: robert.field at oracle.com (Robert Field)
Date: Mon, 10 Oct 2016 13:22:43 -0700
Subject: JShell tool: remove or keep default Edit Pad editor?
Message-ID: <57FBF893.4040607@oracle.com>

Within the jshell tool, you can type:

     /edit foo

or

     /edit

To edit a specific snippet or all active snippets.

If no external editor is specified in the jshell tool with:

     /set editor myfavoriteeditor

then a built-in default editor "Edit Pad" is used.

There are several reasons Edit Pad is there:

* So that the jshell tool works out-of-the-box.  Particularly for 
newbies it is important that they can use jshell without configuring it.

* So that jshell can be platform-neutral.  There is no editor that would 
work on every platform -- or even any configuration of a platform.  This 
is an issue for documentation.

* Because of interaction issues, including potentially needed flags, 
set-up of an external editor can be error prone.  The external editor 
launch may need options set.  If the editor returns immediately 
(sometimes or always) the jshell editor setting -wait should be used.

* For newbies where the barrier to entry should be low, the challenges 
of learning an editor can be an issue.  The Edit Pad is as simple as 
possible.

There are however also many drawbacks to having the built-in editor:

* It is a module anomaly to reference Desktop from core JDK tools.

* Part of the definition of the jshell tool is that it is a command line 
tool.  The Edit Pad is not command-line.

* The Edit Pad functionality is a slippery-slope.  There have already 
been requests for additional functionality -- on several fronts: 
interaction with jshell, more general editing functionality, and more 
Java-specific functionality.

* The existence of a separate window in the jshell tool is a 
slippery-slope.  There have already been requests for windows for I/O 
(both for clarity of separating commands from output and to address 
issues of interaction between command input and program input) and 
requests for windows with active variable values, etc.

* The core JDK tools team does not have UI design as a core competency,

We would very much like your input on this issue.  A (motivated) 
thumbs-up/down are interesting.  Alternative suggestions on addressing 
this are very interesting.

Thanks,
Robert et. al.



From paul.sandoz at oracle.com  Tue Oct 11 00:31:35 2016
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 10 Oct 2016 17:31:35 -0700
Subject: JShell tool: remove or keep default Edit Pad editor?
In-Reply-To: <57FBF893.4040607@oracle.com>
References: <57FBF893.4040607@oracle.com>
Message-ID: <CF81D97E-28F6-4E95-82FB-498570A1E9D0@oracle.com>

Hi Robert,

IMO i think you should drop it, for many of the reasons you have stated. I suspect we may come to regret this dependency later on.

One approach for an out of the box solution is to split out the editor functionality into a separate module and for jshell to define a service provider interface. Thereby on a full JDK distribution you can the same functionality but on a more minimal distribution it is not present. A lesser solution is to provide the service provider interface and an example implementation that is not distributed, thereby teaching institutions could still use that.

However, there is still the slippery-slope argument, where developers may come to expect a live editing window with completion and JavaDoc display etc etc. This is where IDEs can better excel with good integration with jshell, so i think we should encourage that use-case.

Paul.

> On 10 Oct 2016, at 13:22, Robert Field <robert.field at oracle.com> wrote:
> 
> Within the jshell tool, you can type:
> 
>    /edit foo
> 
> or
> 
>    /edit
> 
> To edit a specific snippet or all active snippets.
> 
> If no external editor is specified in the jshell tool with:
> 
>    /set editor myfavoriteeditor
> 
> then a built-in default editor "Edit Pad" is used.
> 
> There are several reasons Edit Pad is there:
> 
> * So that the jshell tool works out-of-the-box.  Particularly for newbies it is important that they can use jshell without configuring it.
> 
> * So that jshell can be platform-neutral.  There is no editor that would work on every platform -- or even any configuration of a platform.  This is an issue for documentation.
> 
> * Because of interaction issues, including potentially needed flags, set-up of an external editor can be error prone.  The external editor launch may need options set.  If the editor returns immediately (sometimes or always) the jshell editor setting -wait should be used.
> 
> * For newbies where the barrier to entry should be low, the challenges of learning an editor can be an issue.  The Edit Pad is as simple as possible.
> 
> There are however also many drawbacks to having the built-in editor:
> 
> * It is a module anomaly to reference Desktop from core JDK tools.
> 
> * Part of the definition of the jshell tool is that it is a command line tool.  The Edit Pad is not command-line.
> 
> * The Edit Pad functionality is a slippery-slope.  There have already been requests for additional functionality -- on several fronts: interaction with jshell, more general editing functionality, and more Java-specific functionality.
> 
> * The existence of a separate window in the jshell tool is a slippery-slope.  There have already been requests for windows for I/O (both for clarity of separating commands from output and to address issues of interaction between command input and program input) and requests for windows with active variable values, etc.
> 
> * The core JDK tools team does not have UI design as a core competency,
> 
> We would very much like your input on this issue.  A (motivated) thumbs-up/down are interesting.  Alternative suggestions on addressing this are very interesting.
> 
> Thanks,
> Robert et. al.
> 
> 


From paul.sandoz at oracle.com  Tue Oct 11 19:26:55 2016
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 11 Oct 2016 12:26:55 -0700
Subject: using jshell in executable UNIX scripts
In-Reply-To: <a8f765ed-6968-473a-a6d7-fa4ae0305139@gmail.com>
References: <a8f765ed-6968-473a-a6d7-fa4ae0305139@gmail.com>
Message-ID: <C1386533-A254-4698-BB14-E3A1593454AE@oracle.com>

Hi Peter,

I was wondering when this would be discussed :-)

This potentially starts moving down the slippery slope of what it means to be Java syntax and what it means to execute. Larger topics to be thought about.

Here is some interesting discussion about Go:

  http://golangcookbook.com/chapters/running/shebang/

Surprisingly you can make it work in bash (from the above link):

  //$JDK_HOME/bin/jshell $0 $@; exit $?
  System.out.println("HELLO");

  /exit

Paul.

> On 10 Oct 2016, at 04:03, Peter Levart <peter.levart at gmail.com> wrote:
> 
> Hi,
> 
> I don't know if this is the right list to discuss this, so please direct me to a more suitable place if there is one.
> 
> "jshell" command is a very nice interactive Java shell, but it could also be used for scripting. An executable script in any major UNIX OS is a textual file with executable permissions that starts with the following two characters: #!
> The rest of the 1st line is the path to the interpreter executable and any arguments passed to it. The last argument passed to the interpreter is the path to the executable script. In case of jshell, one would want such script to be written like:
> 
> #!/home/peter/Apps64/jdk9/bin/jshell
> 
> System.out.println("Hello World!");
> 
> /exit
> 
> 
> The problem is that jshell tries to parse the 1st line using jshell syntax and the result of running above executable script is:
> 
> | Error:
> |  illegal character: '#'
> | #!/home/peter/Apps64/jdk9/bin/jshell
> |  ^
> |  Error:
> |  illegal start of expression
> |  #!/home/peter/Apps64/jdk9/bin/jshell
> |    ^
> Hello World!
> 
> 
> The script is actually executed, but the syntax error encountered in the 1st line is printed too.
> 
> Would it be possible for jshell to skip 1st line if it starts with characters #! like other shells do?
> 
> 
> Regards, Peter
> 


From brian.goetz at oracle.com  Tue Oct 11 19:52:10 2016
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 11 Oct 2016 15:52:10 -0400
Subject: using jshell in executable UNIX scripts
In-Reply-To: <80a6b79b-296b-3251-e027-3a1483f8e5b4@gmail.com>
References: <80a6b79b-296b-3251-e027-3a1483f8e5b4@gmail.com>
Message-ID: <f0bad509-7acb-315a-dad0-1cdd964eb486@oracle.com>

I understand why you'd like to coopt jshell into this -- after all, it 
is convenient and it seems "so close" -- but this is trying to turn 
jshell into something it wasn't designed for.  But this wasn't an 
oversight; we deliberately chose to leave this *outside* of the jshell 
requirements, because it feels like an entirely different feature.

More generally, "hacks" like this always come back to bite you. What you 
want is a "no main, no compile java runner".  Jshell looks like that, 
but it isn't.  When you have nothing, a little of something seems like a 
really good idea; but the warts will become apparent almost 
immediately.  I'd much rather do nothing for this now, and consider 
doing something better in the future, than doing something bad now -- 
which is what this would be.


On 10/10/2016 9:55 AM, Peter Levart wrote:
> Hi,
>
> "jshell" command is a very nice interactive Java shell, but it could 
> also be used for scripting. An executable script in any major UNIX OS 
> is a textual file with executable permissions that starts with the 
> following two characters: #!
> The rest of the 1st line is the path to the interpreter executable and 
> any arguments passed to it. The last argument passed to the 
> interpreter is the path to the executable script. In case of jshell, 
> one would want such script to be written like:
>
> #!/home/peter/Apps64/jdk9/bin/jshell
>
> System.out.println("Hello World!");
>
> /exit
>
>
> The problem is that jshell tries to parse the 1st line using jshell 
> syntax and the result of running above executable script is:
>
> | Error:
> |  illegal character: '#'
> | #!/home/peter/Apps64/jdk9/bin/jshell
> |  ^
> |  Error:
> |  illegal start of expression
> |  #!/home/peter/Apps64/jdk9/bin/jshell
> |    ^
> Hello World!
>
>
> The script is actually executed, but the syntax error encountered in 
> the 1st line is printed too.
>
> Would it be possible for jshell to skip 1st line if it starts with 
> characters #! like other shells do?
>
>
> Regards, Peter
>


From robert.field at oracle.com  Tue Oct 11 20:09:47 2016
From: robert.field at oracle.com (Robert Field)
Date: Tue, 11 Oct 2016 13:09:47 -0700
Subject: JShell: showing and retaining settings
Message-ID: <57FD470B.9070100@oracle.com>

In response to a review request for

     8163840: jshell tool: provide way to display configuration settings

I had an in-depth discussion with Brian about the settings related 
commands -- resulting in a proposed syntax significantly different than 
current or the webrev.  I'd like to vet this at the design level before 
implementing it (again).  Your feedback is requested.

/set as before.

Showing settings with '/set' without specifying a setting (rather than 
'/set -show' in the RFR)..  This is consistent with many other shells, 
including bash.  It also reduces the commands to learn.

Since /set would also show settings retained between sessions, for 
symmetry, /retain would be rolled into /set as /set -retain ...

Since mode settings are very extensive they would be shown only for 
requested modes.

Examples ---

jshell> /set
|  /set editor -retain kwrite
|  /set editor -default
|  /set start -none
|  /set feedback normal
|
| For mode settings use:  /show mode <mode>
| Current set modes: verbose normal concise silent

jshell> /set editor
|  /set editor -retain kwrite
|  /set editor -default

jshell> /set mode concise
|  /set mode concise -quiet
|  /set prompt concise "jshell> " "   ...> "
|  /set format concise typeKind "class" class
|  /set format concise typeKind "interface" interface
|  /set format concise typeKind "enum" enum
|  /set format concise typeKind "annotation interface" annotation
|  /set format concise pre "|  "
|  /set format concise resolve "{until}{unrerr}" 
modified,added,used,replaced
|  /set format concise err "%6$s"
|  /set format concise unrerr "{unresolved} is declared" unresolved1-error0
|  /set format concise unrerr "{unresolved} are declared" unresolved2-error0
|  /set format concise unrerr " this error is corrected: {errors}" 
unresolved0-error1
|  /set format concise unrerr "{unresolved} is declared and this error 
is corrected: {errors}" unresolved1-error1
|  /set format concise unrerr "{unresolved} are declared and this error 
is corrected: {errors}" unresolved2-error1
|  /set format concise unrerr " these errors are corrected: {errors}" 
unresolved0-error2
|  /set format concise unrerr "{unresolved} is declared and these errors 
are corrected: {errors}" unresolved1-error2
|  /set format concise unrerr "{unresolved} are declared and these 
errors are corrected: {errors}" unresolved2-error2
|  /set format concise display "{result}{pre}created scratch variable 
{name} : {type}{post}" expression-modified,added,replaced-primary
|  /set format concise display "{result}{pre}value of {name} : 
{type}{post}" varvalue-primary
|  /set format concise display "{result}{pre}assigned to {name} : 
{type}{post}" assignment-primary
|  /set format concise display "{result}{pre}{action} variable {name} : 
{type}{resolve}{post}" varinit,vardecl
|  /set format concise display "{pre}{action} variable 
{name}{resolve}{post}" varinit,vardecl-notdefined
|  /set format concise display "{pre}{action} variable {name}{post}" 
varinit,expression,vardecl-dropped
|  /set format concise display "{pre}{action} variable {name}, reset to 
null{post}" varinit,vardecl-replaced-update-ok
|  /set format concise display "{pre}{action} {typeKind} 
{name}{resolve}{post}" class,enum,annotation,interface
|  /set format concise display "{pre}{action} method 
{name}({type}){resolve}{post}" method
|  /set format concise display "{pre}attempted to use {typeKind} 
{name}{resolve}{post}" class,enum,annotation,interface-used
|  /set format concise display "{pre}attempted to call method 
{name}({type}){resolve}{post}" method-used
|  /set format concise display "" 
modified,added,dropped,overwrote,replaced-update
|  /set format concise display "{pre}{action} variable {name}, reset to 
null{post}" varinit,vardecl-replaced-update-ok
|  /set format concise display "{result}" 
varinit,expression,assignment,varvalue,vardecl-modified,added,replaced-primary-ok
|  /set format concise display "" 
class,enum,varinit,annotation,assignment,method,vardecl,interface-ok
|  /set format concise type "%2$s"
|  /set format concise errorpre "|  "
|  /set format concise result "{name} ==> {value}{post}" 
modified,added,replaced-primary-ok
|  /set format concise unresolved "%4$s"
|  /set format concise errorline "{post}{pre}    {err}"
|  /set format concise post "%n"
|  /set format concise name "%1$s"
|  /set format concise action "created" added-primary
|  /set format concise action "modified" modified-primary
|  /set format concise action "replaced" replaced-primary
|  /set format concise action "overwrote" overwrote-primary
|  /set format concise action "dropped" dropped-primary
|  /set format concise action "  update created" added-update
|  /set format concise action "  update modified" modified-update
|  /set format concise action "  update replaced" replaced-update
|  /set format concise action "  update overwrote" overwrote-update
|  /set format concise action "  update dropped" dropped-update
|  /set format concise errorpost "%n"
|  /set format concise until ", however, it cannot be instanciated or 
its methods invoked until" class-primary-defined
|  /set format concise until ", however, its methods cannot be invoked 
until" interface-primary-defined
|  /set format concise until ", however, it cannot be used until" 
enum,annotation-primary-defined
|  /set format concise until ", however, it cannot be invoked until" 
method-primary-defined
|  /set format concise until ", however, it cannot be referenced until" 
primary-notdefined
|  /set format concise until " which cannot be instanciated or its 
methods invoked until" class-update-defined
|  /set format concise until " whose methods cannot be invoked until" 
interface-update-defined
|  /set format concise until " which cannot be invoked until" 
method-update-defined
|  /set format concise until " which cannot be referenced until" 
update-notdefined
|  /set format concise value "%3$s"
|  /set format concise errors "%5$s"
|  /set truncation concise 80
|  /set truncation concise 1000 expression,varvalue

jshell> /set start -retain -default


Thoughts?



From cay at horstmann.com  Tue Oct 11 20:11:28 2016
From: cay at horstmann.com (Cay Horstmann)
Date: Tue, 11 Oct 2016 13:11:28 -0700
Subject: using jshell in executable UNIX scripts
In-Reply-To: <f0bad509-7acb-315a-dad0-1cdd964eb486@oracle.com>
References: <80a6b79b-296b-3251-e027-3a1483f8e5b4@gmail.com>
	<f0bad509-7acb-315a-dad0-1cdd964eb486@oracle.com>
Message-ID: <9787e1d6-5c23-eeaf-f3d5-a5dc5d5da509@horstmann.com>

You may know that the Scala REPL and Nashorn let you use a shebang in 
the first line. (Nashorn doesn't do it very well: command line arguments 
must be preceded by -- because jjs can take multiple scripts.)

I have used the feature for Scala quite a few times. But it's a very 
minor convenience. Everytime the script turned into anything of any 
value, I wanted it compiled, and then I had to add the Scala equivalent 
of "public static void main" anyway.

If I want to do the same in Java, the // trick is good enough.

Cheers,

Cay

Le 10/11/2016 ? 12:52 PM, Brian Goetz a ?crit :
> I understand why you'd like to coopt jshell into this -- after all, it
> is convenient and it seems "so close" -- but this is trying to turn
> jshell into something it wasn't designed for.  But this wasn't an
> oversight; we deliberately chose to leave this *outside* of the jshell
> requirements, because it feels like an entirely different feature.
>
> More generally, "hacks" like this always come back to bite you. What you
> want is a "no main, no compile java runner".  Jshell looks like that,
> but it isn't.  When you have nothing, a little of something seems like a
> really good idea; but the warts will become apparent almost
> immediately.  I'd much rather do nothing for this now, and consider
> doing something better in the future, than doing something bad now --
> which is what this would be.
>
>
> On 10/10/2016 9:55 AM, Peter Levart wrote:
>> Hi,
>>
>> "jshell" command is a very nice interactive Java shell, but it could
>> also be used for scripting. An executable script in any major UNIX OS
>> is a textual file with executable permissions that starts with the
>> following two characters: #!
>> The rest of the 1st line is the path to the interpreter executable and
>> any arguments passed to it. The last argument passed to the
>> interpreter is the path to the executable script. In case of jshell,
>> one would want such script to be written like:
>>
>> #!/home/peter/Apps64/jdk9/bin/jshell
>>
>> System.out.println("Hello World!");
>>
>> /exit
>>
>>
>> The problem is that jshell tries to parse the 1st line using jshell
>> syntax and the result of running above executable script is:
>>
>> | Error:
>> |  illegal character: '#'
>> | #!/home/peter/Apps64/jdk9/bin/jshell
>> |  ^
>> |  Error:
>> |  illegal start of expression
>> |  #!/home/peter/Apps64/jdk9/bin/jshell
>> |    ^
>> Hello World!
>>
>>
>> The script is actually executed, but the syntax error encountered in
>> the 1st line is printed too.
>>
>> Would it be possible for jshell to skip 1st line if it starts with
>> characters #! like other shells do?
>>
>>
>> Regards, Peter
>>
>


-- 

Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com

From mark.reinhold at oracle.com  Tue Oct 11 23:09:19 2016
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 11 Oct 2016 16:09:19 -0700
Subject: JShell tool: remove or keep default Edit Pad editor?
In-Reply-To: <CF81D97E-28F6-4E95-82FB-498570A1E9D0@oracle.com>
References: <57FBF893.4040607@oracle.com>
	<CF81D97E-28F6-4E95-82FB-498570A1E9D0@oracle.com>
Message-ID: <20161011160919.399889281eggemoggin.niobe.net>

2016/10/10 17:31:35 -0700, paul.sandoz at oracle.com:
> IMO i think you should drop it, for many of the reasons you have
> stated. I suspect we may come to regret this dependency later on.

I agree.

    $ ls -l java.desktop.jmod jdk.jshell.jmod
    -rw-r--r-- 1 mr green  12M 2016-10-09 03:55 java.desktop.jmod
    -rw-r--r-- 1 mr green 387K 2016-10-09 03:55 jdk.jshell.jmod
    $ 

It sure would be nice to be able to link a custom image that contains
jdk.jshell without dragging in all of java.desktop, as it does now.

> One approach for an out of the box solution is to split out the editor
> functionality into a separate module and for jshell to define a
> service provider interface. Thereby on a full JDK distribution you can
> the same functionality but on a more minimal distribution it is not
> present.

That would be the "modular" way to do it.

Have you considered, at least on Unix systems, supporting the EDITOR
environment variable?  Yes, it might be platform-specific, but it's an
incredibly handy and reasonably standard way to tell random programs how
to use the editor of your choice.

- Mark

From robert.field at oracle.com  Wed Oct 12 00:51:41 2016
From: robert.field at oracle.com (Robert Field)
Date: Tue, 11 Oct 2016 17:51:41 -0700
Subject: JShell tool: remove or keep default Edit Pad editor?
In-Reply-To: <20161011160919.399889281eggemoggin.niobe.net>
References: <57FBF893.4040607@oracle.com>
	<CF81D97E-28F6-4E95-82FB-498570A1E9D0@oracle.com>
	<20161011160919.399889281eggemoggin.niobe.net>
Message-ID: <57FD891D.2040806@oracle.com>


On 10/11/16 16:09, mark.reinhold at oracle.com wrote:
> 2016/10/10 17:31:35 -0700, paul.sandoz at oracle.com:
>> IMO i think you should drop it, for many of the reasons you have
>> stated. I suspect we may come to regret this dependency later on.
> I agree.
>
>      $ ls -l java.desktop.jmod jdk.jshell.jmod
>      -rw-r--r-- 1 mr green  12M 2016-10-09 03:55 java.desktop.jmod
>      -rw-r--r-- 1 mr green 387K 2016-10-09 03:55 jdk.jshell.jmod
>      $
>
> It sure would be nice to be able to link a custom image that contains
> jdk.jshell without dragging in all of java.desktop, as it does now.
>
>> One approach for an out of the box solution is to split out the editor
>> functionality into a separate module and for jshell to define a
>> service provider interface. Thereby on a full JDK distribution you can
>> the same functionality but on a more minimal distribution it is not
>> present.
> That would be the "modular" way to do it.

That would certainly be doable.  If the critical concern is module 
boundaries.  But that exposes the Edit Pad to use outside of jshell -- 
is that an issue?

The Edit Pad doesn't have any particularly interesting differences from 
the use of any external editor -- except that we know it exists.  Any 
mechanism by which we could know where an editor was would work.

>
> Have you considered, at least on Unix systems, supporting the EDITOR
> environment variable?  Yes, it might be platform-specific, but it's an
> incredibly handy and reasonably standard way to tell random programs how
> to use the editor of your choice.

Was tempted.  The jshell tool suspends the REPL while in the editor (so 
they don't clash).  However some editors return immediately -- there is 
a -wait option on /set editor for this case.  But of course, coming from 
EDITOR there is no way to know if it needed. Between that, the platform 
specific aspect, and how it would interact with /set and Preferences -- 
it seemed a bit convoluted and shaky.  Still an option but it doesn't 
solve the problem -- just another finger in the dike.

>
> - Mark

Thanks,
Robert


From sundararajan.athijegannathan at oracle.com  Wed Oct 12 02:29:50 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 12 Oct 2016 07:59:50 +0530
Subject: using jshell in executable UNIX scripts
In-Reply-To: <f0bad509-7acb-315a-dad0-1cdd964eb486@oracle.com>
References: <80a6b79b-296b-3251-e027-3a1483f8e5b4@gmail.com>
	<f0bad509-7acb-315a-dad0-1cdd964eb486@oracle.com>
Message-ID: <22bc55df-b94c-748c-e226-9be33e4f7902@oracle.com>

There is another shell in jdk (since jdk8) called "jjs". jjs supports
shebang scripts,  backquote exec,  heredocs, calls to Java code etc:

https://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn/shell.html

-Sundar

On 10/12/2016 1:22 AM, Brian Goetz wrote:
> I understand why you'd like to coopt jshell into this -- after all, it
> is convenient and it seems "so close" -- but this is trying to turn
> jshell into something it wasn't designed for.  But this wasn't an
> oversight; we deliberately chose to leave this *outside* of the jshell
> requirements, because it feels like an entirely different feature.
>
> More generally, "hacks" like this always come back to bite you. What
> you want is a "no main, no compile java runner".  Jshell looks like
> that, but it isn't.  When you have nothing, a little of something
> seems like a really good idea; but the warts will become apparent
> almost immediately.  I'd much rather do nothing for this now, and
> consider doing something better in the future, than doing something
> bad now -- which is what this would be.
>
>
> On 10/10/2016 9:55 AM, Peter Levart wrote:
>> Hi,
>>
>> "jshell" command is a very nice interactive Java shell, but it could
>> also be used for scripting. An executable script in any major UNIX OS
>> is a textual file with executable permissions that starts with the
>> following two characters: #!
>> The rest of the 1st line is the path to the interpreter executable
>> and any arguments passed to it. The last argument passed to the
>> interpreter is the path to the executable script. In case of jshell,
>> one would want such script to be written like:
>>
>> #!/home/peter/Apps64/jdk9/bin/jshell
>>
>> System.out.println("Hello World!");
>>
>> /exit
>>
>>
>> The problem is that jshell tries to parse the 1st line using jshell
>> syntax and the result of running above executable script is:
>>
>> | Error:
>> |  illegal character: '#'
>> | #!/home/peter/Apps64/jdk9/bin/jshell
>> |  ^
>> |  Error:
>> |  illegal start of expression
>> |  #!/home/peter/Apps64/jdk9/bin/jshell
>> |    ^
>> Hello World!
>>
>>
>> The script is actually executed, but the syntax error encountered in
>> the 1st line is printed too.
>>
>> Would it be possible for jshell to skip 1st line if it starts with
>> characters #! like other shells do?
>>
>>
>> Regards, Peter
>>
>


From som.snytt at gmail.com  Wed Oct 12 03:25:42 2016
From: som.snytt at gmail.com (Som Snytt)
Date: Tue, 11 Oct 2016 20:25:42 -0700
Subject: JShell tool: remove or keep default Edit Pad editor?
In-Reply-To: <57FD891D.2040806@oracle.com>
References: <57FBF893.4040607@oracle.com>
	<CF81D97E-28F6-4E95-82FB-498570A1E9D0@oracle.com>
	<57FD891D.2040806@oracle.com>
Message-ID: <CAPaMnL6JZLCJ1xLORWfv83Bhu-NWv000Wep1ayvwZtVEixXHyw@mail.gmail.com>

Scala REPL uses EDITOR, but I'm going to try a plug-in approach. But it has
to be easy to fetch the plug-in.

The alternative Ammonite REPL makes downloading dependencies easy. The
Scala REPL receives black marks for being an awkward download for newbies,
with no story for dependencies unless run under the sbt build tool (as `sbt
console`), which is also awkward. Some users prefer the worksheet available
in the IDEs in any case.

The other possible integration point for Scala is the Ensime project, which
lets emacs/vi/et al talk to a resident compiler and benefit from
autocomplete and so on.

Ammonite avoids baked-in features, especially half-baked. I'm hoping for
editing support for Scala REPL as a separate module; the Scala project has
been farming out bits to semi-autonomous projects, as a way to reduce
download size and maintenance burden, including the cost of maintaining
suboptimal code.

Scala REPL is also the basis for Spark shell, which has special needs for
how snippets are translated to compilable units; that's another example of
a feature that would have benefited from pluggability.

HTH. I've been impressed how jshell issues sound familiar from the Scala
experience. Except the naming problem. The Scala REPL never had an
interesting name.


On Tue, Oct 11, 2016 at 5:51 PM, Robert Field <robert.field at oracle.com>
wrote:

>
> On 10/11/16 16:09, mark.reinhold at oracle.com wrote:
>
>> 2016/10/10 17:31:35 -0700, paul.sandoz at oracle.com:
>>
>>> IMO i think you should drop it, for many of the reasons you have
>>> stated. I suspect we may come to regret this dependency later on.
>>>
>> I agree.
>>
>>      $ ls -l java.desktop.jmod jdk.jshell.jmod
>>      -rw-r--r-- 1 mr green  12M 2016-10-09 03:55 java.desktop.jmod
>>      -rw-r--r-- 1 mr green 387K 2016-10-09 03:55 jdk.jshell.jmod
>>      $
>>
>> It sure would be nice to be able to link a custom image that contains
>> jdk.jshell without dragging in all of java.desktop, as it does now.
>>
>> One approach for an out of the box solution is to split out the editor
>>> functionality into a separate module and for jshell to define a
>>> service provider interface. Thereby on a full JDK distribution you can
>>> the same functionality but on a more minimal distribution it is not
>>> present.
>>>
>> That would be the "modular" way to do it.
>>
>
> That would certainly be doable.  If the critical concern is module
> boundaries.  But that exposes the Edit Pad to use outside of jshell -- is
> that an issue?
>
> The Edit Pad doesn't have any particularly interesting differences from
> the use of any external editor -- except that we know it exists.  Any
> mechanism by which we could know where an editor was would work.
>
>
>> Have you considered, at least on Unix systems, supporting the EDITOR
>> environment variable?  Yes, it might be platform-specific, but it's an
>> incredibly handy and reasonably standard way to tell random programs how
>> to use the editor of your choice.
>>
>
> Was tempted.  The jshell tool suspends the REPL while in the editor (so
> they don't clash).  However some editors return immediately -- there is a
> -wait option on /set editor for this case.  But of course, coming from
> EDITOR there is no way to know if it needed. Between that, the platform
> specific aspect, and how it would interact with /set and Preferences -- it
> seemed a bit convoluted and shaky.  Still an option but it doesn't solve
> the problem -- just another finger in the dike.
>
>
>> - Mark
>>
>
> Thanks,
> Robert
>
>

From som.snytt at gmail.com  Wed Oct 12 04:44:43 2016
From: som.snytt at gmail.com (Som Snytt)
Date: Tue, 11 Oct 2016 21:44:43 -0700
Subject: JShell: showing and retaining settings
In-Reply-To: <57FD470B.9070100@oracle.com>
References: <57FD470B.9070100@oracle.com>
Message-ID: <CAPaMnL6qAPDtVW5FLQ2XaR_YAUEcS8Pkkqyr8p6pFPYx0V1Kgw@mail.gmail.com>

FWIW, Scala REPL works that way.

scala> :se
-d = .
-deprecation = true
-encoding = UTF-8
-feature = true
-nowarn = false

scala> :se -Ywarn-unused

scala> :se
-Ywarn-unused = true
-d = .
-deprecation = true
-encoding = UTF-8
-feature = true
-nowarn = false

scala> { val x, y = 42 ; x + 17 }
<console>:12: warning: local val in value res0 is never used
       { val x, y = 42 ; x + 17 }
                ^
res0: Int = 59

scala> :replay -nowarn
Replaying: { val x, y = 42 ; x + 17 }
res0: Int = 59

The settings, reset and replay commands just take compiler settings to use.
I can remember that.

There are legacy settings on the $intp interpreter, which I can't
rediscover without autocompletion.

scala> $intp.isettings.
allSettings   deprecation_=            maxPrintString   unwrapStrings
deprecation   maxAutoprintCompletion   toString

scala> $intp.isettings.maxPrintString = 20
$intp.isettings.m...

I stopped using switches with commands, as a complication. Help and usage
becomes cumbersome. In this case, what's wrong with "/retain" also showing
settings, for symmetry? "/set -retain" is more to type. Also, "/set" and
"/ret" pair nicely.



On Tue, Oct 11, 2016 at 1:09 PM, Robert Field <robert.field at oracle.com>
wrote:

> In response to a review request for
>
>     8163840: jshell tool: provide way to display configuration settings
>
> I had an in-depth discussion with Brian about the settings related
> commands -- resulting in a proposed syntax significantly different than
> current or the webrev.  I'd like to vet this at the design level before
> implementing it (again).  Your feedback is requested.
>
> /set as before.
>
> Showing settings with '/set' without specifying a setting (rather than
> '/set -show' in the RFR)..  This is consistent with many other shells,
> including bash.  It also reduces the commands to learn.
>
> Since /set would also show settings retained between sessions, for
> symmetry, /retain would be rolled into /set as /set -retain ...
>
> Since mode settings are very extensive they would be shown only for
> requested modes.
>
> Examples ---
>
> jshell> /set
> |  /set editor -retain kwrite
> |  /set editor -default
> |  /set start -none
> |  /set feedback normal
> |
> | For mode settings use:  /show mode <mode>
> | Current set modes: verbose normal concise silent
>
> jshell> /set editor
> |  /set editor -retain kwrite
> |  /set editor -default
>
> jshell> /set mode concise
> |  /set mode concise -quiet
> |  /set prompt concise "jshell> " "   ...> "
> |  /set format concise typeKind "class" class
> |  /set format concise typeKind "interface" interface
> |  /set format concise typeKind "enum" enum
> |  /set format concise typeKind "annotation interface" annotation
> |  /set format concise pre "|  "
> |  /set format concise resolve "{until}{unrerr}"
> modified,added,used,replaced
> |  /set format concise err "%6$s"
> |  /set format concise unrerr "{unresolved} is declared" unresolved1-error0
> |  /set format concise unrerr "{unresolved} are declared"
> unresolved2-error0
> |  /set format concise unrerr " this error is corrected: {errors}"
> unresolved0-error1
> |  /set format concise unrerr "{unresolved} is declared and this error is
> corrected: {errors}" unresolved1-error1
> |  /set format concise unrerr "{unresolved} are declared and this error is
> corrected: {errors}" unresolved2-error1
> |  /set format concise unrerr " these errors are corrected: {errors}"
> unresolved0-error2
> |  /set format concise unrerr "{unresolved} is declared and these errors
> are corrected: {errors}" unresolved1-error2
> |  /set format concise unrerr "{unresolved} are declared and these errors
> are corrected: {errors}" unresolved2-error2
> |  /set format concise display "{result}{pre}created scratch variable
> {name} : {type}{post}" expression-modified,added,replaced-primary
> |  /set format concise display "{result}{pre}value of {name} :
> {type}{post}" varvalue-primary
> |  /set format concise display "{result}{pre}assigned to {name} :
> {type}{post}" assignment-primary
> |  /set format concise display "{result}{pre}{action} variable {name} :
> {type}{resolve}{post}" varinit,vardecl
> |  /set format concise display "{pre}{action} variable
> {name}{resolve}{post}" varinit,vardecl-notdefined
> |  /set format concise display "{pre}{action} variable {name}{post}"
> varinit,expression,vardecl-dropped
> |  /set format concise display "{pre}{action} variable {name}, reset to
> null{post}" varinit,vardecl-replaced-update-ok
> |  /set format concise display "{pre}{action} {typeKind}
> {name}{resolve}{post}" class,enum,annotation,interface
> |  /set format concise display "{pre}{action} method
> {name}({type}){resolve}{post}" method
> |  /set format concise display "{pre}attempted to use {typeKind}
> {name}{resolve}{post}" class,enum,annotation,interface-used
> |  /set format concise display "{pre}attempted to call method
> {name}({type}){resolve}{post}" method-used
> |  /set format concise display "" modified,added,dropped,overwro
> te,replaced-update
> |  /set format concise display "{pre}{action} variable {name}, reset to
> null{post}" varinit,vardecl-replaced-update-ok
> |  /set format concise display "{result}" varinit,expression,assignment,
> varvalue,vardecl-modified,added,replaced-primary-ok
> |  /set format concise display "" class,enum,varinit,annotation,
> assignment,method,vardecl,interface-ok
> |  /set format concise type "%2$s"
> |  /set format concise errorpre "|  "
> |  /set format concise result "{name} ==> {value}{post}"
> modified,added,replaced-primary-ok
> |  /set format concise unresolved "%4$s"
> |  /set format concise errorline "{post}{pre}    {err}"
> |  /set format concise post "%n"
> |  /set format concise name "%1$s"
> |  /set format concise action "created" added-primary
> |  /set format concise action "modified" modified-primary
> |  /set format concise action "replaced" replaced-primary
> |  /set format concise action "overwrote" overwrote-primary
> |  /set format concise action "dropped" dropped-primary
> |  /set format concise action "  update created" added-update
> |  /set format concise action "  update modified" modified-update
> |  /set format concise action "  update replaced" replaced-update
> |  /set format concise action "  update overwrote" overwrote-update
> |  /set format concise action "  update dropped" dropped-update
> |  /set format concise errorpost "%n"
> |  /set format concise until ", however, it cannot be instanciated or its
> methods invoked until" class-primary-defined
> |  /set format concise until ", however, its methods cannot be invoked
> until" interface-primary-defined
> |  /set format concise until ", however, it cannot be used until"
> enum,annotation-primary-defined
> |  /set format concise until ", however, it cannot be invoked until"
> method-primary-defined
> |  /set format concise until ", however, it cannot be referenced until"
> primary-notdefined
> |  /set format concise until " which cannot be instanciated or its methods
> invoked until" class-update-defined
> |  /set format concise until " whose methods cannot be invoked until"
> interface-update-defined
> |  /set format concise until " which cannot be invoked until"
> method-update-defined
> |  /set format concise until " which cannot be referenced until"
> update-notdefined
> |  /set format concise value "%3$s"
> |  /set format concise errors "%5$s"
> |  /set truncation concise 80
> |  /set truncation concise 1000 expression,varvalue
>
> jshell> /set start -retain -default
>
>
> Thoughts?
>
>
>

From som.snytt at gmail.com  Wed Oct 12 05:12:41 2016
From: som.snytt at gmail.com (Som Snytt)
Date: Tue, 11 Oct 2016 22:12:41 -0700
Subject: using jshell in executable UNIX scripts
In-Reply-To: <9787e1d6-5c23-eeaf-f3d5-a5dc5d5da509@horstmann.com>
References: <80a6b79b-296b-3251-e027-3a1483f8e5b4@gmail.com>
	<f0bad509-7acb-315a-dad0-1cdd964eb486@oracle.com>
	<9787e1d6-5c23-eeaf-f3d5-a5dc5d5da509@horstmann.com>
Message-ID: <CAPaMnL5sHHs-E6M-13NaAPp+yGXT1_X4PSSz86AOTh1xugjbAA@mail.gmail.com>

The -save option does that trick. I think it's an old one.

apm at mara:~/tmp$ cat mytool.scala
#!/bin/sh
exec /home/apm/scala-2.12.0-RC1/bin/scala -nc -save "$0" "$@"
!#
Console println s"hello, ${util.Properties.userName}"
apm at mara:~/tmp$ sh -x mytool.scala
+ exec /home/apm/scala-2.12.0-RC1/bin/scala -nc -save mytool.scala
hello, apm
apm at mara:~/tmp$ ls mytool.*
mytool.jar  mytool.scala
apm at mara:~/tmp$ sh -x mytool.scala
+ exec /home/apm/scala-2.12.0-RC1/bin/scala -nc -save mytool.scala
hello, apm

The subsequent run uses the jar, unless the source is touched.

There's not a great difference between embedding a snippet for scripting
and for REPL.

Aside from actual tooling, sometimes it's easier to just edit a file than
fiddle in the REPL, especially when more than a few expressions are
involved.


On Tue, Oct 11, 2016 at 1:11 PM, Cay Horstmann <cay at horstmann.com> wrote:

> You may know that the Scala REPL and Nashorn let you use a shebang in the
> first line. (Nashorn doesn't do it very well: command line arguments must
> be preceded by -- because jjs can take multiple scripts.)
>
> I have used the feature for Scala quite a few times. But it's a very minor
> convenience. Everytime the script turned into anything of any value, I
> wanted it compiled, and then I had to add the Scala equivalent of "public
> static void main" anyway.
>
> If I want to do the same in Java, the // trick is good enough.
>
> Cheers,
>
> Cay
>
>
> Le 10/11/2016 ? 12:52 PM, Brian Goetz a ?crit :
>
>> I understand why you'd like to coopt jshell into this -- after all, it
>> is convenient and it seems "so close" -- but this is trying to turn
>> jshell into something it wasn't designed for.  But this wasn't an
>> oversight; we deliberately chose to leave this *outside* of the jshell
>> requirements, because it feels like an entirely different feature.
>>
>> More generally, "hacks" like this always come back to bite you. What you
>> want is a "no main, no compile java runner".  Jshell looks like that,
>> but it isn't.  When you have nothing, a little of something seems like a
>> really good idea; but the warts will become apparent almost
>> immediately.  I'd much rather do nothing for this now, and consider
>> doing something better in the future, than doing something bad now --
>> which is what this would be.
>>
>>
>> On 10/10/2016 9:55 AM, Peter Levart wrote:
>>
>>> Hi,
>>>
>>> "jshell" command is a very nice interactive Java shell, but it could
>>> also be used for scripting. An executable script in any major UNIX OS
>>> is a textual file with executable permissions that starts with the
>>> following two characters: #!
>>> The rest of the 1st line is the path to the interpreter executable and
>>> any arguments passed to it. The last argument passed to the
>>> interpreter is the path to the executable script. In case of jshell,
>>> one would want such script to be written like:
>>>
>>> #!/home/peter/Apps64/jdk9/bin/jshell
>>>
>>> System.out.println("Hello World!");
>>>
>>> /exit
>>>
>>>
>>> The problem is that jshell tries to parse the 1st line using jshell
>>> syntax and the result of running above executable script is:
>>>
>>> | Error:
>>> |  illegal character: '#'
>>> | #!/home/peter/Apps64/jdk9/bin/jshell
>>> |  ^
>>> |  Error:
>>> |  illegal start of expression
>>> |  #!/home/peter/Apps64/jdk9/bin/jshell
>>> |    ^
>>> Hello World!
>>>
>>>
>>> The script is actually executed, but the syntax error encountered in
>>> the 1st line is printed too.
>>>
>>> Would it be possible for jshell to skip 1st line if it starts with
>>> characters #! like other shells do?
>>>
>>>
>>> Regards, Peter
>>>
>>>
>>
>
> --
>
> Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com
>

From paul.deitel at deitel.com  Wed Oct 12 16:04:02 2016
From: paul.deitel at deitel.com (Paul Deitel)
Date: Wed, 12 Oct 2016 12:04:02 -0400
Subject: JShell tool: remove or keep default Edit Pad editor? 
In-Reply-To: <mailman.36168.1476247488.23828.kulla-dev@openjdk.java.net>
References: <mailman.36168.1476247488.23828.kulla-dev@openjdk.java.net>
Message-ID: <5A596307-1965-4B2D-AB48-F99D177D24B3@deitel.com>

While I understand the issue of bundling Edit Pad with respect to modularization, as an author of introductory computer programming texts, like Java How to Program, command line REPL is much less useful for beginners if they have to try to figure out how to edit something like a complete class definition from the command line. 

If possible, I?d recommend somehow providing access to a more robust cross-platform editor?perhaps something like jEdit (jedit.org). If not, perhaps the modularized JShell could provide an option that enables Edit Pad if someone wants to use it.

If you do keep Edit Pad, here are some changes I?d like to see to make it slightly nicer:

a. Use a fixed-width code font for readability

b. Use a bigger font size or provide controls for changing the font size--the current size is tiny and hard to read

c. Add 5-10 pixels of padding between the textbox containing the code and the window border?right now the left edge of the code is right up against the window?s border, again making the code hard to read.

d. Separate each snippet from the next by a blank line.

Thanks,
Paul

From paul.deitel at deitel.com  Wed Oct 12 16:55:49 2016
From: paul.deitel at deitel.com (Paul Deitel)
Date: Wed, 12 Oct 2016 12:55:49 -0400
Subject: JShell /-n command
In-Reply-To: <5A596307-1965-4B2D-AB48-F99D177D24B3@deitel.com>
References: <mailman.36168.1476247488.23828.kulla-dev@openjdk.java.net>
	<5A596307-1965-4B2D-AB48-F99D177D24B3@deitel.com>
Message-ID: <29EEDF78-3E33-4B31-818D-F8EDA68421B7@deitel.com>

Is the command 

	/-n 

actually useful? Chances are, if you have any decent number of snippets, you will not recall more than the last few you typed. 

You can already execute the last valid snippet with /!.

For anything else, you?d probably have to do a /list to see what valid snippets you have. At that point, rather than doing /-n, you?d just use /<id> to execute a given snippet.

One point of emphasis in many JShell presentation has been how it?s useful for beginners. I?ve been teaching beginning programmers for 25+ years. A beginner seeing options like this will only get confused. 

I recommend removing /-n as an option.

Paul

Paul J. Deitel, CEO
Deitel & Associates, Inc.
Oracle Java Champion
Microsoft Visual C# MVP 2012-2014

http://www.deitel.com
978-443-2423

Facebook: http://facebook.com/DeitelFan
Twitter: @deitel
LinkedIn: http://www.linkedin.com/company/deitel-&-associates
YouTube: http://youtube.com/DeitelTV
Instagram: http://instagram.com/DeitelFan
Google+: http://google.com/+DeitelFan

Newsletter: http://www.deitel.com/newsletter/subscribe.html

On-Site Worldwide Corporate Training: http://www.deitel.com/training/
Purchase our most recent books: http://amzn.to/18BLG2I
Resource Centers: http://www.deitel.com/ResourceCenters.html





From mark.reinhold at oracle.com  Wed Oct 12 17:12:16 2016
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 12 Oct 2016 10:12:16 -0700
Subject: JShell tool: remove or keep default Edit Pad editor?
In-Reply-To: <57FD891D.2040806@oracle.com>
References: <57FBF893.4040607@oracle.com>
	<CF81D97E-28F6-4E95-82FB-498570A1E9D0@oracle.com>
	<20161011160919.399889281eggemoggin.niobe.net>
	<57FD891D.2040806@oracle.com>
Message-ID: <20161012101216.896781462eggemoggin.niobe.net>

2016/10/11 17:51:41 -0700, robert.field at oracle.com:
> On 10/11/16 16:09, mark.reinhold at oracle.com wrote:
>> 2016/10/10 17:31:35 -0700, paul.sandoz at oracle.com:
>>> ...
>>> 
>>> One approach for an out of the box solution is to split out the editor
>>> functionality into a separate module and for jshell to define a
>>> service provider interface. Thereby on a full JDK distribution you can
>>> the same functionality but on a more minimal distribution it is not
>>> present.
>> 
>> That would be the "modular" way to do it.
> 
> That would certainly be doable.  If the critical concern is module 
> boundaries.  But that exposes the Edit Pad to use outside of jshell -- 
> is that an issue?

You can prevent undue exposure by defining the service type in the
jdk.jshell module and exporting its containing package only to the
new module that contains Edit Pad, something like this:

    module jdk.jshell {
        exports jdk.jshell.editor.spi to jdk.internal.editpad;
        ...
    }

    module jdk.internal.editpad {
        requires java.desktop;
        requires jdk.jshell;
        provides jdk.jshell.editor.spi.Editor
            with jdk.internal.editpad.EditorProvider;
    }

>> ...
>> 
>> Have you considered, at least on Unix systems, supporting the EDITOR
>> environment variable?  Yes, it might be platform-specific, but it's an
>> incredibly handy and reasonably standard way to tell random programs how
>> to use the editor of your choice.
> 
> Was tempted.  The jshell tool suspends the REPL while in the editor (so 
> they don't clash).  However some editors return immediately -- there is 
> a -wait option on /set editor for this case.

Every Unix tool I've ever seen that uses EDITOR has assumed that the
command defined by that environment variable will not return until the
editing operation is complete.  I think jshell can assume that too.

>                                               But of course, coming from 
> EDITOR there is no way to know if it needed. Between that, the platform 
> specific aspect, and how it would interact with /set and Preferences -- 
> it seemed a bit convoluted and shaky.  Still an option but it doesn't 
> solve the problem -- just another finger in the dike.

All too often we've built useful tools in the JDK but failed to make
them relate well to the environments in which they're actually used.
I'd hate to see jshell fall into the same trap.  Please reconsider
this.

- Mark

From brian.goetz at oracle.com  Wed Oct 12 19:16:29 2016
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 12 Oct 2016 15:16:29 -0400
Subject: JShell tool: remove or keep default Edit Pad editor?
In-Reply-To: <20161012101216.896781462eggemoggin.niobe.net>
References: <57FBF893.4040607@oracle.com>
	<CF81D97E-28F6-4E95-82FB-498570A1E9D0@oracle.com>
	<20161011160919.399889281eggemoggin.niobe.net>
	<57FD891D.2040806@oracle.com>
	<20161012101216.896781462eggemoggin.niobe.net>
Message-ID: <84209863-9314-6f14-c465-3a3992ccfa63@oracle.com>


> Every Unix tool I've ever seen that uses EDITOR has assumed that the
> command defined by that environment variable will not return until the
> editing operation is complete.  I think jshell can assume that too.

And, every Windows system has Notepad installed.  So between *nix and 
Windows, that might cover the waterfront...


From jan.lahoda at oracle.com  Wed Oct 12 19:41:43 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 12 Oct 2016 21:41:43 +0200
Subject: RFR JDK-8167461: jshell tool: Scanner#next() hangs tool
Message-ID: <57FE91F7.2020605@oracle.com>

Hello,

Bug:
https://bugs.openjdk.java.net/browse/JDK-8167461

The problem is that this sequence of snippets is not working properly 
(won't read the System.in properly/seemingly hangs):
jshell> Scanner input = new Scanner(System.in);
jshell> int x = input.nextInt();

The reason is that the PipeInputStream (which is used to pass data 
received by the remote agent from the socket to System.in) does not 
override the read(byte[], int, int) method. So the default 
implementation will be used, which waits until all the requested data 
are read. Scanner wrap s the System.in with InputStreamReader, and that 
appears to read (up to) 8192 bytes into a buffer, but the user typically 
does not type so many characters. The solution is to override the 
read(byte[], int, int) method, and return only bytes we have buffered 
(except the method will wait for the first byte).

Webrev:
http://cr.openjdk.java.net/~jlahoda/8167461/webrev.00/

Also, more general question related to the System.in handling: unused 
input for one snippet is not passed to following snippets - is that OK, 
or do we need to discuss changing that? I.e.:
jshell> int x = input.nextInt();
1 1
x ==> 1
//the other "1" is thrown away

jshell> int x = input.nextInt();
2
x ==> 2
//the user had to type additional input.

Thanks,
     Jan

From robert.field at oracle.com  Wed Oct 12 20:52:12 2016
From: robert.field at oracle.com (Robert Field)
Date: Wed, 12 Oct 2016 13:52:12 -0700
Subject: RFR JDK-8167461: jshell tool: Scanner#next() hangs tool
In-Reply-To: <57FE91F7.2020605@oracle.com>
References: <57FE91F7.2020605@oracle.com>
Message-ID: <57FEA27C.7050101@oracle.com>

Looks good.  Might be safest to copy the checks from the top of 
InputStream's implementation --

     public int read(byte b[], int off, int len) throws IOException {
         if (b == null) {
             throw new NullPointerException();
         } else if (off < 0 || len < 0 || len > b.length - off) {
             throw new IndexOutOfBoundsException();
         } else if (len == 0) {
             return 0;
         }

I'm somewhat unclear on why the read/write in Util are changed to the 
buffered form.  BTW.  There isn't (and wasn't) an EOF test here.

As to input carrying over: I can see either as being surprising in some 
cases.  As-is, very simple "Enter two numbers: " kinds of newbie coding 
will misbehave, and misbehave in a way that could look like a hang 
(waiting on input).
With a input carry-over implementation however, garbage entered, perhaps 
much earlier in the session would still be what is read later -- that 
could be hard to diagnose, and would take coding (or a /reset) to cure.
I think addressing that should be a separate issue.

-Robert

On 10/12/16 12:41, Jan Lahoda wrote:
> Hello,
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8167461
>
> The problem is that this sequence of snippets is not working properly 
> (won't read the System.in properly/seemingly hangs):
> jshell> Scanner input = new Scanner(System.in);
> jshell> int x = input.nextInt();
>
> The reason is that the PipeInputStream (which is used to pass data 
> received by the remote agent from the socket to System.in) does not 
> override the read(byte[], int, int) method. So the default 
> implementation will be used, which waits until all the requested data 
> are read. Scanner wrap s the System.in with InputStreamReader, and 
> that appears to read (up to) 8192 bytes into a buffer, but the user 
> typically does not type so many characters. The solution is to 
> override the read(byte[], int, int) method, and return only bytes we 
> have buffered (except the method will wait for the first byte).
>
> Webrev:
> http://cr.openjdk.java.net/~jlahoda/8167461/webrev.00/
>
> Also, more general question related to the System.in handling: unused 
> input for one snippet is not passed to following snippets - is that 
> OK, or do we need to discuss changing that? I.e.:
> jshell> int x = input.nextInt();
> 1 1
> x ==> 1
> //the other "1" is thrown away
>
> jshell> int x = input.nextInt();
> 2
> x ==> 2
> //the user had to type additional input.
>
> Thanks,
>     Jan


From robert.field at oracle.com  Wed Oct 12 21:08:31 2016
From: robert.field at oracle.com (Robert Field)
Date: Wed, 12 Oct 2016 14:08:31 -0700
Subject: JShell tool: remove or keep default Edit Pad editor?
In-Reply-To: <20161012101216.896781462eggemoggin.niobe.net>
References: <57FBF893.4040607@oracle.com>
	<CF81D97E-28F6-4E95-82FB-498570A1E9D0@oracle.com>
	<20161011160919.399889281eggemoggin.niobe.net>
	<57FD891D.2040806@oracle.com>
	<20161012101216.896781462eggemoggin.niobe.net>
Message-ID: <57FEA64F.7050801@oracle.com>


On 10/12/16 10:12, mark.reinhold at oracle.com wrote:
> 2016/10/11 17:51:41 -0700, robert.field at oracle.com:
>> On 10/11/16 16:09, mark.reinhold at oracle.com wrote:
>>> 2016/10/10 17:31:35 -0700, paul.sandoz at oracle.com:
>>>> ...
>>>>
>>>> One approach for an out of the box solution is to split out the editor
>>>> functionality into a separate module and for jshell to define a
>>>> service provider interface. Thereby on a full JDK distribution you can
>>>> the same functionality but on a more minimal distribution it is not
>>>> present.
>>> That would be the "modular" way to do it.
>> That would certainly be doable.  If the critical concern is module
>> boundaries.  But that exposes the Edit Pad to use outside of jshell --
>> is that an issue?
> You can prevent undue exposure by defining the service type in the
> jdk.jshell module and exporting its containing package only to the
> new module that contains Edit Pad, something like this:
>
>      module jdk.jshell {
>          exports jdk.jshell.editor.spi to jdk.internal.editpad;
>          ...
>      }
>
>      module jdk.internal.editpad {
>          requires java.desktop;
>          requires jdk.jshell;
>          provides jdk.jshell.editor.spi.Editor
>              with jdk.internal.editpad.EditorProvider;
>      }

Nice!  I've created:

     jshell tool: Edit Pad should be in its own module
     https://bugs.openjdk.java.net/browse/JDK-8167636

>>> ...
>>>
>>> Have you considered, at least on Unix systems, supporting the EDITOR
>>> environment variable?  Yes, it might be platform-specific, but it's an
>>> incredibly handy and reasonably standard way to tell random programs how
>>> to use the editor of your choice.
>> Was tempted.  The jshell tool suspends the REPL while in the editor (so
>> they don't clash).  However some editors return immediately -- there is
>> a -wait option on /set editor for this case.
> Every Unix tool I've ever seen that uses EDITOR has assumed that the
> command defined by that environment variable will not return until the
> editing operation is complete.  I think jshell can assume that too.

Given that assumption, that is a good idea.  Created:

     jshell tool: /edit should use EDITOR setting
     https://bugs.openjdk.java.net/browse/JDK-8167637

>
>>                                                But of course, coming from
>> EDITOR there is no way to know if it needed. Between that, the platform
>> specific aspect, and how it would interact with /set and Preferences --
>> it seemed a bit convoluted and shaky.  Still an option but it doesn't
>> solve the problem -- just another finger in the dike.
> All too often we've built useful tools in the JDK but failed to make
> them relate well to the environments in which they're actually used.
> I'd hate to see jshell fall into the same trap.  Please reconsider
> this.

Done!

-Robert

>
> - Mark


From robert.field at oracle.com  Wed Oct 12 21:15:19 2016
From: robert.field at oracle.com (Robert Field)
Date: Wed, 12 Oct 2016 14:15:19 -0700
Subject: JShell /-n command
In-Reply-To: <29EEDF78-3E33-4B31-818D-F8EDA68421B7@deitel.com>
References: <mailman.36168.1476247488.23828.kulla-dev@openjdk.java.net>	<5A596307-1965-4B2D-AB48-F99D177D24B3@deitel.com>
	<29EEDF78-3E33-4B31-818D-F8EDA68421B7@deitel.com>
Message-ID: <57FEA7E7.1040206@oracle.com>

I agree this isn't useful and is confusing -- for another reason too -- 
from /help:

| /<id> -- re-run snippet by id
| /-<n> -- re-run n-th previous snippet

So /3 refers to a snippet-id and /-3 refers to a count backwards.

I've never used the /-n form.  For one, the up-arrow is much more 
convenient.

Unless I hear an strong advocate, I will remove.

Thanks,
Robert

On 10/12/16 09:55, Paul Deitel wrote:
> Is the command
>
> 	/-n
>
> actually useful? Chances are, if you have any decent number of snippets, you will not recall more than the last few you typed.
>
> You can already execute the last valid snippet with /!.
>
> For anything else, you?d probably have to do a /list to see what valid snippets you have. At that point, rather than doing /-n, you?d just use /<id> to execute a given snippet.
>
> One point of emphasis in many JShell presentation has been how it?s useful for beginners. I?ve been teaching beginning programmers for 25+ years. A beginner seeing options like this will only get confused.
>
> I recommend removing /-n as an option.
>
> Paul
>
> Paul J. Deitel, CEO
> Deitel & Associates, Inc.
> Oracle Java Champion
> Microsoft Visual C# MVP 2012-2014
>
> http://www.deitel.com
> 978-443-2423
>
> Facebook: http://facebook.com/DeitelFan
> Twitter: @deitel
> LinkedIn: http://www.linkedin.com/company/deitel-&-associates
> YouTube: http://youtube.com/DeitelTV
> Instagram: http://instagram.com/DeitelFan
> Google+: http://google.com/+DeitelFan
>
> Newsletter: http://www.deitel.com/newsletter/subscribe.html
>
> On-Site Worldwide Corporate Training: http://www.deitel.com/training/
> Purchase our most recent books: http://amzn.to/18BLG2I
> Resource Centers: http://www.deitel.com/ResourceCenters.html
>
>
>
>


From robert.field at oracle.com  Wed Oct 12 22:56:13 2016
From: robert.field at oracle.com (Robert Field)
Date: Wed, 12 Oct 2016 15:56:13 -0700
Subject: JShell tool: remove or keep default Edit Pad editor?
In-Reply-To: <5A596307-1965-4B2D-AB48-F99D177D24B3@deitel.com>
References: <mailman.36168.1476247488.23828.kulla-dev@openjdk.java.net>
	<5A596307-1965-4B2D-AB48-F99D177D24B3@deitel.com>
Message-ID: <57FEBF8D.2040102@oracle.com>


On 10/12/16 09:04, Paul Deitel wrote:
> While I understand the issue of bundling Edit Pad with respect to modularization, as an author of introductory computer programming texts, like Java How to Program, command line REPL is much less useful for beginners if they have to try to figure out how to edit something like a complete class definition from the command line.
>
> If possible, I?d recommend somehow providing access to a more robust cross-platform editor?perhaps something like jEdit (jedit.org). If not, perhaps the modularized JShell could provide an option that enables Edit Pad if someone wants to use it.

jEdit is a nice editor.  I've started to use it as a stand-alone editor 
-- thanks.   There are a lot issues with rolling external code into the 
JDK -- and were it added the update cycle is far shower than in the 
wild..  I think for a newbie jEdit would look like a jet console.  
Besides that somethings works out of the box, the idea of the Edit Pad 
is to be dead-simple for newbies.

jEdit would be a good choice for a user to use as the retained external 
editor jshell setting.   I notice however that doing so you do not get 
Java features, like syntax highlighting because the file ends in 
".edit".  I've added:

     jshell tool: external editor temp file should be *.java
     https://bugs.openjdk.java.net/browse/JDK-8167640

>
> If you do keep Edit Pad, here are some changes I?d like to see to make it slightly nicer:
>
> a. Use a fixed-width code font for readability
>
> b. Use a bigger font size or provide controls for changing the font size--the current size is tiny and hard to read
>
> c. Add 5-10 pixels of padding between the textbox containing the code and the window border?right now the left edge of the code is right up against the window?s border, again making the code hard to read.
>
> d. Separate each snippet from the next by a blank line.

I have added:

     jshell tool: Edit Pad has readability issues
     https://bugs.openjdk.java.net/browse/JDK-8167639

Separating by a blank line I have some hesitation.  For one, it does not 
match what is sent to external editors.

Thanks,
Robert

>
> Thanks,
> Paul


From jonathan.gibbons at oracle.com  Wed Oct 12 23:04:16 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 12 Oct 2016 16:04:16 -0700
Subject: JShell tool: remove or keep default Edit Pad editor?
In-Reply-To: <57FEBF8D.2040102@oracle.com>
References: <mailman.36168.1476247488.23828.kulla-dev@openjdk.java.net>	<5A596307-1965-4B2D-AB48-F99D177D24B3@deitel.com>
	<57FEBF8D.2040102@oracle.com>
Message-ID: <57FEC170.6080503@oracle.com>

The nice thing about a service-oriented approach is that you could 
provide/support/allow different editor services, such as "use EditPad", 
"use JEdit", "use EDITOR", and the user could configure their choice.

-- Jon


On 10/12/2016 03:56 PM, Robert Field wrote:
>
> On 10/12/16 09:04, Paul Deitel wrote:
>> While I understand the issue of bundling Edit Pad with respect to 
>> modularization, as an author of introductory computer programming 
>> texts, like Java How to Program, command line REPL is much less 
>> useful for beginners if they have to try to figure out how to edit 
>> something like a complete class definition from the command line.
>>
>> If possible, I?d recommend somehow providing access to a more robust 
>> cross-platform editor?perhaps something like jEdit (jedit.org). If 
>> not, perhaps the modularized JShell could provide an option that 
>> enables Edit Pad if someone wants to use it.
>
> jEdit is a nice editor.  I've started to use it as a stand-alone 
> editor -- thanks.   There are a lot issues with rolling external code 
> into the JDK -- and were it added the update cycle is far shower than 
> in the wild..  I think for a newbie jEdit would look like a jet 
> console.  Besides that somethings works out of the box, the idea of 
> the Edit Pad is to be dead-simple for newbies.
>
> jEdit would be a good choice for a user to use as the retained 
> external editor jshell setting.   I notice however that doing so you 
> do not get Java features, like syntax highlighting because the file 
> ends in ".edit".  I've added:
>
>     jshell tool: external editor temp file should be *.java
>     https://bugs.openjdk.java.net/browse/JDK-8167640
>
>>
>> If you do keep Edit Pad, here are some changes I?d like to see to 
>> make it slightly nicer:
>>
>> a. Use a fixed-width code font for readability
>>
>> b. Use a bigger font size or provide controls for changing the font 
>> size--the current size is tiny and hard to read
>>
>> c. Add 5-10 pixels of padding between the textbox containing the code 
>> and the window border?right now the left edge of the code is right up 
>> against the window?s border, again making the code hard to read.
>>
>> d. Separate each snippet from the next by a blank line.
>
> I have added:
>
>     jshell tool: Edit Pad has readability issues
>     https://bugs.openjdk.java.net/browse/JDK-8167639
>
> Separating by a blank line I have some hesitation.  For one, it does 
> not match what is sent to external editors.
>
> Thanks,
> Robert
>
>>
>> Thanks,
>> Paul
>


From brian.goetz at oracle.com  Thu Oct 13 17:04:08 2016
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 13 Oct 2016 13:04:08 -0400
Subject: JShell /-n command
In-Reply-To: <57FEA7E7.1040206@oracle.com>
References: <mailman.36168.1476247488.23828.kulla-dev@openjdk.java.net>
	<5A596307-1965-4B2D-AB48-F99D177D24B3@deitel.com>
	<29EEDF78-3E33-4B31-818D-F8EDA68421B7@deitel.com>
	<57FEA7E7.1040206@oracle.com>
Message-ID: <01f7650c-140f-292f-7560-042e2cfe1a82@oracle.com>

This is derived from a feature from Unix shells, which I use all the 
time; frequently you have a sequence of "do this, then do that, then do 
the other thing", and doing "-n" repeatedly handles that sequence.  
Easier than "hit up arrow five times, return, repeat".

On 10/12/2016 5:15 PM, Robert Field wrote:
> I agree this isn't useful and is confusing -- for another reason too 
> -- from /help:
>
> | /<id> -- re-run snippet by id
> | /-<n> -- re-run n-th previous snippet
>
> So /3 refers to a snippet-id and /-3 refers to a count backwards.
>
> I've never used the /-n form.  For one, the up-arrow is much more 
> convenient.
>
> Unless I hear an strong advocate, I will remove.
>
> Thanks,
> Robert
>
> On 10/12/16 09:55, Paul Deitel wrote:
>> Is the command
>>
>>     /-n
>>
>> actually useful? Chances are, if you have any decent number of 
>> snippets, you will not recall more than the last few you typed.
>>
>> You can already execute the last valid snippet with /!.
>>
>> For anything else, you?d probably have to do a /list to see what 
>> valid snippets you have. At that point, rather than doing /-n, you?d 
>> just use /<id> to execute a given snippet.
>>
>> One point of emphasis in many JShell presentation has been how it?s 
>> useful for beginners. I?ve been teaching beginning programmers for 
>> 25+ years. A beginner seeing options like this will only get confused.
>>
>> I recommend removing /-n as an option.
>>
>> Paul
>>
>> Paul J. Deitel, CEO
>> Deitel & Associates, Inc.
>> Oracle Java Champion
>> Microsoft Visual C# MVP 2012-2014
>>
>> http://www.deitel.com
>> 978-443-2423
>>
>> Facebook: http://facebook.com/DeitelFan
>> Twitter: @deitel
>> LinkedIn: http://www.linkedin.com/company/deitel-&-associates
>> YouTube: http://youtube.com/DeitelTV
>> Instagram: http://instagram.com/DeitelFan
>> Google+: http://google.com/+DeitelFan
>>
>> Newsletter: http://www.deitel.com/newsletter/subscribe.html
>>
>> On-Site Worldwide Corporate Training: http://www.deitel.com/training/
>> Purchase our most recent books: http://amzn.to/18BLG2I
>> Resource Centers: http://www.deitel.com/ResourceCenters.html
>>
>>
>>
>>
>


From michael.mueller at mueller-bruehl.de  Thu Oct 13 17:45:14 2016
From: michael.mueller at mueller-bruehl.de (=?ISO-8859-1?Q?Michael_M=FCller?=)
Date: Thu, 13 Oct 2016 19:45:14 +0200
Subject: JShell /-n command
In-Reply-To: <01f7650c-140f-292f-7560-042e2cfe1a82@oracle.com>
References: <mailman.36168.1476247488.23828.kulla-dev@openjdk.java.net>
	<5A596307-1965-4B2D-AB48-F99D177D24B3@deitel.com>
	<29EEDF78-3E33-4B31-818D-F8EDA68421B7@deitel.com>
	<57FEA7E7.1040206@oracle.com>
	<01f7650c-140f-292f-7560-042e2cfe1a82@oracle.com>
Message-ID: <D20BFFFC-EFA4-48A8-911C-DFF4DD0DB21D@mueller-bruehl.de>

+1
-- 
Herzliche Gr??e, Best regards
Michael M?ller

Twitter: @muellermi
Blog: blog.mueller-bruehl.de
Web Development with Java and JSF: leanpub.com/jsf
Java Lambdas and Parallel Streams: leanpub.com/lambdas


Am 13. Oktober 2016 19:04:08 MESZ, schrieb Brian Goetz <brian.goetz at oracle.com>:
>This is derived from a feature from Unix shells, which I use all the 
>time; frequently you have a sequence of "do this, then do that, then do
>
>the other thing", and doing "-n" repeatedly handles that sequence.  
>Easier than "hit up arrow five times, return, repeat".
>
>On 10/12/2016 5:15 PM, Robert Field wrote:
>> I agree this isn't useful and is confusing -- for another reason too 
>> -- from /help:
>>
>> | /<id> -- re-run snippet by id
>> | /-<n> -- re-run n-th previous snippet
>>
>> So /3 refers to a snippet-id and /-3 refers to a count backwards.
>>
>> I've never used the /-n form.  For one, the up-arrow is much more 
>> convenient.
>>
>> Unless I hear an strong advocate, I will remove.
>>
>> Thanks,
>> Robert
>>
>> On 10/12/16 09:55, Paul Deitel wrote:
>>> Is the command
>>>
>>>     /-n
>>>
>>> actually useful? Chances are, if you have any decent number of 
>>> snippets, you will not recall more than the last few you typed.
>>>
>>> You can already execute the last valid snippet with /!.
>>>
>>> For anything else, you?d probably have to do a /list to see what 
>>> valid snippets you have. At that point, rather than doing /-n, you?d
>
>>> just use /<id> to execute a given snippet.
>>>
>>> One point of emphasis in many JShell presentation has been how it?s 
>>> useful for beginners. I?ve been teaching beginning programmers for 
>>> 25+ years. A beginner seeing options like this will only get
>confused.
>>>
>>> I recommend removing /-n as an option.
>>>
>>> Paul
>>>
>>> Paul J. Deitel, CEO
>>> Deitel & Associates, Inc.
>>> Oracle Java Champion
>>> Microsoft Visual C# MVP 2012-2014
>>>
>>> http://www.deitel.com
>>> 978-443-2423
>>>
>>> Facebook: http://facebook.com/DeitelFan
>>> Twitter: @deitel
>>> LinkedIn: http://www.linkedin.com/company/deitel-&-associates
>>> YouTube: http://youtube.com/DeitelTV
>>> Instagram: http://instagram.com/DeitelFan
>>> Google+: http://google.com/+DeitelFan
>>>
>>> Newsletter: http://www.deitel.com/newsletter/subscribe.html
>>>
>>> On-Site Worldwide Corporate Training:
>http://www.deitel.com/training/
>>> Purchase our most recent books: http://amzn.to/18BLG2I
>>> Resource Centers: http://www.deitel.com/ResourceCenters.html
>>>
>>>
>>>
>>>
>>

From jan.lahoda at oracle.com  Thu Oct 13 18:53:49 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 13 Oct 2016 20:53:49 +0200
Subject: RFR JDK-8167461: jshell tool: Scanner#next() hangs tool
In-Reply-To: <57FEA27C.7050101@oracle.com>
References: <57FE91F7.2020605@oracle.com> <57FEA27C.7050101@oracle.com>
Message-ID: <57FFD83D.9060804@oracle.com>

On 12.10.2016 22:52, Robert Field wrote:
> Looks good.  Might be safest to copy the checks from the top of
> InputStream's implementation --
>
>      public int read(byte b[], int off, int len) throws IOException {
>          if (b == null) {
>              throw new NullPointerException();
>          } else if (off < 0 || len < 0 || len > b.length - off) {
>              throw new IndexOutOfBoundsException();
>          } else if (len == 0) {
>              return 0;
>          }

Yes, makes sense.

>
> I'm somewhat unclear on why the read/write in Util are changed to the
> buffered form.  BTW.  There isn't (and wasn't) an EOF test here.

The reason is that (currently), when the user's snippet is waiting for 
input and the user types Ctrl-C, the user's snippet is stopped, but the 
read method returns -1 (see ConsoleIOContext.readUserInput()) (somewhat 
pretending stream end). So this change was to prevent writing this -1 to 
the remote side.

But, I was thinking how to improve that (and add/fix handling of EOF as 
well, even though I guess it might be surprising if the user in is 
closed). And we could do this:
-add a new exception, like StopException (similar to JLine's 
UserInterruptException)
-the (user-)in.read() could throw the exception to signal the user 
cancelled the input. execution.Util.remoteInputOutput would then take 
care of cancelling the user's code, and would know to not pass any data 
to the agent.

What do you think?

Thanks,
    Jan

>
> As to input carrying over: I can see either as being surprising in some
> cases.  As-is, very simple "Enter two numbers: " kinds of newbie coding
> will misbehave, and misbehave in a way that could look like a hang
> (waiting on input).
> With a input carry-over implementation however, garbage entered, perhaps
> much earlier in the session would still be what is read later -- that
> could be hard to diagnose, and would take coding (or a /reset) to cure.
> I think addressing that should be a separate issue.
>
> -Robert
>
> On 10/12/16 12:41, Jan Lahoda wrote:
>> Hello,
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8167461
>>
>> The problem is that this sequence of snippets is not working properly
>> (won't read the System.in properly/seemingly hangs):
>> jshell> Scanner input = new Scanner(System.in);
>> jshell> int x = input.nextInt();
>>
>> The reason is that the PipeInputStream (which is used to pass data
>> received by the remote agent from the socket to System.in) does not
>> override the read(byte[], int, int) method. So the default
>> implementation will be used, which waits until all the requested data
>> are read. Scanner wrap s the System.in with InputStreamReader, and
>> that appears to read (up to) 8192 bytes into a buffer, but the user
>> typically does not type so many characters. The solution is to
>> override the read(byte[], int, int) method, and return only bytes we
>> have buffered (except the method will wait for the first byte).
>>
>> Webrev:
>> http://cr.openjdk.java.net/~jlahoda/8167461/webrev.00/
>>
>> Also, more general question related to the System.in handling: unused
>> input for one snippet is not passed to following snippets - is that
>> OK, or do we need to discuss changing that? I.e.:
>> jshell> int x = input.nextInt();
>> 1 1
>> x ==> 1
>> //the other "1" is thrown away
>>
>> jshell> int x = input.nextInt();
>> 2
>> x ==> 2
>> //the user had to type additional input.
>>
>> Thanks,
>>     Jan
>

From robert.field at oracle.com  Thu Oct 13 19:29:13 2016
From: robert.field at oracle.com (Robert Field)
Date: Thu, 13 Oct 2016 12:29:13 -0700
Subject: RFR JDK-8167461: jshell tool: Scanner#next() hangs tool
In-Reply-To: <57FFD83D.9060804@oracle.com>
References: <57FE91F7.2020605@oracle.com> <57FEA27C.7050101@oracle.com>
	<57FFD83D.9060804@oracle.com>
Message-ID: <57FFE089.4080105@oracle.com>

Looking forward to it!

-Robert

On 10/13/16 11:53, Jan Lahoda wrote:
> On 12.10.2016 22:52, Robert Field wrote:
>> Looks good.  Might be safest to copy the checks from the top of
>> InputStream's implementation --
>>
>>      public int read(byte b[], int off, int len) throws IOException {
>>          if (b == null) {
>>              throw new NullPointerException();
>>          } else if (off < 0 || len < 0 || len > b.length - off) {
>>              throw new IndexOutOfBoundsException();
>>          } else if (len == 0) {
>>              return 0;
>>          }
>
> Yes, makes sense.
>
>>
>> I'm somewhat unclear on why the read/write in Util are changed to the
>> buffered form.  BTW.  There isn't (and wasn't) an EOF test here.
>
> The reason is that (currently), when the user's snippet is waiting for 
> input and the user types Ctrl-C, the user's snippet is stopped, but 
> the read method returns -1 (see ConsoleIOContext.readUserInput()) 
> (somewhat pretending stream end). So this change was to prevent 
> writing this -1 to the remote side.
>
> But, I was thinking how to improve that (and add/fix handling of EOF 
> as well, even though I guess it might be surprising if the user in is 
> closed). And we could do this:
> -add a new exception, like StopException (similar to JLine's 
> UserInterruptException)
> -the (user-)in.read() could throw the exception to signal the user 
> cancelled the input. execution.Util.remoteInputOutput would then take 
> care of cancelling the user's code, and would know to not pass any 
> data to the agent.
>
> What do you think?
>
> Thanks,
>    Jan
>
>>
>> As to input carrying over: I can see either as being surprising in some
>> cases.  As-is, very simple "Enter two numbers: " kinds of newbie coding
>> will misbehave, and misbehave in a way that could look like a hang
>> (waiting on input).
>> With a input carry-over implementation however, garbage entered, perhaps
>> much earlier in the session would still be what is read later -- that
>> could be hard to diagnose, and would take coding (or a /reset) to cure.
>> I think addressing that should be a separate issue.
>>
>> -Robert
>>
>> On 10/12/16 12:41, Jan Lahoda wrote:
>>> Hello,
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8167461
>>>
>>> The problem is that this sequence of snippets is not working properly
>>> (won't read the System.in properly/seemingly hangs):
>>> jshell> Scanner input = new Scanner(System.in);
>>> jshell> int x = input.nextInt();
>>>
>>> The reason is that the PipeInputStream (which is used to pass data
>>> received by the remote agent from the socket to System.in) does not
>>> override the read(byte[], int, int) method. So the default
>>> implementation will be used, which waits until all the requested data
>>> are read. Scanner wrap s the System.in with InputStreamReader, and
>>> that appears to read (up to) 8192 bytes into a buffer, but the user
>>> typically does not type so many characters. The solution is to
>>> override the read(byte[], int, int) method, and return only bytes we
>>> have buffered (except the method will wait for the first byte).
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~jlahoda/8167461/webrev.00/
>>>
>>> Also, more general question related to the System.in handling: unused
>>> input for one snippet is not passed to following snippets - is that
>>> OK, or do we need to discuss changing that? I.e.:
>>> jshell> int x = input.nextInt();
>>> 1 1
>>> x ==> 1
>>> //the other "1" is thrown away
>>>
>>> jshell> int x = input.nextInt();
>>> 2
>>> x ==> 2
>>> //the user had to type additional input.
>>>
>>> Thanks,
>>>     Jan
>>


From jan.lahoda at oracle.com  Fri Oct 14 13:16:34 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 14 Oct 2016 15:16:34 +0200
Subject: RFR JDK-8167461: jshell tool: Scanner#next() hangs tool
In-Reply-To: <57FFE089.4080105@oracle.com>
References: <57FE91F7.2020605@oracle.com> <57FEA27C.7050101@oracle.com>
	<57FFD83D.9060804@oracle.com> <57FFE089.4080105@oracle.com>
Message-ID: <5800DAB2.60104@oracle.com>

Hi,

Updated webrev is here:
http://cr.openjdk.java.net/~jlahoda/8167461/webrev.01/

In the end, I used InterruptedIOException instead of some newly created 
StopException, as it seems reasonably close to what we need.

The userin data that are being sent from the engine to the remote agent 
are tagged now, and allow to send data, close the stream, and partially 
transfer exceptions (just the exception's message is transferred, not 
the stack trace).

What do you think?

Thanks,
     Jan

On 13.10.2016 21:29, Robert Field wrote:
> Looking forward to it!
>
> -Robert
>
> On 10/13/16 11:53, Jan Lahoda wrote:
>> On 12.10.2016 22:52, Robert Field wrote:
>>> Looks good.  Might be safest to copy the checks from the top of
>>> InputStream's implementation --
>>>
>>>      public int read(byte b[], int off, int len) throws IOException {
>>>          if (b == null) {
>>>              throw new NullPointerException();
>>>          } else if (off < 0 || len < 0 || len > b.length - off) {
>>>              throw new IndexOutOfBoundsException();
>>>          } else if (len == 0) {
>>>              return 0;
>>>          }
>>
>> Yes, makes sense.
>>
>>>
>>> I'm somewhat unclear on why the read/write in Util are changed to the
>>> buffered form.  BTW.  There isn't (and wasn't) an EOF test here.
>>
>> The reason is that (currently), when the user's snippet is waiting for
>> input and the user types Ctrl-C, the user's snippet is stopped, but
>> the read method returns -1 (see ConsoleIOContext.readUserInput())
>> (somewhat pretending stream end). So this change was to prevent
>> writing this -1 to the remote side.
>>
>> But, I was thinking how to improve that (and add/fix handling of EOF
>> as well, even though I guess it might be surprising if the user in is
>> closed). And we could do this:
>> -add a new exception, like StopException (similar to JLine's
>> UserInterruptException)
>> -the (user-)in.read() could throw the exception to signal the user
>> cancelled the input. execution.Util.remoteInputOutput would then take
>> care of cancelling the user's code, and would know to not pass any
>> data to the agent.
>>
>> What do you think?
>>
>> Thanks,
>>    Jan
>>
>>>
>>> As to input carrying over: I can see either as being surprising in some
>>> cases.  As-is, very simple "Enter two numbers: " kinds of newbie coding
>>> will misbehave, and misbehave in a way that could look like a hang
>>> (waiting on input).
>>> With a input carry-over implementation however, garbage entered, perhaps
>>> much earlier in the session would still be what is read later -- that
>>> could be hard to diagnose, and would take coding (or a /reset) to cure.
>>> I think addressing that should be a separate issue.
>>>
>>> -Robert
>>>
>>> On 10/12/16 12:41, Jan Lahoda wrote:
>>>> Hello,
>>>>
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8167461
>>>>
>>>> The problem is that this sequence of snippets is not working properly
>>>> (won't read the System.in properly/seemingly hangs):
>>>> jshell> Scanner input = new Scanner(System.in);
>>>> jshell> int x = input.nextInt();
>>>>
>>>> The reason is that the PipeInputStream (which is used to pass data
>>>> received by the remote agent from the socket to System.in) does not
>>>> override the read(byte[], int, int) method. So the default
>>>> implementation will be used, which waits until all the requested data
>>>> are read. Scanner wrap s the System.in with InputStreamReader, and
>>>> that appears to read (up to) 8192 bytes into a buffer, but the user
>>>> typically does not type so many characters. The solution is to
>>>> override the read(byte[], int, int) method, and return only bytes we
>>>> have buffered (except the method will wait for the first byte).
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~jlahoda/8167461/webrev.00/
>>>>
>>>> Also, more general question related to the System.in handling: unused
>>>> input for one snippet is not passed to following snippets - is that
>>>> OK, or do we need to discuss changing that? I.e.:
>>>> jshell> int x = input.nextInt();
>>>> 1 1
>>>> x ==> 1
>>>> //the other "1" is thrown away
>>>>
>>>> jshell> int x = input.nextInt();
>>>> 2
>>>> x ==> 2
>>>> //the user had to type additional input.
>>>>
>>>> Thanks,
>>>>     Jan
>>>
>

From robert.field at oracle.com  Fri Oct 14 15:53:50 2016
From: robert.field at oracle.com (Robert Field)
Date: Fri, 14 Oct 2016 08:53:50 -0700
Subject: RFR JDK-8167461: jshell tool: Scanner#next() hangs tool
In-Reply-To: <5800DAB2.60104@oracle.com>
References: <57FE91F7.2020605@oracle.com> <57FEA27C.7050101@oracle.com>
	<57FFD83D.9060804@oracle.com> <57FFE089.4080105@oracle.com>
	<5800DAB2.60104@oracle.com>
Message-ID: <5800FF8E.2000602@oracle.com>

Two things --

(1) This behavior should be documented.

(2) We have "stop()" in the API, but with this, our reference 
implementation does not use it.  Should it exist in the API?
"stop()" also exists in the SPI -- forwarded API -> EC -> remote EC.  
This pathway would no longer be used by our reference implementation.
What does this mean about stop() in the SPI design?

-Robert

On 10/14/16 06:16, Jan Lahoda wrote:
> Hi,
>
> Updated webrev is here:
> http://cr.openjdk.java.net/~jlahoda/8167461/webrev.01/
>
> In the end, I used InterruptedIOException instead of some newly 
> created StopException, as it seems reasonably close to what we need.
>
> The userin data that are being sent from the engine to the remote 
> agent are tagged now, and allow to send data, close the stream, and 
> partially transfer exceptions (just the exception's message is 
> transferred, not the stack trace).
>
> What do you think?
>
> Thanks,
>     Jan
>
> On 13.10.2016 21:29, Robert Field wrote:
>> Looking forward to it!
>>
>> -Robert
>>
>> On 10/13/16 11:53, Jan Lahoda wrote:
>>> On 12.10.2016 22:52, Robert Field wrote:
>>>> Looks good.  Might be safest to copy the checks from the top of
>>>> InputStream's implementation --
>>>>
>>>>      public int read(byte b[], int off, int len) throws IOException {
>>>>          if (b == null) {
>>>>              throw new NullPointerException();
>>>>          } else if (off < 0 || len < 0 || len > b.length - off) {
>>>>              throw new IndexOutOfBoundsException();
>>>>          } else if (len == 0) {
>>>>              return 0;
>>>>          }
>>>
>>> Yes, makes sense.
>>>
>>>>
>>>> I'm somewhat unclear on why the read/write in Util are changed to the
>>>> buffered form.  BTW.  There isn't (and wasn't) an EOF test here.
>>>
>>> The reason is that (currently), when the user's snippet is waiting for
>>> input and the user types Ctrl-C, the user's snippet is stopped, but
>>> the read method returns -1 (see ConsoleIOContext.readUserInput())
>>> (somewhat pretending stream end). So this change was to prevent
>>> writing this -1 to the remote side.
>>>
>>> But, I was thinking how to improve that (and add/fix handling of EOF
>>> as well, even though I guess it might be surprising if the user in is
>>> closed). And we could do this:
>>> -add a new exception, like StopException (similar to JLine's
>>> UserInterruptException)
>>> -the (user-)in.read() could throw the exception to signal the user
>>> cancelled the input. execution.Util.remoteInputOutput would then take
>>> care of cancelling the user's code, and would know to not pass any
>>> data to the agent.
>>>
>>> What do you think?
>>>
>>> Thanks,
>>>    Jan
>>>
>>>>
>>>> As to input carrying over: I can see either as being surprising in 
>>>> some
>>>> cases.  As-is, very simple "Enter two numbers: " kinds of newbie 
>>>> coding
>>>> will misbehave, and misbehave in a way that could look like a hang
>>>> (waiting on input).
>>>> With a input carry-over implementation however, garbage entered, 
>>>> perhaps
>>>> much earlier in the session would still be what is read later -- that
>>>> could be hard to diagnose, and would take coding (or a /reset) to 
>>>> cure.
>>>> I think addressing that should be a separate issue.
>>>>
>>>> -Robert
>>>>
>>>> On 10/12/16 12:41, Jan Lahoda wrote:
>>>>> Hello,
>>>>>
>>>>> Bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8167461
>>>>>
>>>>> The problem is that this sequence of snippets is not working properly
>>>>> (won't read the System.in properly/seemingly hangs):
>>>>> jshell> Scanner input = new Scanner(System.in);
>>>>> jshell> int x = input.nextInt();
>>>>>
>>>>> The reason is that the PipeInputStream (which is used to pass data
>>>>> received by the remote agent from the socket to System.in) does not
>>>>> override the read(byte[], int, int) method. So the default
>>>>> implementation will be used, which waits until all the requested data
>>>>> are read. Scanner wrap s the System.in with InputStreamReader, and
>>>>> that appears to read (up to) 8192 bytes into a buffer, but the user
>>>>> typically does not type so many characters. The solution is to
>>>>> override the read(byte[], int, int) method, and return only bytes we
>>>>> have buffered (except the method will wait for the first byte).
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~jlahoda/8167461/webrev.00/
>>>>>
>>>>> Also, more general question related to the System.in handling: unused
>>>>> input for one snippet is not passed to following snippets - is that
>>>>> OK, or do we need to discuss changing that? I.e.:
>>>>> jshell> int x = input.nextInt();
>>>>> 1 1
>>>>> x ==> 1
>>>>> //the other "1" is thrown away
>>>>>
>>>>> jshell> int x = input.nextInt();
>>>>> 2
>>>>> x ==> 2
>>>>> //the user had to type additional input.
>>>>>
>>>>> Thanks,
>>>>>     Jan
>>>>
>>


From bitterfoxc at gmail.com  Sat Oct 15 12:45:24 2016
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Sat, 15 Oct 2016 21:45:24 +0900
Subject: RFR 8145263: JShell API: Change the format of
	SourceCodeAnalysis#documentation
In-Reply-To: <CAHjBcHOZo-55TZHhnC8UkWpzxeHtvgkw_v9VwkSTSfra2i_Z6g@mail.gmail.com>
References: <CAHjBcHOSbneONaCRjWStxCXYENvyoOxp5RuAStfnBp4-+wZJxw@mail.gmail.com>
	<566ED116.3080502@oracle.com>
	<CAHjBcHN3bMNw+xZ96EOXHNFYVMhT7PxX5PQDdjueE10N+7gg2w@mail.gmail.com>
	<56707E7E.4020704@oracle.com>
	<CAHjBcHMXDQHb-xVnpqG7yGa7Y5tzbUqzug-Y-+gPy0DrUND8nQ@mail.gmail.com>
	<57E979DC.2060007@oracle.com>
	<CAHjBcHOrmtYjiMQ=gPbEKYTTxLDJKT+b7cORPJDuzOXHgi4V1w@mail.gmail.com>
	<CAHjBcHPh3KWx6E+d=_noepg6qfb8Wzh4j1sEWNKf8SFZDWAHng@mail.gmail.com>
	<1577bb420e8.2765.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<57F2B9BD.30202@oracle.com>
	<CAHjBcHOZo-55TZHhnC8UkWpzxeHtvgkw_v9VwkSTSfra2i_Z6g@mail.gmail.com>
Message-ID: <CAHjBcHMcocES2WH28nwszkMb09no9TKudxfom5BbnuWPt_F9ew@mail.gmail.com>

resending...

2016-10-06 14:02 GMT+09:00 ShinyaYoshida <bitterfoxc at gmail.com>:

> Hi Robert, Brian and Jan,
> Thank you for your review and sorry for late reply.
>
> I think throws-clause is still necessary information even if javadoc is
> implemented because some of methods doesn't provide javadoc, such as user
> defined methods or methods in user loaded jars.
> What do you think?
> If you think it's still overkill, I'll drop it.
>
> Regards,
> shinyafox(Shinya Yoshida)
>
>
> 2016-10-04 5:04 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com>:
>
>> Looks OK to me too. I don't have a strong opinion on the throws clause.
>>
>> Jan
>>
>> On 30.9.2016 17:26, Robert Field wrote:
>>
>>> Nice!
>>>
>>> Includes a lot of touches to make it more readable and useful.
>>>
>>> Passing on one bit of feedback from Brian, put into my words: since we
>>> are going to be adding full javadoc access, we want this signature
>>> output crisp. So, the throws clause is probably overkill.
>>>
>>> Thanks,
>>> Robert
>>>
>>> On September 30, 2016 4:04:03 AM ShinyaYoshida <bitterfoxc at gmail.com>
>>> wrote:
>>>
>>> Hi Robert and Jan,
>>>> I've updated the webrev to current code base:
>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.10/
>>>>
>>>> Could you review this?
>>>>
>>>> Regards,
>>>> shinyafox(Shinya Yoshida)
>>>>
>>>>
>>>> 2016-09-27 4:51 GMT+09:00 ShinyaYoshida <bitterfoxc at gmail.com
>>>> <mailto:bitterfoxc at gmail.com>>:
>>>>
>>>>     Hi Robert,
>>>>     Never mind! And I'm also sorry for having left this.
>>>>
>>>>     I'll try updating webrev to current code base until 1/Oct.
>>>>
>>>>     BTW, currently a lot of things in jshell are configurable, could
>>>>     signature of documentation also be configurable in future(JDK10 or
>>>>     9.1 or ...)?
>>>>
>>>>     Thank you,
>>>>     shinyafox(Shinya Yoshida)
>>>>
>>>>     2016-09-26 12:41 GMT-07:00 Robert Field <robert.field at oracle.com
>>>>     <mailto:robert.field at oracle.com>>:
>>>>
>>>>         In reviewing outstanding issues, we discovered this RFR which
>>>>         was left hanging.
>>>>
>>>>         Our sincere apologies for dropping the ball on this.
>>>>
>>>>         We are juggling a lot, if we miss something like this in the
>>>>         future, please let us know.
>>>>
>>>>         I have made some changes in the issue, please note them.  I
>>>>         know there have been some underlying changes as well
>>>>         (parameter names from source).
>>>>
>>>>         If you would be willing to update this RFR we will review
>>>>         promptly.
>>>>
>>>>         Thank you and sorry,
>>>>         Robert
>>>>
>>>>
>>>>         On 12/15/15 17:07, ShinyaYoshida wrote:
>>>>
>>>>>         Hi Jan and Robert,
>>>>>         Thank you.
>>>>>
>>>>>         I've filed:
>>>>>         https://bugs.openjdk.java.net/browse/JDK-8145473
>>>>>         <https://bugs.openjdk.java.net/browse/JDK-8145473>
>>>>>
>>>>>         Ok, I put the type parameters for the constructor before the
>>>>>         traditional(current) form:
>>>>>         http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.01/
>>>>> <http://cr.openjdk.java.net/%7Eshinyafox/kulla/8145263/webrev.01/>
>>>>>
>>>>>         Please review it again.
>>>>>
>>>>>         Regards,
>>>>>         shinyafox(Shinya Yoshida)
>>>>>
>>>>>
>>>>>         2015-12-16 5:56 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com
>>>>>         <mailto:jan.lahoda at oracle.com>>:
>>>>>
>>>>>             Hi Shinya,
>>>>>
>>>>>             On 14.12.2015 15:40, ShinyaYoshida wrote:
>>>>>
>>>>>                 Hi Jan,
>>>>>                 Thank you for your review.
>>>>>
>>>>>                 2015-12-14 23:24 GMT+09:00 Jan Lahoda
>>>>>                 <jan.lahoda at oracle.com <mailto:jan.lahoda at oracle.com>
>>>>>                 <mailto:jan.lahoda at oracle.com
>>>>>
>>>>>                 <mailto:jan.lahoda at oracle.com>>>:
>>>>>
>>>>>                     Hi Shinya,
>>>>>
>>>>>                     Generally, looks good, thanks for looking at
>>>>>                 this! Two comments:
>>>>>                     -for parameter names, I was hoping we could get
>>>>>                 them from the
>>>>>                     sources (if/when available), but we are not doing
>>>>>                 that now, and
>>>>>                     hiding synthetic parameter names makes sense to
>>>>>                 me. So this is OK,
>>>>>                     and if we at some point start to parse parameter
>>>>>                 names from the
>>>>>                     sources, we can tweak the code to do the right
>>>>> thing.
>>>>>
>>>>>                 I think that there should be the issue for the
>>>>>                 parameter names.
>>>>>                 Do you have the issue for that?
>>>>>
>>>>>
>>>>>             No issue for this yet.
>>>>>
>>>>>                 If not, should I create it?
>>>>>
>>>>>
>>>>>             Sure, thanks.
>>>>>
>>>>>
>>>>>
>>>>>                     -not sure if marking constructors with ".new"
>>>>>                     ("type-name.new(<parameters>)") will be clear -
>>>>>                 do you think the
>>>>>                     traditional form ("type-name(<parameters>)") is
>>>>>                 unclear?
>>>>>
>>>>>
>>>>>                 When I consider the constructor with the generics
>>>>>                 like following, I
>>>>>                 notice that the traditional(current) form is
>>>>>                 difficult to represent it.
>>>>>                 class C<T> { <U> C(U u) {} }
>>>>>                 So I choose that format which is like the constructor
>>>>>                 reference.
>>>>>
>>>>>
>>>>>             I think generic constructors (i.e. constructors that
>>>>>             themselves have type parameters) are very uncommon, so I
>>>>>             wouldn't optimize for those. Having the format nice for
>>>>>             usual constructors is more important, I think, even if
>>>>>             the format for these uncommon constructors would be uglier.
>>>>>
>>>>>             Thanks,
>>>>>                 Jan
>>>>>
>>>>>
>>>>>
>>>>>                 Another possible representation is "new <Generics>
>>>>>                 type-name<Generics>(<parameters>)" which is similar
>>>>>                 to the invocation of
>>>>>                 the constructor with generics.
>>>>>
>>>>>                 What do you think?
>>>>>
>>>>>                 Regards,
>>>>>                 shinyafox(Shinya Yoshida)
>>>>>
>>>>>
>>>>>                     Thanks,
>>>>>                          Jan
>>>>>
>>>>>
>>>>>                     On 13.12.2015 07:33, ShinyaYoshida wrote:
>>>>>
>>>>>                         Hi Jan and Robert,
>>>>>                         I'd like to propose changing the format of
>>>>>                         SourceCodeAnalysis#documentation.
>>>>>
>>>>>                         The detail of the change is on the issue
>>>>> 8145263:
>>>>>                 https://bugs.openjdk.java.net/browse/JDK-8145263
>>>>>                 <https://bugs.openjdk.java.net/browse/JDK-8145263>
>>>>>                         Please see it.
>>>>>
>>>>>                         You can see the more example in the test of
>>>>>                 my patch.
>>>>>
>>>>>                         Patch is here:
>>>>>                 http://cr.openjdk.java.net/~sh
>>>>> inyafox/kulla/8145263/webrev.00/
>>>>>                 <http://cr.openjdk.java.net/%7
>>>>> Eshinyafox/kulla/8145263/webrev.00/>
>>>>>
>>>>>                         Please consider my proposal and review the
>>>>> patch.
>>>>>
>>>>>                         Regards,
>>>>>                         shinyafox(Shinya Yoshida)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>

From jan.lahoda at oracle.com  Sun Oct 16 18:17:20 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Sun, 16 Oct 2016 20:17:20 +0200
Subject: RFR JDK-8167461: jshell tool: Scanner#next() hangs tool
In-Reply-To: <5800FF8E.2000602@oracle.com>
References: <57FE91F7.2020605@oracle.com> <57FEA27C.7050101@oracle.com>
	<57FFD83D.9060804@oracle.com> <57FFE089.4080105@oracle.com>
	<5800DAB2.60104@oracle.com> <5800FF8E.2000602@oracle.com>
Message-ID: <5803C430.6040902@oracle.com>

On 14.10.2016 17:53, Robert Field wrote:
> Two things --
>
> (1) This behavior should be documented.

Sure, updated webrev:
http://cr.openjdk.java.net/~jlahoda/8167461/webrev.02/

>
> (2) We have "stop()" in the API, but with this, our reference
> implementation does not use it.  Should it exist in the API?
> "stop()" also exists in the SPI -- forwarded API -> EC -> remote EC.
> This pathway would no longer be used by our reference implementation.
> What does this mean about stop() in the SPI design?

We still call the API version from the StopDetectingInputStream (via the 
"stop" Runnable filled in the constructor of ConsoleIOContext).

Even if we didn't call the API, then I would still think the stop method 
should be in the API, for cases where the client would like to implement 
e.g. a watchdog.

Introducing an alternative way to do the stop while waiting for input is 
not perfect, but so far, I don't see a better solution. Any ideas?

Thanks,
     Jan

>
> -Robert
>
> On 10/14/16 06:16, Jan Lahoda wrote:
>> Hi,
>>
>> Updated webrev is here:
>> http://cr.openjdk.java.net/~jlahoda/8167461/webrev.01/
>>
>> In the end, I used InterruptedIOException instead of some newly
>> created StopException, as it seems reasonably close to what we need.
>>
>> The userin data that are being sent from the engine to the remote
>> agent are tagged now, and allow to send data, close the stream, and
>> partially transfer exceptions (just the exception's message is
>> transferred, not the stack trace).
>>
>> What do you think?
>>
>> Thanks,
>>     Jan
>>
>> On 13.10.2016 21:29, Robert Field wrote:
>>> Looking forward to it!
>>>
>>> -Robert
>>>
>>> On 10/13/16 11:53, Jan Lahoda wrote:
>>>> On 12.10.2016 22:52, Robert Field wrote:
>>>>> Looks good.  Might be safest to copy the checks from the top of
>>>>> InputStream's implementation --
>>>>>
>>>>>      public int read(byte b[], int off, int len) throws IOException {
>>>>>          if (b == null) {
>>>>>              throw new NullPointerException();
>>>>>          } else if (off < 0 || len < 0 || len > b.length - off) {
>>>>>              throw new IndexOutOfBoundsException();
>>>>>          } else if (len == 0) {
>>>>>              return 0;
>>>>>          }
>>>>
>>>> Yes, makes sense.
>>>>
>>>>>
>>>>> I'm somewhat unclear on why the read/write in Util are changed to the
>>>>> buffered form.  BTW.  There isn't (and wasn't) an EOF test here.
>>>>
>>>> The reason is that (currently), when the user's snippet is waiting for
>>>> input and the user types Ctrl-C, the user's snippet is stopped, but
>>>> the read method returns -1 (see ConsoleIOContext.readUserInput())
>>>> (somewhat pretending stream end). So this change was to prevent
>>>> writing this -1 to the remote side.
>>>>
>>>> But, I was thinking how to improve that (and add/fix handling of EOF
>>>> as well, even though I guess it might be surprising if the user in is
>>>> closed). And we could do this:
>>>> -add a new exception, like StopException (similar to JLine's
>>>> UserInterruptException)
>>>> -the (user-)in.read() could throw the exception to signal the user
>>>> cancelled the input. execution.Util.remoteInputOutput would then take
>>>> care of cancelling the user's code, and would know to not pass any
>>>> data to the agent.
>>>>
>>>> What do you think?
>>>>
>>>> Thanks,
>>>>    Jan
>>>>
>>>>>
>>>>> As to input carrying over: I can see either as being surprising in
>>>>> some
>>>>> cases.  As-is, very simple "Enter two numbers: " kinds of newbie
>>>>> coding
>>>>> will misbehave, and misbehave in a way that could look like a hang
>>>>> (waiting on input).
>>>>> With a input carry-over implementation however, garbage entered,
>>>>> perhaps
>>>>> much earlier in the session would still be what is read later -- that
>>>>> could be hard to diagnose, and would take coding (or a /reset) to
>>>>> cure.
>>>>> I think addressing that should be a separate issue.
>>>>>
>>>>> -Robert
>>>>>
>>>>> On 10/12/16 12:41, Jan Lahoda wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167461
>>>>>>
>>>>>> The problem is that this sequence of snippets is not working properly
>>>>>> (won't read the System.in properly/seemingly hangs):
>>>>>> jshell> Scanner input = new Scanner(System.in);
>>>>>> jshell> int x = input.nextInt();
>>>>>>
>>>>>> The reason is that the PipeInputStream (which is used to pass data
>>>>>> received by the remote agent from the socket to System.in) does not
>>>>>> override the read(byte[], int, int) method. So the default
>>>>>> implementation will be used, which waits until all the requested data
>>>>>> are read. Scanner wrap s the System.in with InputStreamReader, and
>>>>>> that appears to read (up to) 8192 bytes into a buffer, but the user
>>>>>> typically does not type so many characters. The solution is to
>>>>>> override the read(byte[], int, int) method, and return only bytes we
>>>>>> have buffered (except the method will wait for the first byte).
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~jlahoda/8167461/webrev.00/
>>>>>>
>>>>>> Also, more general question related to the System.in handling: unused
>>>>>> input for one snippet is not passed to following snippets - is that
>>>>>> OK, or do we need to discuss changing that? I.e.:
>>>>>> jshell> int x = input.nextInt();
>>>>>> 1 1
>>>>>> x ==> 1
>>>>>> //the other "1" is thrown away
>>>>>>
>>>>>> jshell> int x = input.nextInt();
>>>>>> 2
>>>>>> x ==> 2
>>>>>> //the user had to type additional input.
>>>>>>
>>>>>> Thanks,
>>>>>>     Jan
>>>>>
>>>
>

From robert.field at oracle.com  Sun Oct 16 19:47:48 2016
From: robert.field at oracle.com (Robert Field)
Date: Sun, 16 Oct 2016 12:47:48 -0700
Subject: RFR JDK-8167461: jshell tool: Scanner#next() hangs tool
In-Reply-To: <5803C430.6040902@oracle.com>
References: <57FE91F7.2020605@oracle.com> <57FEA27C.7050101@oracle.com>
	<57FFD83D.9060804@oracle.com> <57FFE089.4080105@oracle.com>
	<5800DAB2.60104@oracle.com> <5800FF8E.2000602@oracle.com>
	<5803C430.6040902@oracle.com>
Message-ID: <5803D964.60306@oracle.com>


On 10/16/16 11:17, Jan Lahoda wrote:
> On 14.10.2016 17:53, Robert Field wrote:
>> Two things --
>>
>> (1) This behavior should be documented.
>
> Sure, updated webrev:
> http://cr.openjdk.java.net/~jlahoda/8167461/webrev.02/

Thumbs up.

>
>>
>> (2) We have "stop()" in the API, but with this, our reference
>> implementation does not use it.  Should it exist in the API?
>> "stop()" also exists in the SPI -- forwarded API -> EC -> remote EC.
>> This pathway would no longer be used by our reference implementation.
>> What does this mean about stop() in the SPI design?
>
> We still call the API version from the StopDetectingInputStream (via 
> the "stop" Runnable filled in the constructor of ConsoleIOContext).

OK

>
> Even if we didn't call the API, then I would still think the stop 
> method should be in the API, for cases where the client would like to 
> implement e.g. a watchdog.
>
> Introducing an alternative way to do the stop while waiting for input 
> is not perfect, but so far, I don't see a better solution. Any ideas?
>
> Thanks,
>     Jan

Thanks,
Robert

>
>>
>> -Robert
>>
>> On 10/14/16 06:16, Jan Lahoda wrote:
>>> Hi,
>>>
>>> Updated webrev is here:
>>> http://cr.openjdk.java.net/~jlahoda/8167461/webrev.01/
>>>
>>> In the end, I used InterruptedIOException instead of some newly
>>> created StopException, as it seems reasonably close to what we need.
>>>
>>> The userin data that are being sent from the engine to the remote
>>> agent are tagged now, and allow to send data, close the stream, and
>>> partially transfer exceptions (just the exception's message is
>>> transferred, not the stack trace).
>>>
>>> What do you think?
>>>
>>> Thanks,
>>>     Jan
>>>
>>> On 13.10.2016 21:29, Robert Field wrote:
>>>> Looking forward to it!
>>>>
>>>> -Robert
>>>>
>>>> On 10/13/16 11:53, Jan Lahoda wrote:
>>>>> On 12.10.2016 22:52, Robert Field wrote:
>>>>>> Looks good.  Might be safest to copy the checks from the top of
>>>>>> InputStream's implementation --
>>>>>>
>>>>>>      public int read(byte b[], int off, int len) throws 
>>>>>> IOException {
>>>>>>          if (b == null) {
>>>>>>              throw new NullPointerException();
>>>>>>          } else if (off < 0 || len < 0 || len > b.length - off) {
>>>>>>              throw new IndexOutOfBoundsException();
>>>>>>          } else if (len == 0) {
>>>>>>              return 0;
>>>>>>          }
>>>>>
>>>>> Yes, makes sense.
>>>>>
>>>>>>
>>>>>> I'm somewhat unclear on why the read/write in Util are changed to 
>>>>>> the
>>>>>> buffered form.  BTW.  There isn't (and wasn't) an EOF test here.
>>>>>
>>>>> The reason is that (currently), when the user's snippet is waiting 
>>>>> for
>>>>> input and the user types Ctrl-C, the user's snippet is stopped, but
>>>>> the read method returns -1 (see ConsoleIOContext.readUserInput())
>>>>> (somewhat pretending stream end). So this change was to prevent
>>>>> writing this -1 to the remote side.
>>>>>
>>>>> But, I was thinking how to improve that (and add/fix handling of EOF
>>>>> as well, even though I guess it might be surprising if the user in is
>>>>> closed). And we could do this:
>>>>> -add a new exception, like StopException (similar to JLine's
>>>>> UserInterruptException)
>>>>> -the (user-)in.read() could throw the exception to signal the user
>>>>> cancelled the input. execution.Util.remoteInputOutput would then take
>>>>> care of cancelling the user's code, and would know to not pass any
>>>>> data to the agent.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Thanks,
>>>>>    Jan
>>>>>
>>>>>>
>>>>>> As to input carrying over: I can see either as being surprising in
>>>>>> some
>>>>>> cases.  As-is, very simple "Enter two numbers: " kinds of newbie
>>>>>> coding
>>>>>> will misbehave, and misbehave in a way that could look like a hang
>>>>>> (waiting on input).
>>>>>> With a input carry-over implementation however, garbage entered,
>>>>>> perhaps
>>>>>> much earlier in the session would still be what is read later -- 
>>>>>> that
>>>>>> could be hard to diagnose, and would take coding (or a /reset) to
>>>>>> cure.
>>>>>> I think addressing that should be a separate issue.
>>>>>>
>>>>>> -Robert
>>>>>>
>>>>>> On 10/12/16 12:41, Jan Lahoda wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Bug:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167461
>>>>>>>
>>>>>>> The problem is that this sequence of snippets is not working 
>>>>>>> properly
>>>>>>> (won't read the System.in properly/seemingly hangs):
>>>>>>> jshell> Scanner input = new Scanner(System.in);
>>>>>>> jshell> int x = input.nextInt();
>>>>>>>
>>>>>>> The reason is that the PipeInputStream (which is used to pass data
>>>>>>> received by the remote agent from the socket to System.in) does not
>>>>>>> override the read(byte[], int, int) method. So the default
>>>>>>> implementation will be used, which waits until all the requested 
>>>>>>> data
>>>>>>> are read. Scanner wrap s the System.in with InputStreamReader, and
>>>>>>> that appears to read (up to) 8192 bytes into a buffer, but the user
>>>>>>> typically does not type so many characters. The solution is to
>>>>>>> override the read(byte[], int, int) method, and return only 
>>>>>>> bytes we
>>>>>>> have buffered (except the method will wait for the first byte).
>>>>>>>
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~jlahoda/8167461/webrev.00/
>>>>>>>
>>>>>>> Also, more general question related to the System.in handling: 
>>>>>>> unused
>>>>>>> input for one snippet is not passed to following snippets - is that
>>>>>>> OK, or do we need to discuss changing that? I.e.:
>>>>>>> jshell> int x = input.nextInt();
>>>>>>> 1 1
>>>>>>> x ==> 1
>>>>>>> //the other "1" is thrown away
>>>>>>>
>>>>>>> jshell> int x = input.nextInt();
>>>>>>> 2
>>>>>>> x ==> 2
>>>>>>> //the user had to type additional input.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>     Jan
>>>>>>
>>>>
>>


From bitterfoxc at gmail.com  Mon Oct 17 14:25:00 2016
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Mon, 17 Oct 2016 23:25:00 +0900
Subject: RFR 8145263: JShell API: Change the format of
	SourceCodeAnalysis#documentation
In-Reply-To: <5803DC5F.5040604@oracle.com>
References: <CAHjBcHOSbneONaCRjWStxCXYENvyoOxp5RuAStfnBp4-+wZJxw@mail.gmail.com>
	<566ED116.3080502@oracle.com>
	<CAHjBcHN3bMNw+xZ96EOXHNFYVMhT7PxX5PQDdjueE10N+7gg2w@mail.gmail.com>
	<56707E7E.4020704@oracle.com>
	<CAHjBcHMXDQHb-xVnpqG7yGa7Y5tzbUqzug-Y-+gPy0DrUND8nQ@mail.gmail.com>
	<57E979DC.2060007@oracle.com>
	<CAHjBcHOrmtYjiMQ=gPbEKYTTxLDJKT+b7cORPJDuzOXHgi4V1w@mail.gmail.com>
	<CAHjBcHPh3KWx6E+d=_noepg6qfb8Wzh4j1sEWNKf8SFZDWAHng@mail.gmail.com>
	<1577bb420e8.2765.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<57F2B9BD.30202@oracle.com>
	<CAHjBcHOZo-55TZHhnC8UkWpzxeHtvgkw_v9VwkSTSfra2i_Z6g@mail.gmail.com>
	<CAHjBcHMcocES2WH28nwszkMb09no9TKudxfom5BbnuWPt_F9ew@mail.gmail.com>
	<5803DC5F.5040604@oracle.com>
Message-ID: <CAHjBcHOgzwsUKvm=dZWeqPwqOK6rrhQ4+R_jn1cLjvPOa276eg@mail.gmail.com>

Hi Robert,
I've pushed:
http://hg.openjdk.java.net/jdk9/dev/langtools/rev/296c87505118

Thank you!
shinyafox(Shinya Yoshida)

2016-10-17 5:00 GMT+09:00 Robert Field <robert.field at oracle.com>:

> If we find the throws info too much, we can pull it later.
>
> I believe this change needs to be pushed before:
>     8131019: jshell tool: access javadoc from tool
> which now has the go-away.
>
> So, Shinya, yes, please push it
>
> Thanks!
>
> -Robert
>
>
>
> On 10/15/16 05:45, ShinyaYoshida wrote:
>
> resending...
>
> 2016-10-06 14:02 GMT+09:00 ShinyaYoshida <bitterfoxc at gmail.com>:
>
>> Hi Robert, Brian and Jan,
>> Thank you for your review and sorry for late reply.
>>
>> I think throws-clause is still necessary information even if javadoc is
>> implemented because some of methods doesn't provide javadoc, such as user
>> defined methods or methods in user loaded jars.
>> What do you think?
>> If you think it's still overkill, I'll drop it.
>>
>> Regards,
>> shinyafox(Shinya Yoshida)
>>
>>
>> 2016-10-04 5:04 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com>:
>>
>>> Looks OK to me too. I don't have a strong opinion on the throws clause.
>>>
>>> Jan
>>>
>>> On 30.9.2016 17:26, Robert Field wrote:
>>>
>>>> Nice!
>>>>
>>>> Includes a lot of touches to make it more readable and useful.
>>>>
>>>> Passing on one bit of feedback from Brian, put into my words: since we
>>>> are going to be adding full javadoc access, we want this signature
>>>> output crisp. So, the throws clause is probably overkill.
>>>>
>>>> Thanks,
>>>> Robert
>>>>
>>>> On September 30, 2016 4:04:03 AM ShinyaYoshida <bitterfoxc at gmail.com>
>>>> wrote:
>>>>
>>>> Hi Robert and Jan,
>>>>> I've updated the webrev to current code base:
>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.10/
>>>>>
>>>>> Could you review this?
>>>>>
>>>>> Regards,
>>>>> shinyafox(Shinya Yoshida)
>>>>>
>>>>>
>>>>> 2016-09-27 4:51 GMT+09:00 ShinyaYoshida <bitterfoxc at gmail.com
>>>>> <mailto:bitterfoxc at gmail.com>>:
>>>>>
>>>>>     Hi Robert,
>>>>>     Never mind! And I'm also sorry for having left this.
>>>>>
>>>>>     I'll try updating webrev to current code base until 1/Oct.
>>>>>
>>>>>     BTW, currently a lot of things in jshell are configurable, could
>>>>>     signature of documentation also be configurable in future(JDK10 or
>>>>>     9.1 or ...)?
>>>>>
>>>>>     Thank you,
>>>>>     shinyafox(Shinya Yoshida)
>>>>>
>>>>>     2016-09-26 12:41 GMT-07:00 Robert Field <robert.field at oracle.com
>>>>>     <mailto:robert.field at oracle.com>>:
>>>>>
>>>>>         In reviewing outstanding issues, we discovered this RFR which
>>>>>         was left hanging.
>>>>>
>>>>>         Our sincere apologies for dropping the ball on this.
>>>>>
>>>>>         We are juggling a lot, if we miss something like this in the
>>>>>         future, please let us know.
>>>>>
>>>>>         I have made some changes in the issue, please note them.  I
>>>>>         know there have been some underlying changes as well
>>>>>         (parameter names from source).
>>>>>
>>>>>         If you would be willing to update this RFR we will review
>>>>>         promptly.
>>>>>
>>>>>         Thank you and sorry,
>>>>>         Robert
>>>>>
>>>>>
>>>>>         On 12/15/15 17:07, ShinyaYoshida wrote:
>>>>>
>>>>>>         Hi Jan and Robert,
>>>>>>         Thank you.
>>>>>>
>>>>>>         I've filed:
>>>>>>         https://bugs.openjdk.java.net/browse/JDK-8145473
>>>>>>         <https://bugs.openjdk.java.net/browse/JDK-8145473>
>>>>>>
>>>>>>         Ok, I put the type parameters for the constructor before the
>>>>>>         traditional(current) form:
>>>>>>         http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.0
>>>>>> 1/ <http://cr.openjdk.java.net/%7Eshinyafox/kulla/8145263/webrev.01/>
>>>>>>
>>>>>>         Please review it again.
>>>>>>
>>>>>>         Regards,
>>>>>>         shinyafox(Shinya Yoshida)
>>>>>>
>>>>>>
>>>>>>         2015-12-16 5:56 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com
>>>>>>         <mailto:jan.lahoda at oracle.com>>:
>>>>>>
>>>>>>             Hi Shinya,
>>>>>>
>>>>>>             On 14.12.2015 15:40, ShinyaYoshida wrote:
>>>>>>
>>>>>>                 Hi Jan,
>>>>>>                 Thank you for your review.
>>>>>>
>>>>>>                 2015-12-14 23:24 GMT+09:00 Jan Lahoda
>>>>>>                 <jan.lahoda at oracle.com <mailto:jan.lahoda at oracle.com>
>>>>>>                 <mailto:jan.lahoda at oracle.com
>>>>>>
>>>>>>                 <mailto:jan.lahoda at oracle.com>>>:
>>>>>>
>>>>>>                     Hi Shinya,
>>>>>>
>>>>>>                     Generally, looks good, thanks for looking at
>>>>>>                 this! Two comments:
>>>>>>                     -for parameter names, I was hoping we could get
>>>>>>                 them from the
>>>>>>                     sources (if/when available), but we are not doing
>>>>>>                 that now, and
>>>>>>                     hiding synthetic parameter names makes sense to
>>>>>>                 me. So this is OK,
>>>>>>                     and if we at some point start to parse parameter
>>>>>>                 names from the
>>>>>>                     sources, we can tweak the code to do the right
>>>>>> thing.
>>>>>>
>>>>>>                 I think that there should be the issue for the
>>>>>>                 parameter names.
>>>>>>                 Do you have the issue for that?
>>>>>>
>>>>>>
>>>>>>             No issue for this yet.
>>>>>>
>>>>>>                 If not, should I create it?
>>>>>>
>>>>>>
>>>>>>             Sure, thanks.
>>>>>>
>>>>>>
>>>>>>
>>>>>>                     -not sure if marking constructors with ".new"
>>>>>>                     ("type-name.new(<parameters>)") will be clear -
>>>>>>                 do you think the
>>>>>>                     traditional form ("type-name(<parameters>)") is
>>>>>>                 unclear?
>>>>>>
>>>>>>
>>>>>>                 When I consider the constructor with the generics
>>>>>>                 like following, I
>>>>>>                 notice that the traditional(current) form is
>>>>>>                 difficult to represent it.
>>>>>>                 class C<T> { <U> C(U u) {} }
>>>>>>                 So I choose that format which is like the constructor
>>>>>>                 reference.
>>>>>>
>>>>>>
>>>>>>             I think generic constructors (i.e. constructors that
>>>>>>             themselves have type parameters) are very uncommon, so I
>>>>>>             wouldn't optimize for those. Having the format nice for
>>>>>>             usual constructors is more important, I think, even if
>>>>>>             the format for these uncommon constructors would be
>>>>>> uglier.
>>>>>>
>>>>>>             Thanks,
>>>>>>                 Jan
>>>>>>
>>>>>>
>>>>>>
>>>>>>                 Another possible representation is "new <Generics>
>>>>>>                 type-name<Generics>(<parameters>)" which is similar
>>>>>>                 to the invocation of
>>>>>>                 the constructor with generics.
>>>>>>
>>>>>>                 What do you think?
>>>>>>
>>>>>>                 Regards,
>>>>>>                 shinyafox(Shinya Yoshida)
>>>>>>
>>>>>>
>>>>>>                     Thanks,
>>>>>>                          Jan
>>>>>>
>>>>>>
>>>>>>                     On 13.12.2015 07:33, ShinyaYoshida wrote:
>>>>>>
>>>>>>                         Hi Jan and Robert,
>>>>>>                         I'd like to propose changing the format of
>>>>>>                         SourceCodeAnalysis#documentation.
>>>>>>
>>>>>>                         The detail of the change is on the issue
>>>>>> 8145263:
>>>>>>                 https://bugs.openjdk.java.net/browse/JDK-8145263
>>>>>>                 <https://bugs.openjdk.java.net/browse/JDK-8145263>
>>>>>>                         Please see it.
>>>>>>
>>>>>>                         You can see the more example in the test of
>>>>>>                 my patch.
>>>>>>
>>>>>>                         Patch is here:
>>>>>>                 http://cr.openjdk.java.net/~sh
>>>>>> inyafox/kulla/8145263/webrev.00/
>>>>>>                 <http://cr.openjdk.java.net/%7
>>>>>> Eshinyafox/kulla/8145263/webrev.00/>
>>>>>>
>>>>>>                         Please consider my proposal and review the
>>>>>> patch.
>>>>>>
>>>>>>                         Regards,
>>>>>>                         shinyafox(Shinya Yoshida)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>
>
>

From jan.lahoda at oracle.com  Mon Oct 17 16:08:00 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 17 Oct 2016 18:08:00 +0200
Subject: RFR 8131019: jshell tool: access javadoc from tool
Message-ID: <5804F760.5050509@oracle.com>

Hello,

This patch adds ability to show javadoc inside JShell (by showingg it on 
the second invocation of the Shift-<tab> documentation). In addition to 
jdk.jshell changes, there is a support in jdk.compiler, that is expected 
to be reused by jjs.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8131019

Webrev:
http://cr.openjdk.java.net/~jlahoda/8131019/webrev.00/

Any feedback is welcome!

Thanks,
     Jan

From robert.field at oracle.com  Tue Oct 18 20:34:23 2016
From: robert.field at oracle.com (Robert Field)
Date: Tue, 18 Oct 2016 13:34:23 -0700
Subject: RFR 8131019: jshell tool: access javadoc from tool
In-Reply-To: <5804F760.5050509@oracle.com>
References: <5804F760.5050509@oracle.com>
Message-ID: <5806874F.5080903@oracle.com>

One concern:

     142 jshell.console.see.javadoc = <invoke documentation again to see 
more documentation>

I think this may be confusing.  For seeing more with regular tab the 
existing prompt is this (and seems clear):

     141 jshell.console.see.more = <press tab to see more>

Also, you are adding:

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

Can we make the doc one:

     142 jshell.console.see.javadoc = <press shift-tab again to see javadoc>

otherwise looks good.

Thanks,
Robert

On 10/17/16 09:08, Jan Lahoda wrote:
> Hello,
>
> This patch adds ability to show javadoc inside JShell (by showingg it 
> on the second invocation of the Shift-<tab> documentation). In 
> addition to jdk.jshell changes, there is a support in jdk.compiler, 
> that is expected to be reused by jjs.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8131019
>
> Webrev:
> http://cr.openjdk.java.net/~jlahoda/8131019/webrev.00/
>
> Any feedback is welcome!
>
> Thanks,
>     Jan


From robert.field at oracle.com  Wed Oct 19 04:34:14 2016
From: robert.field at oracle.com (Robert Field)
Date: Tue, 18 Oct 2016 21:34:14 -0700
Subject: RFR 8163840 (v3): jshell tool: provide way to display configuration
	settings
Message-ID: <5806F7C6.70203@oracle.com>

Please review this change which allows all settings to be shown.
Revamped as discussed in the thread "JShell: showing and retaining 
settings" (copied into bug Description).

Bug:
     https://bugs.openjdk.java.net/browse/JDK-8163840

Webrev:
     http://cr.openjdk.java.net/~rfield/8163840v3.webrev/

Thanks,
Robert

From jan.lahoda at oracle.com  Wed Oct 19 12:53:04 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 19 Oct 2016 14:53:04 +0200
Subject: RFR 8131019: jshell tool: access javadoc from tool
In-Reply-To: <5806874F.5080903@oracle.com>
References: <5804F760.5050509@oracle.com> <5806874F.5080903@oracle.com>
Message-ID: <58076CB0.8010803@oracle.com>

Hi Robert,

Thanks for looking at this and for the comment.

On 18.10.2016 22:34, Robert Field wrote:
> One concern:
>
>      142 jshell.console.see.javadoc = <invoke documentation again to see
> more documentation>
>
> I think this may be confusing.  For seeing more with regular tab the
> existing prompt is this (and seems clear):
>
>      141 jshell.console.see.more = <press tab to see more>
>
> Also, you are adding:
>
>      143 jshell.console.no.javadoc = <no javadoc found>
>
> Can we make the doc one:
>
>      142 jshell.console.see.javadoc = <press shift-tab again to see
> javadoc>

I used a more general "documentation", as the same text may be used for 
expanding command documentation (like: "/list <shift-tab>"). Maybe we 
want two different texts? I.e.

jshell.console.see.javadoc = <press shift-tab again to see javadoc>

for javadoc, and:

jshell.console.see.help = <press shift-tab again to see detailed help>

for the command documentation?

Thanks,
    Jan

>
> otherwise looks good.
>
> Thanks,
> Robert
>
> On 10/17/16 09:08, Jan Lahoda wrote:
>> Hello,
>>
>> This patch adds ability to show javadoc inside JShell (by showingg it
>> on the second invocation of the Shift-<tab> documentation). In
>> addition to jdk.jshell changes, there is a support in jdk.compiler,
>> that is expected to be reused by jjs.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8131019
>>
>> Webrev:
>> http://cr.openjdk.java.net/~jlahoda/8131019/webrev.00/
>>
>> Any feedback is welcome!
>>
>> Thanks,
>>     Jan
>

From robert.field at oracle.com  Wed Oct 19 13:07:48 2016
From: robert.field at oracle.com (Robert Field)
Date: Wed, 19 Oct 2016 06:07:48 -0700
Subject: RFR 8131019: jshell tool: access javadoc from tool
In-Reply-To: <58076CB0.8010803@oracle.com>
References: <5804F760.5050509@oracle.com> <5806874F.5080903@oracle.com>
	<58076CB0.8010803@oracle.com>
Message-ID: <157dd0e0ca0.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>

Sounds good.

Robert




On October 19, 2016 5:53:07 AM Jan Lahoda <jan.lahoda at oracle.com> wrote:

> Hi Robert,
>
> Thanks for looking at this and for the comment.
>
> On 18.10.2016 22:34, Robert Field wrote:
>> One concern:
>>
>>      142 jshell.console.see.javadoc = <invoke documentation again to see
>> more documentation>
>>
>> I think this may be confusing.  For seeing more with regular tab the
>> existing prompt is this (and seems clear):
>>
>>      141 jshell.console.see.more = <press tab to see more>
>>
>> Also, you are adding:
>>
>>      143 jshell.console.no.javadoc = <no javadoc found>
>>
>> Can we make the doc one:
>>
>>      142 jshell.console.see.javadoc = <press shift-tab again to see
>> javadoc>
>
> I used a more general "documentation", as the same text may be used for
> expanding command documentation (like: "/list <shift-tab>"). Maybe we
> want two different texts? I.e.
>
> jshell.console.see.javadoc = <press shift-tab again to see javadoc>
>
> for javadoc, and:
>
> jshell.console.see.help = <press shift-tab again to see detailed help>
>
> for the command documentation?
>
> Thanks,
>     Jan
>
>>
>> otherwise looks good.
>>
>> Thanks,
>> Robert
>>
>> On 10/17/16 09:08, Jan Lahoda wrote:
>>> Hello,
>>>
>>> This patch adds ability to show javadoc inside JShell (by showingg it
>>> on the second invocation of the Shift-<tab> documentation). In
>>> addition to jdk.jshell changes, there is a support in jdk.compiler,
>>> that is expected to be reused by jjs.
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8131019
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~jlahoda/8131019/webrev.00/
>>>
>>> Any feedback is welcome!
>>>
>>> Thanks,
>>>     Jan
>>



From michael.mueller at mueller-bruehl.de  Wed Oct 19 13:45:49 2016
From: michael.mueller at mueller-bruehl.de (=?UTF-8?Q?Michael_M=c3=bcller?=)
Date: Wed, 19 Oct 2016 15:45:49 +0200
Subject: JShell /-n command
In-Reply-To: <01f7650c-140f-292f-7560-042e2cfe1a82@oracle.com>
References: <mailman.36168.1476247488.23828.kulla-dev@openjdk.java.net>
	<5A596307-1965-4B2D-AB48-F99D177D24B3@deitel.com>
	<29EEDF78-3E33-4B31-818D-F8EDA68421B7@deitel.com>
	<57FEA7E7.1040206@oracle.com>
	<01f7650c-140f-292f-7560-042e2cfe1a82@oracle.com>
Message-ID: <c2f404b2-ace0-5437-d1de-6b5f0de04fac@mueller-bruehl.de>

Hi,


Is this feature removed [ :( ] or will it be kept [ :-) ]?


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 und (parallel) Streams" Deutsche Ausgabe: 
https://leanpub.com/lambdas-de
"Java Lambdas and (parallel) Streams" English edition: 
https://leanpub.com/lambdas

On 10/13/2016 07:04 PM, Brian Goetz wrote:
> This is derived from a feature from Unix shells, which I use all the 
> time; frequently you have a sequence of "do this, then do that, then 
> do the other thing", and doing "-n" repeatedly handles that sequence.  
> Easier than "hit up arrow five times, return, repeat".
>
> On 10/12/2016 5:15 PM, Robert Field wrote:
>> I agree this isn't useful and is confusing -- for another reason too 
>> -- from /help:
>>
>> | /<id> -- re-run snippet by id
>> | /-<n> -- re-run n-th previous snippet
>>
>> So /3 refers to a snippet-id and /-3 refers to a count backwards.
>>
>> I've never used the /-n form.  For one, the up-arrow is much more 
>> convenient.
>>
>> Unless I hear an strong advocate, I will remove.
>>
>> Thanks,
>> Robert
>>
>> On 10/12/16 09:55, Paul Deitel wrote:
>>> Is the command
>>>
>>>     /-n
>>>
>>> actually useful? Chances are, if you have any decent number of 
>>> snippets, you will not recall more than the last few you typed.
>>>
>>> You can already execute the last valid snippet with /!.
>>>
>>> For anything else, you?d probably have to do a /list to see what 
>>> valid snippets you have. At that point, rather than doing /-n, you?d 
>>> just use /<id> to execute a given snippet.
>>>
>>> One point of emphasis in many JShell presentation has been how it?s 
>>> useful for beginners. I?ve been teaching beginning programmers for 
>>> 25+ years. A beginner seeing options like this will only get confused.
>>>
>>> I recommend removing /-n as an option.
>>>
>>> Paul
>>>
>>> Paul J. Deitel, CEO
>>> Deitel & Associates, Inc.
>>> Oracle Java Champion
>>> Microsoft Visual C# MVP 2012-2014
>>>
>>> http://www.deitel.com
>>> 978-443-2423
>>>
>>> Facebook: http://facebook.com/DeitelFan
>>> Twitter: @deitel
>>> LinkedIn: http://www.linkedin.com/company/deitel-&-associates
>>> YouTube: http://youtube.com/DeitelTV
>>> Instagram: http://instagram.com/DeitelFan
>>> Google+: http://google.com/+DeitelFan
>>>
>>> Newsletter: http://www.deitel.com/newsletter/subscribe.html
>>>
>>> On-Site Worldwide Corporate Training: http://www.deitel.com/training/
>>> Purchase our most recent books: http://amzn.to/18BLG2I
>>> Resource Centers: http://www.deitel.com/ResourceCenters.html
>>>
>>>
>>>
>>>
>>
>
>


From robert.field at oracle.com  Wed Oct 19 17:05:27 2016
From: robert.field at oracle.com (Robert Field)
Date: Wed, 19 Oct 2016 10:05:27 -0700
Subject: JShell /-n command
In-Reply-To: <c2f404b2-ace0-5437-d1de-6b5f0de04fac@mueller-bruehl.de>
References: <mailman.36168.1476247488.23828.kulla-dev@openjdk.java.net>
	<5A596307-1965-4B2D-AB48-F99D177D24B3@deitel.com>
	<29EEDF78-3E33-4B31-818D-F8EDA68421B7@deitel.com>
	<57FEA7E7.1040206@oracle.com>
	<01f7650c-140f-292f-7560-042e2cfe1a82@oracle.com>
	<c2f404b2-ace0-5437-d1de-6b5f0de04fac@mueller-bruehl.de>
Message-ID: <157dde79bf0.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>

Michael, Brian's argument and your +1 were convincing.  It is staying.
-Robert

P.S. I'll have to try that -- in bash and jshell



On October 19, 2016 6:46:00 AM Michael M?ller 
<michael.mueller at mueller-bruehl.de> wrote:

> Hi,
>
>
> Is this feature removed [ :( ] or will it be kept [ :-) ]?
>
>
> 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 und (parallel) Streams" Deutsche Ausgabe:
> https://leanpub.com/lambdas-de
> "Java Lambdas and (parallel) Streams" English edition:
> https://leanpub.com/lambdas
>
> On 10/13/2016 07:04 PM, Brian Goetz wrote:
>> This is derived from a feature from Unix shells, which I use all the
>> time; frequently you have a sequence of "do this, then do that, then
>> do the other thing", and doing "-n" repeatedly handles that sequence.
>> Easier than "hit up arrow five times, return, repeat".
>>
>> On 10/12/2016 5:15 PM, Robert Field wrote:
>>> I agree this isn't useful and is confusing -- for another reason too
>>> -- from /help:
>>>
>>> | /<id> -- re-run snippet by id
>>> | /-<n> -- re-run n-th previous snippet
>>>
>>> So /3 refers to a snippet-id and /-3 refers to a count backwards.
>>>
>>> I've never used the /-n form.  For one, the up-arrow is much more
>>> convenient.
>>>
>>> Unless I hear an strong advocate, I will remove.
>>>
>>> Thanks,
>>> Robert
>>>
>>> On 10/12/16 09:55, Paul Deitel wrote:
>>>> Is the command
>>>>
>>>>     /-n
>>>>
>>>> actually useful? Chances are, if you have any decent number of
>>>> snippets, you will not recall more than the last few you typed.
>>>>
>>>> You can already execute the last valid snippet with /!.
>>>>
>>>> For anything else, you?d probably have to do a /list to see what
>>>> valid snippets you have. At that point, rather than doing /-n, you?d
>>>> just use /<id> to execute a given snippet.
>>>>
>>>> One point of emphasis in many JShell presentation has been how it?s
>>>> useful for beginners. I?ve been teaching beginning programmers for
>>>> 25+ years. A beginner seeing options like this will only get confused.
>>>>
>>>> I recommend removing /-n as an option.
>>>>
>>>> Paul
>>>>
>>>> Paul J. Deitel, CEO
>>>> Deitel & Associates, Inc.
>>>> Oracle Java Champion
>>>> Microsoft Visual C# MVP 2012-2014
>>>>
>>>> http://www.deitel.com
>>>> 978-443-2423
>>>>
>>>> Facebook: http://facebook.com/DeitelFan
>>>> Twitter: @deitel
>>>> LinkedIn: http://www.linkedin.com/company/deitel-&-associates
>>>> YouTube: http://youtube.com/DeitelTV
>>>> Instagram: http://instagram.com/DeitelFan
>>>> Google+: http://google.com/+DeitelFan
>>>>
>>>> Newsletter: http://www.deitel.com/newsletter/subscribe.html
>>>>
>>>> On-Site Worldwide Corporate Training: http://www.deitel.com/training/
>>>> Purchase our most recent books: http://amzn.to/18BLG2I
>>>> Resource Centers: http://www.deitel.com/ResourceCenters.html
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>



From jan.lahoda at oracle.com  Wed Oct 19 19:14:30 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 19 Oct 2016 21:14:30 +0200
Subject: RFR 8163840 (v3): jshell tool: provide way to display
	configuration settings
In-Reply-To: <5806F7C6.70203@oracle.com>
References: <5806F7C6.70203@oracle.com>
Message-ID: <5807C616.4080208@oracle.com>

In Feedback.java, there is:
  816                         .map(v -> v.name().toLowerCase())

This is going to cause problems on the Turkish locale, where "I" will 
get converted to "?" instead of "i". Suggest to use toLowerCase(Locale.US).

Otherwise, seems OK to me.

Jan

On 19.10.2016 06:34, Robert Field wrote:
> Please review this change which allows all settings to be shown.
> Revamped as discussed in the thread "JShell: showing and retaining
> settings" (copied into bug Description).
>
> Bug:
>      https://bugs.openjdk.java.net/browse/JDK-8163840
>
> Webrev:
>      http://cr.openjdk.java.net/~rfield/8163840v3.webrev/
>
> Thanks,
> Robert

From robert.field at oracle.com  Fri Oct 21 07:14:08 2016
From: robert.field at oracle.com (Robert Field)
Date: Fri, 21 Oct 2016 00:14:08 -0700
Subject: RFR 8167637: jshell tool: /edit should use EDITOR setting
Message-ID: <5809C040.80408@oracle.com>

Please review --

Bugs:

     8167637: jshell tool: /edit should use EDITOR setting
     https://bugs.openjdk.java.net/browse/JDK-8167637

     8167640: jshell tool: external editor temp file should be *.java
     https://bugs.openjdk.java.net/browse/JDK-8167640

Webrev:

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

Thanks,
Robert


From robert.field at oracle.com  Sat Oct 22 00:19:32 2016
From: robert.field at oracle.com (Robert Field)
Date: Fri, 21 Oct 2016 17:19:32 -0700
Subject: RFR 8166649: jshell tool: missing --add-modules and --module-path
Message-ID: <580AB094.30105@oracle.com>

Please review....

Bugs:

     8166649: jshell tool: missing --add-modules and --module-path
     https://bugs.openjdk.java.net/browse/JDK-8166649

     8167462: jshell tool: /help /reload is wrong about re-executing 
commands
     https://bugs.openjdk.java.net/browse/JDK-8167462

Webrev:

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

New command-line options:

     --module-path <path>  Specify where to find application modules
     --add-modules <module>(,<module>)*
                           Specify modules to resolve, or all modules on the
                            module path if <module> is ALL-MODULE-PATHs

Thanks,
Robert


From robert.field at oracle.com  Sun Oct 23 04:14:33 2016
From: robert.field at oracle.com (Robert Field)
Date: Sat, 22 Oct 2016 21:14:33 -0700
Subject: RFR 8167636: jshell tool: Edit Pad should be in its own module
Message-ID: <580C3929.5030108@oracle.com>

Remove the dependency of the jshell tool on the java.desktop module.
Uses modules and ServiceLoader so that Edit Pad is optional -- that is, 
a jlink'ed image can be produced without Edit Pad and without java.desktop

Bug:
     https://bugs.openjdk.java.net/browse/JDK-8167636

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

Thanks,
Robert


From robert.field at oracle.com  Sun Oct 23 06:52:28 2016
From: robert.field at oracle.com (Robert Field)
Date: Sat, 22 Oct 2016 23:52:28 -0700
Subject: RFR 8167636: jshell tool: Edit Pad should be in its own module
In-Reply-To: <580C3929.5030108@oracle.com>
References: <580C3929.5030108@oracle.com>
Message-ID: <580C5E2C.9000706@oracle.com>

Note: jdk.internal.le and thus the jshell tool's ConsoleIOContext have a 
dependency on java.awt.event.ActionListener.
The former uses reflection to quietly ignore when it isn't present -- at 
a loss of functionality (functionality we use).
This code has a hack until I can discuss with Jan what the options are.
Ideally jdk.internal.le can lose it's dependency; Otherwise, I will 
change ConsoleIOContext to use reflection, which will mean a loss of 
shift-tab and shortcut+* functionality when java.desktop is not in the 
image.

-Robert


On 10/22/16 21:14, Robert Field wrote:
> Remove the dependency of the jshell tool on the java.desktop module.
> Uses modules and ServiceLoader so that Edit Pad is optional -- that 
> is, a jlink'ed image can be produced without Edit Pad and without 
> java.desktop
>
> Bug:
>     https://bugs.openjdk.java.net/browse/JDK-8167636
>
> Webrev:
>     http://cr.openjdk.java.net/~rfield/8167636v0.webrev/
>
> Thanks,
> Robert
>


From forax at univ-mlv.fr  Sun Oct 23 07:47:02 2016
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 23 Oct 2016 09:47:02 +0200 (CEST)
Subject: RFR 8167636: jshell tool: Edit Pad should be in its own module
In-Reply-To: <580C5E2C.9000706@oracle.com>
References: <580C3929.5030108@oracle.com> <580C5E2C.9000706@oracle.com>
Message-ID: <888700430.533086.1477208822872.JavaMail.zimbra@u-pem.fr>

Hi Robert,
in ConsoleIOContext, the private bind() can take a Consumer (or a Runnable) as second parameter so you don't need to use a special functional interface for that (ActionListener).

BuildInEditorProvider should be an interface, the only reason to not use an interface as a module service is backward compatibility.

In jdk.shell module, i don't know why you restrict the access to jdk.internal.jshell.editpad. If someone want it's own editor, why not letting him to implement BuildInEditorProvider.

EditPane do not need to be a JFrame (i.e. inherits from a JFrame), you can create a plain old JFrame in run().
Also the CountDownLatch::countDown can be shield behind a Runnable so only EditPadProvider knows that it uses a CountDownLatch, the EditPane will only call the Runnable.

cheers,
R?mi

----- Mail original -----
> De: "Robert Field" <robert.field at oracle.com>
> ?: "Kulla" <kulla-dev at openjdk.java.net>
> Envoy?: Dimanche 23 Octobre 2016 08:52:28
> Objet: Re: RFR 8167636: jshell tool: Edit Pad should be in its own module

> Note: jdk.internal.le and thus the jshell tool's ConsoleIOContext have a
> dependency on java.awt.event.ActionListener.
> The former uses reflection to quietly ignore when it isn't present -- at
> a loss of functionality (functionality we use).
> This code has a hack until I can discuss with Jan what the options are.
> Ideally jdk.internal.le can lose it's dependency; Otherwise, I will
> change ConsoleIOContext to use reflection, which will mean a loss of
> shift-tab and shortcut+* functionality when java.desktop is not in the
> image.
> 
> -Robert
> 
> 
> On 10/22/16 21:14, Robert Field wrote:
>> Remove the dependency of the jshell tool on the java.desktop module.
>> Uses modules and ServiceLoader so that Edit Pad is optional -- that
>> is, a jlink'ed image can be produced without Edit Pad and without
>> java.desktop
>>
>> Bug:
>>     https://bugs.openjdk.java.net/browse/JDK-8167636
>>
>> Webrev:
>>     http://cr.openjdk.java.net/~rfield/8167636v0.webrev/
>>
>> Thanks,
>> Robert

From robert.field at oracle.com  Sun Oct 23 13:42:41 2016
From: robert.field at oracle.com (Robert Field)
Date: Sun, 23 Oct 2016 06:42:41 -0700
Subject: RFR 8167636: jshell tool: Edit Pad should be in its own module
In-Reply-To: <580C5E2C.9000706@oracle.com>
References: <580C3929.5030108@oracle.com> <580C5E2C.9000706@oracle.com>
Message-ID: <580CBE51.9080701@oracle.com>

New version --

Both runtime-time and compile-time dependency on ActionListener (and 
thus java.desktop) removed from ConsoleIOContext.
All key sequences work on jlinked image without desktop.

Webrev:
     http://cr.openjdk.java.net/~rfield/8167636v1.webrev/

-Robert

On 10/22/16 23:52, Robert Field wrote:
> Note: jdk.internal.le and thus the jshell tool's ConsoleIOContext have 
> a dependency on java.awt.event.ActionListener.
> The former uses reflection to quietly ignore when it isn't present -- 
> at a loss of functionality (functionality we use).
> This code has a hack until I can discuss with Jan what the options are.
> Ideally jdk.internal.le can lose it's dependency; Otherwise, I will 
> change ConsoleIOContext to use reflection, which will mean a loss of 
> shift-tab and shortcut+* functionality when java.desktop is not in the 
> image.
>
> -Robert
>
>
> On 10/22/16 21:14, Robert Field wrote:
>> Remove the dependency of the jshell tool on the java.desktop module.
>> Uses modules and ServiceLoader so that Edit Pad is optional -- that 
>> is, a jlink'ed image can be produced without Edit Pad and without 
>> java.desktop
>>
>> Bug:
>>     https://bugs.openjdk.java.net/browse/JDK-8167636
>>
>> Webrev:
>>     http://cr.openjdk.java.net/~rfield/8167636v0.webrev/
>>
>> Thanks,
>> Robert
>>
>


From robert.field at oracle.com  Sun Oct 23 13:57:18 2016
From: robert.field at oracle.com (Robert Field)
Date: Sun, 23 Oct 2016 06:57:18 -0700
Subject: RFR 8167636: jshell tool: Edit Pad should be in its own module
In-Reply-To: <888700430.533086.1477208822872.JavaMail.zimbra@u-pem.fr>
References: <580C3929.5030108@oracle.com> <580C5E2C.9000706@oracle.com>
	<888700430.533086.1477208822872.JavaMail.zimbra@u-pem.fr>
Message-ID: <580CC1BE.9010606@oracle.com>

Hi R?mi,

On 10/23/16 00:47, Remi Forax wrote:
> Hi Robert,
> in ConsoleIOContext, the private bind() can take a Consumer (or a Runnable) as second parameter so you don't need to use a special functional interface for that (ActionListener).

Saw your response after I fixed the ConsoleIOContext dependencies-- 
including adding support for Consumer (which isn't in our version of 
JLine) and then noticing Runnable ;-)

>
> BuildInEditorProvider should be an interface, the only reason to not use an interface as a module service is backward compatibility.

OK.
All the examples I saw used abstract classes, so I assumed there was 
some reason.

>
> In jdk.shell module, i don't know why you restrict the access to jdk.internal.jshell.editpad. If someone want it's own editor, why not letting him to implement BuildInEditorProvider.

Allowing alternative implementations of the built-in editor is certainly 
a reasonable thing -- though, probably the external editor choice is 
much easier -- the built-in editor doesn't, at this time, really add 
anything that an external editor doesn't, except that it is built-in.  I 
didn't want to bake what the interface to it would be at this time.

>
> EditPane do not need to be a JFrame (i.e. inherits from a JFrame), you can create a plain old JFrame in run().
> Also the CountDownLatch::countDown can be shield behind a Runnable so only EditPadProvider knows that it uses a CountDownLatch, the EditPane will only call the Runnable.

Will look at that.

Thanks much for the comments!

-Robert

>
> cheers,
> R?mi
>
> ----- Mail original -----
>> De: "Robert Field" <robert.field at oracle.com>
>> ?: "Kulla" <kulla-dev at openjdk.java.net>
>> Envoy?: Dimanche 23 Octobre 2016 08:52:28
>> Objet: Re: RFR 8167636: jshell tool: Edit Pad should be in its own module
>> Note: jdk.internal.le and thus the jshell tool's ConsoleIOContext have a
>> dependency on java.awt.event.ActionListener.
>> The former uses reflection to quietly ignore when it isn't present -- at
>> a loss of functionality (functionality we use).
>> This code has a hack until I can discuss with Jan what the options are.
>> Ideally jdk.internal.le can lose it's dependency; Otherwise, I will
>> change ConsoleIOContext to use reflection, which will mean a loss of
>> shift-tab and shortcut+* functionality when java.desktop is not in the
>> image.
>>
>> -Robert
>>
>>
>> On 10/22/16 21:14, Robert Field wrote:
>>> Remove the dependency of the jshell tool on the java.desktop module.
>>> Uses modules and ServiceLoader so that Edit Pad is optional -- that
>>> is, a jlink'ed image can be produced without Edit Pad and without
>>> java.desktop
>>>
>>> Bug:
>>>      https://bugs.openjdk.java.net/browse/JDK-8167636
>>>
>>> Webrev:
>>>      http://cr.openjdk.java.net/~rfield/8167636v0.webrev/
>>>
>>> Thanks,
>>> Robert


From jan.lahoda at oracle.com  Sun Oct 23 17:58:13 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Sun, 23 Oct 2016 19:58:13 +0200
Subject: RFR 8167637: jshell tool: /edit should use EDITOR setting
In-Reply-To: <5809C040.80408@oracle.com>
References: <5809C040.80408@oracle.com>
Message-ID: <580CFA35.3000602@oracle.com>

Overall, seems OK to me. It seems there is a missing
setEditorEnvSubtest();
call at the end of (after the last block of setEnvVar in):
ToolCommandOptionTest.java#setEditorEnvTest

Jan

On 21.10.2016 09:14, Robert Field wrote:
> Please review --
>
> Bugs:
>
>      8167637: jshell tool: /edit should use EDITOR setting
>      https://bugs.openjdk.java.net/browse/JDK-8167637
>
>      8167640: jshell tool: external editor temp file should be *.java
>      https://bugs.openjdk.java.net/browse/JDK-8167640
>
> Webrev:
>
>      http://cr.openjdk.java.net/~rfield/8167637v0.webrev/
>
> Thanks,
> Robert
>

From jan.lahoda at oracle.com  Sun Oct 23 18:30:51 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Sun, 23 Oct 2016 20:30:51 +0200
Subject: RFR 8166649: jshell tool: missing --add-modules and --module-path
In-Reply-To: <580AB094.30105@oracle.com>
References: <580AB094.30105@oracle.com>
Message-ID: <580D01DB.8060808@oracle.com>

Seems OK to me.

Jan

On 22.10.2016 02:19, Robert Field wrote:
> Please review....
>
> Bugs:
>
>      8166649: jshell tool: missing --add-modules and --module-path
>      https://bugs.openjdk.java.net/browse/JDK-8166649
>
>      8167462: jshell tool: /help /reload is wrong about re-executing
> commands
>      https://bugs.openjdk.java.net/browse/JDK-8167462
>
> Webrev:
>
>      http://cr.openjdk.java.net/~rfield/8166649v0.webrev/
>
> New command-line options:
>
>      --module-path <path>  Specify where to find application modules
>      --add-modules <module>(,<module>)*
>                            Specify modules to resolve, or all modules on
> the
>                             module path if <module> is ALL-MODULE-PATHs
>
> Thanks,
> Robert
>

From robert.field at oracle.com  Tue Oct 25 00:07:04 2016
From: robert.field at oracle.com (Robert Field)
Date: Mon, 24 Oct 2016 17:07:04 -0700
Subject: RFR 8167637: jshell tool: /edit should use EDITOR setting
In-Reply-To: <580CFA35.3000602@oracle.com>
References: <5809C040.80408@oracle.com> <580CFA35.3000602@oracle.com>
Message-ID: <580EA228.2000206@oracle.com>


On 10/23/16 10:58, Jan Lahoda wrote:
> Overall, seems OK to me. It seems there is a missing
> setEditorEnvSubtest();
> call at the end of (after the last block of setEnvVar in):
> ToolCommandOptionTest.java#setEditorEnvTest

Sure enough.  The last set-up wasn't getting tested.  Fixed.

Pushed.

Thanks,
Robert

>
> Jan
>
> On 21.10.2016 09:14, Robert Field wrote:
>> Please review --
>>
>> Bugs:
>>
>>      8167637: jshell tool: /edit should use EDITOR setting
>>      https://bugs.openjdk.java.net/browse/JDK-8167637
>>
>>      8167640: jshell tool: external editor temp file should be *.java
>>      https://bugs.openjdk.java.net/browse/JDK-8167640
>>
>> Webrev:
>>
>>      http://cr.openjdk.java.net/~rfield/8167637v0.webrev/
>>
>> Thanks,
>> Robert
>>


From jonathan.gibbons at oracle.com  Wed Oct 26 02:48:34 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 25 Oct 2016 19:48:34 -0700
Subject: RFR 8131019: jshell tool: access javadoc from tool
In-Reply-To: <5804F760.5050509@oracle.com>
References: <5804F760.5050509@oracle.com>
Message-ID: <58101982.6050006@oracle.com>



On 10/17/2016 09:08 AM, Jan Lahoda wrote:
> Hello,
>
> This patch adds ability to show javadoc inside JShell (by showingg it 
> on the second invocation of the Shift-<tab> documentation). In 
> addition to jdk.jshell changes, there is a support in jdk.compiler, 
> that is expected to be reused by jjs.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8131019
>
> Webrev:
> http://cr.openjdk.java.net/~jlahoda/8131019/webrev.00/
>
> Any feedback is welcome!
>
> Thanks,
>     Jan

The file 
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javadocformatter.properties
doesn't seem like it belongs in com/sun/tools/javac/resources.

It would be nice to provide and use String constants for the ANSI escape 
sequences.

JavadocFormatter.java:113 -- ex.printStackTrace seems suspect, 
especially as there seems
to be better infrastructure for handling unwanted exceptions elsewhere 
in JShell.

JavadocFormatter.java:183 -- no distinguished handling for type parameters

JavadocFormatter.java:240 -- is it safe to assume lower case tags at 
this point?  If it helps,
you could leverage com.sun.tools.doclint.HtmlTag

JavadocFormatter.java:356 -- (general comment) what about invalid HTML 
input.
Yes, JDK javadoc comments are reasonably good these days, but that 
doesn't apply
everywhere.

JavadocFormatter.java:333 -- no explicit handling for </p>

JavadocFormatter.java:444 -- suggest moving resource file
Just curious, why the CAP prefix?

JavaDocFormatter.java:visitEndElement: it is common to see optional end 
tags omitted, like
     </li>, </td>, </tr>
     This could screw up the stacks. If </tr> is omitted, won't you skip 
printing the row?

JavadocFormatter.java:409
     Ignoring </td>, </th> will mean that vertical whitespace between 
table cell elements
     may be incorporated into the table cell itself, won't it?  I guess 
in general, it'll all be
     collapsed into a space character, so in general you'll be OK

JavadocFormatter.java
     No support for entities, including &lt; &gt; &amp;

JavadocHelper.java
     I haven't figured out how the {@inheritDoc} resolver is working, 
insofar as how are you
     working with the issue that you have to create a new JavacTask for 
each tree that you
     parse, which means separate distinct components like Names, Symtab, 
and all the other
     javac internal classes. In particular, when you start computing 
supertypes, how do
     you coordinate the different elements provided by the different 
JavacTask objects?

-- Jon

From robert.field at oracle.com  Wed Oct 26 03:21:59 2016
From: robert.field at oracle.com (Robert Field)
Date: Tue, 25 Oct 2016 20:21:59 -0700
Subject: RFR 8167643 JShell: silently ignore access modifiers (as semantically
	irrelevant)
Message-ID: <58102157.6090509@oracle.com>

Please review...

See bug for back-story:

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

Webrev:

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

Thanks,
Robert


From jan.lahoda at oracle.com  Wed Oct 26 17:35:03 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 26 Oct 2016 19:35:03 +0200
Subject: RFR 8131019: jshell tool: access javadoc from tool
In-Reply-To: <58101982.6050006@oracle.com>
References: <5804F760.5050509@oracle.com> <58101982.6050006@oracle.com>
Message-ID: <5810E947.9060403@oracle.com>

Thanks for all the comments so far. An updated webrev reflecting the 
comments is here:
http://cr.openjdk.java.net/~jlahoda/8131019/webrev.01/

Also needs this change to the top-level repository:
http://cr.openjdk.java.net/~jlahoda/8131019/toplevel.01/

Summary of changes:
-the text adjustment suggested by Robert
-the output is paginated, and pauses after methods (if another method 
follows)
-most of the comments below have been addressed (some more comments 
inlined).

On 26.10.2016 04:48, Jonathan Gibbons wrote:
>
>
> On 10/17/2016 09:08 AM, Jan Lahoda wrote:
>> Hello,
>>
>> This patch adds ability to show javadoc inside JShell (by showingg it
>> on the second invocation of the Shift-<tab> documentation). In
>> addition to jdk.jshell changes, there is a support in jdk.compiler,
>> that is expected to be reused by jjs.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8131019
>>
>> Webrev:
>> http://cr.openjdk.java.net/~jlahoda/8131019/webrev.00/
>>
>> Any feedback is welcome!
>>
>> Thanks,
>>     Jan
>
> The file
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javadocformatter.properties
>
> doesn't seem like it belongs in com/sun/tools/javac/resources.

Moved to:
src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/resources/javadocformatter.properties

>
> It would be nice to provide and use String constants for the ANSI escape
> sequences.

Using constants now.

>
> JavadocFormatter.java:113 -- ex.printStackTrace seems suspect,
> especially as there seems
> to be better infrastructure for handling unwanted exceptions elsewhere
> in JShell.

Should not normally happen, I think, so I changed that to throw 
InternalError.

>
> JavadocFormatter.java:183 -- no distinguished handling for type parameters

Fixed.

>
> JavadocFormatter.java:240 -- is it safe to assume lower case tags at
> this point?  If it helps,
> you could leverage com.sun.tools.doclint.HtmlTag

Using HtmlTag now.

>
> JavadocFormatter.java:356 -- (general comment) what about invalid HTML
> input.
> Yes, JDK javadoc comments are reasonably good these days, but that
> doesn't apply
> everywhere.

I tried to fix the formatter so that it does not crash on broken HTML. 
The output may not be ideal, though.

>
> JavadocFormatter.java:333 -- no explicit handling for </p>

Is it necessary to handle the closing tag?

>
> JavadocFormatter.java:444 -- suggest moving resource file
> Just curious, why the CAP prefix?

That's for "caption".

>
> JavaDocFormatter.java:visitEndElement: it is common to see optional end
> tags omitted, like
>      </li>, </td>, </tr>
>      This could screw up the stacks. If </tr> is omitted, won't you skip
> printing the row?

I've tried to fix the "tr" problem. Added tests for missing closing "td" 
(there were existing tests for missing closing "li").

>
> JavadocFormatter.java:409
>      Ignoring </td>, </th> will mean that vertical whitespace between
> table cell elements
>      may be incorporated into the table cell itself, won't it?  I guess
> in general, it'll all be
>      collapsed into a space character, so in general you'll be OK

I tried to clear out the whitespaces so that these should get eliminated 
(but they would probably not be a big deal).

>
> JavadocFormatter.java
>      No support for entities, including &lt; &gt; &amp;

Done.

>
> JavadocHelper.java
>      I haven't figured out how the {@inheritDoc} resolver is working,
> insofar as how are you
>      working with the issue that you have to create a new JavacTask for
> each tree that you
>      parse, which means separate distinct components like Names, Symtab,
> and all the other
>      javac internal classes. In particular, when you start computing
> supertypes, how do
>      you coordinate the different elements provided by the different
> JavacTask objects?

Mapping from the original JavacTask to the new one is done using a 
"handle" (the "elementSignature" will produce a textual representation 
of an Element which is found in the newly parsed source). The resulting 
javadoc is a plain text (with @inheritDoc resolved).

Any feedback is welcome.

Thanks!

Jan


>
> -- Jon

From jonathan.gibbons at oracle.com  Thu Oct 27 02:51:40 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 26 Oct 2016 19:51:40 -0700
Subject: RFR 8131019: jshell tool: access javadoc from tool
In-Reply-To: <5810E947.9060403@oracle.com>
References: <5804F760.5050509@oracle.com> <58101982.6050006@oracle.com>
	<5810E947.9060403@oracle.com>
Message-ID: <58116BBC.4090300@oracle.com>

Looks OK to me.

-- Jon

On 10/26/2016 10:35 AM, Jan Lahoda wrote:
> Thanks for all the comments so far. An updated webrev reflecting the 
> comments is here:
> http://cr.openjdk.java.net/~jlahoda/8131019/webrev.01/
>
> Also needs this change to the top-level repository:
> http://cr.openjdk.java.net/~jlahoda/8131019/toplevel.01/
>
> Summary of changes:
> -the text adjustment suggested by Robert
> -the output is paginated, and pauses after methods (if another method 
> follows)
> -most of the comments below have been addressed (some more comments 
> inlined).
>
> On 26.10.2016 04:48, Jonathan Gibbons wrote:
>>
>>
>> On 10/17/2016 09:08 AM, Jan Lahoda wrote:
>>> Hello,
>>>
>>> This patch adds ability to show javadoc inside JShell (by showingg it
>>> on the second invocation of the Shift-<tab> documentation). In
>>> addition to jdk.jshell changes, there is a support in jdk.compiler,
>>> that is expected to be reused by jjs.
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8131019
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~jlahoda/8131019/webrev.00/
>>>
>>> Any feedback is welcome!
>>>
>>> Thanks,
>>>     Jan
>>
>> The file
>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javadocformatter.properties 
>>
>>
>> doesn't seem like it belongs in com/sun/tools/javac/resources.
>
> Moved to:
> src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/resources/javadocformatter.properties 
>
>
>>
>> It would be nice to provide and use String constants for the ANSI escape
>> sequences.
>
> Using constants now.
>
>>
>> JavadocFormatter.java:113 -- ex.printStackTrace seems suspect,
>> especially as there seems
>> to be better infrastructure for handling unwanted exceptions elsewhere
>> in JShell.
>
> Should not normally happen, I think, so I changed that to throw 
> InternalError.
>
>>
>> JavadocFormatter.java:183 -- no distinguished handling for type 
>> parameters
>
> Fixed.
>
>>
>> JavadocFormatter.java:240 -- is it safe to assume lower case tags at
>> this point?  If it helps,
>> you could leverage com.sun.tools.doclint.HtmlTag
>
> Using HtmlTag now.
>
>>
>> JavadocFormatter.java:356 -- (general comment) what about invalid HTML
>> input.
>> Yes, JDK javadoc comments are reasonably good these days, but that
>> doesn't apply
>> everywhere.
>
> I tried to fix the formatter so that it does not crash on broken HTML. 
> The output may not be ideal, though.
>
>>
>> JavadocFormatter.java:333 -- no explicit handling for </p>
>
> Is it necessary to handle the closing tag?
>
>>
>> JavadocFormatter.java:444 -- suggest moving resource file
>> Just curious, why the CAP prefix?
>
> That's for "caption".
>
>>
>> JavaDocFormatter.java:visitEndElement: it is common to see optional end
>> tags omitted, like
>>      </li>, </td>, </tr>
>>      This could screw up the stacks. If </tr> is omitted, won't you skip
>> printing the row?
>
> I've tried to fix the "tr" problem. Added tests for missing closing 
> "td" (there were existing tests for missing closing "li").
>
>>
>> JavadocFormatter.java:409
>>      Ignoring </td>, </th> will mean that vertical whitespace between
>> table cell elements
>>      may be incorporated into the table cell itself, won't it? I guess
>> in general, it'll all be
>>      collapsed into a space character, so in general you'll be OK
>
> I tried to clear out the whitespaces so that these should get 
> eliminated (but they would probably not be a big deal).
>
>>
>> JavadocFormatter.java
>>      No support for entities, including &lt; &gt; &amp;
>
> Done.
>
>>
>> JavadocHelper.java
>>      I haven't figured out how the {@inheritDoc} resolver is working,
>> insofar as how are you
>>      working with the issue that you have to create a new JavacTask for
>> each tree that you
>>      parse, which means separate distinct components like Names, Symtab,
>> and all the other
>>      javac internal classes. In particular, when you start computing
>> supertypes, how do
>>      you coordinate the different elements provided by the different
>> JavacTask objects?
>
> Mapping from the original JavacTask to the new one is done using a 
> "handle" (the "elementSignature" will produce a textual representation 
> of an Element which is found in the newly parsed source). The 
> resulting javadoc is a plain text (with @inheritDoc resolved).
>
> Any feedback is welcome.
>
> Thanks!
>
> Jan
>
>
>>
>> -- Jon


From jan.lahoda at oracle.com  Thu Oct 27 14:39:21 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 27 Oct 2016 16:39:21 +0200
Subject: RFR 8131019: jshell tool: access javadoc from tool
In-Reply-To: <58116BBC.4090300@oracle.com>
References: <5804F760.5050509@oracle.com> <58101982.6050006@oracle.com>
	<5810E947.9060403@oracle.com> <58116BBC.4090300@oracle.com>
Message-ID: <58121199.1090609@oracle.com>

A slightly updated patch:
http://cr.openjdk.java.net/~jlahoda/8131019/webrev.02/

Changes:
-support for modularized src.zip (SourceCodeAnalysisImpl)
-<img> handling ("alt" attribute is printed), as suggested
-handling for <dl>, <dt> and <dd>

How does this look?

Thanks,
     Jan

On 27.10.2016 04:51, Jonathan Gibbons wrote:
> Looks OK to me.
>
> -- Jon
>
> On 10/26/2016 10:35 AM, Jan Lahoda wrote:
>> Thanks for all the comments so far. An updated webrev reflecting the
>> comments is here:
>> http://cr.openjdk.java.net/~jlahoda/8131019/webrev.01/
>>
>> Also needs this change to the top-level repository:
>> http://cr.openjdk.java.net/~jlahoda/8131019/toplevel.01/
>>
>> Summary of changes:
>> -the text adjustment suggested by Robert
>> -the output is paginated, and pauses after methods (if another method
>> follows)
>> -most of the comments below have been addressed (some more comments
>> inlined).
>>
>> On 26.10.2016 04:48, Jonathan Gibbons wrote:
>>>
>>>
>>> On 10/17/2016 09:08 AM, Jan Lahoda wrote:
>>>> Hello,
>>>>
>>>> This patch adds ability to show javadoc inside JShell (by showingg it
>>>> on the second invocation of the Shift-<tab> documentation). In
>>>> addition to jdk.jshell changes, there is a support in jdk.compiler,
>>>> that is expected to be reused by jjs.
>>>>
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8131019
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~jlahoda/8131019/webrev.00/
>>>>
>>>> Any feedback is welcome!
>>>>
>>>> Thanks,
>>>>     Jan
>>>
>>> The file
>>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javadocformatter.properties
>>>
>>>
>>> doesn't seem like it belongs in com/sun/tools/javac/resources.
>>
>> Moved to:
>> src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/resources/javadocformatter.properties
>>
>>
>>>
>>> It would be nice to provide and use String constants for the ANSI escape
>>> sequences.
>>
>> Using constants now.
>>
>>>
>>> JavadocFormatter.java:113 -- ex.printStackTrace seems suspect,
>>> especially as there seems
>>> to be better infrastructure for handling unwanted exceptions elsewhere
>>> in JShell.
>>
>> Should not normally happen, I think, so I changed that to throw
>> InternalError.
>>
>>>
>>> JavadocFormatter.java:183 -- no distinguished handling for type
>>> parameters
>>
>> Fixed.
>>
>>>
>>> JavadocFormatter.java:240 -- is it safe to assume lower case tags at
>>> this point?  If it helps,
>>> you could leverage com.sun.tools.doclint.HtmlTag
>>
>> Using HtmlTag now.
>>
>>>
>>> JavadocFormatter.java:356 -- (general comment) what about invalid HTML
>>> input.
>>> Yes, JDK javadoc comments are reasonably good these days, but that
>>> doesn't apply
>>> everywhere.
>>
>> I tried to fix the formatter so that it does not crash on broken HTML.
>> The output may not be ideal, though.
>>
>>>
>>> JavadocFormatter.java:333 -- no explicit handling for </p>
>>
>> Is it necessary to handle the closing tag?
>>
>>>
>>> JavadocFormatter.java:444 -- suggest moving resource file
>>> Just curious, why the CAP prefix?
>>
>> That's for "caption".
>>
>>>
>>> JavaDocFormatter.java:visitEndElement: it is common to see optional end
>>> tags omitted, like
>>>      </li>, </td>, </tr>
>>>      This could screw up the stacks. If </tr> is omitted, won't you skip
>>> printing the row?
>>
>> I've tried to fix the "tr" problem. Added tests for missing closing
>> "td" (there were existing tests for missing closing "li").
>>
>>>
>>> JavadocFormatter.java:409
>>>      Ignoring </td>, </th> will mean that vertical whitespace between
>>> table cell elements
>>>      may be incorporated into the table cell itself, won't it? I guess
>>> in general, it'll all be
>>>      collapsed into a space character, so in general you'll be OK
>>
>> I tried to clear out the whitespaces so that these should get
>> eliminated (but they would probably not be a big deal).
>>
>>>
>>> JavadocFormatter.java
>>>      No support for entities, including &lt; &gt; &amp;
>>
>> Done.
>>
>>>
>>> JavadocHelper.java
>>>      I haven't figured out how the {@inheritDoc} resolver is working,
>>> insofar as how are you
>>>      working with the issue that you have to create a new JavacTask for
>>> each tree that you
>>>      parse, which means separate distinct components like Names, Symtab,
>>> and all the other
>>>      javac internal classes. In particular, when you start computing
>>> supertypes, how do
>>>      you coordinate the different elements provided by the different
>>> JavacTask objects?
>>
>> Mapping from the original JavacTask to the new one is done using a
>> "handle" (the "elementSignature" will produce a textual representation
>> of an Element which is found in the newly parsed source). The
>> resulting javadoc is a plain text (with @inheritDoc resolved).
>>
>> Any feedback is welcome.
>>
>> Thanks!
>>
>> Jan
>>
>>
>>>
>>> -- Jon
>

From robert.field at oracle.com  Thu Oct 27 17:31:10 2016
From: robert.field at oracle.com (Robert Field)
Date: Thu, 27 Oct 2016 10:31:10 -0700
Subject: RFR 8131019: jshell tool: access javadoc from tool
In-Reply-To: <58121199.1090609@oracle.com>
References: <5804F760.5050509@oracle.com> <58101982.6050006@oracle.com>
	<5810E947.9060403@oracle.com> <58116BBC.4090300@oracle.com>
	<58121199.1090609@oracle.com>
Message-ID: <15807320360.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>

Thumbs up!


On October 27, 2016 7:39:33 AM Jan Lahoda <jan.lahoda at oracle.com> wrote:

> A slightly updated patch:
> http://cr.openjdk.java.net/~jlahoda/8131019/webrev.02/
>
> Changes:
> -support for modularized src.zip (SourceCodeAnalysisImpl)
> -<img> handling ("alt" attribute is printed), as suggested
> -handling for <dl>, <dt> and <dd>
>
> How does this look?
>
> Thanks,
>      Jan
>
> On 27.10.2016 04:51, Jonathan Gibbons wrote:
>> Looks OK to me.
>>
>> -- Jon
>>
>> On 10/26/2016 10:35 AM, Jan Lahoda wrote:
>>> Thanks for all the comments so far. An updated webrev reflecting the
>>> comments is here:
>>> http://cr.openjdk.java.net/~jlahoda/8131019/webrev.01/
>>>
>>> Also needs this change to the top-level repository:
>>> http://cr.openjdk.java.net/~jlahoda/8131019/toplevel.01/
>>>
>>> Summary of changes:
>>> -the text adjustment suggested by Robert
>>> -the output is paginated, and pauses after methods (if another method
>>> follows)
>>> -most of the comments below have been addressed (some more comments
>>> inlined).
>>>
>>> On 26.10.2016 04:48, Jonathan Gibbons wrote:
>>>>
>>>>
>>>> On 10/17/2016 09:08 AM, Jan Lahoda wrote:
>>>>> Hello,
>>>>>
>>>>> This patch adds ability to show javadoc inside JShell (by showingg it
>>>>> on the second invocation of the Shift-<tab> documentation). In
>>>>> addition to jdk.jshell changes, there is a support in jdk.compiler,
>>>>> that is expected to be reused by jjs.
>>>>>
>>>>> Bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8131019
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~jlahoda/8131019/webrev.00/
>>>>>
>>>>> Any feedback is welcome!
>>>>>
>>>>> Thanks,
>>>>>     Jan
>>>>
>>>> The file
>>>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javadocformatter.properties
>>>>
>>>>
>>>> doesn't seem like it belongs in com/sun/tools/javac/resources.
>>>
>>> Moved to:
>>> src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/resources/javadocformatter.properties
>>>
>>>
>>>>
>>>> It would be nice to provide and use String constants for the ANSI escape
>>>> sequences.
>>>
>>> Using constants now.
>>>
>>>>
>>>> JavadocFormatter.java:113 -- ex.printStackTrace seems suspect,
>>>> especially as there seems
>>>> to be better infrastructure for handling unwanted exceptions elsewhere
>>>> in JShell.
>>>
>>> Should not normally happen, I think, so I changed that to throw
>>> InternalError.
>>>
>>>>
>>>> JavadocFormatter.java:183 -- no distinguished handling for type
>>>> parameters
>>>
>>> Fixed.
>>>
>>>>
>>>> JavadocFormatter.java:240 -- is it safe to assume lower case tags at
>>>> this point?  If it helps,
>>>> you could leverage com.sun.tools.doclint.HtmlTag
>>>
>>> Using HtmlTag now.
>>>
>>>>
>>>> JavadocFormatter.java:356 -- (general comment) what about invalid HTML
>>>> input.
>>>> Yes, JDK javadoc comments are reasonably good these days, but that
>>>> doesn't apply
>>>> everywhere.
>>>
>>> I tried to fix the formatter so that it does not crash on broken HTML.
>>> The output may not be ideal, though.
>>>
>>>>
>>>> JavadocFormatter.java:333 -- no explicit handling for </p>
>>>
>>> Is it necessary to handle the closing tag?
>>>
>>>>
>>>> JavadocFormatter.java:444 -- suggest moving resource file
>>>> Just curious, why the CAP prefix?
>>>
>>> That's for "caption".
>>>
>>>>
>>>> JavaDocFormatter.java:visitEndElement: it is common to see optional end
>>>> tags omitted, like
>>>>      </li>, </td>, </tr>
>>>>      This could screw up the stacks. If </tr> is omitted, won't you skip
>>>> printing the row?
>>>
>>> I've tried to fix the "tr" problem. Added tests for missing closing
>>> "td" (there were existing tests for missing closing "li").
>>>
>>>>
>>>> JavadocFormatter.java:409
>>>>      Ignoring </td>, </th> will mean that vertical whitespace between
>>>> table cell elements
>>>>      may be incorporated into the table cell itself, won't it? I guess
>>>> in general, it'll all be
>>>>      collapsed into a space character, so in general you'll be OK
>>>
>>> I tried to clear out the whitespaces so that these should get
>>> eliminated (but they would probably not be a big deal).
>>>
>>>>
>>>> JavadocFormatter.java
>>>>      No support for entities, including &lt; &gt; &amp;
>>>
>>> Done.
>>>
>>>>
>>>> JavadocHelper.java
>>>>      I haven't figured out how the {@inheritDoc} resolver is working,
>>>> insofar as how are you
>>>>      working with the issue that you have to create a new JavacTask for
>>>> each tree that you
>>>>      parse, which means separate distinct components like Names, Symtab,
>>>> and all the other
>>>>      javac internal classes. In particular, when you start computing
>>>> supertypes, how do
>>>>      you coordinate the different elements provided by the different
>>>> JavacTask objects?
>>>
>>> Mapping from the original JavacTask to the new one is done using a
>>> "handle" (the "elementSignature" will produce a textual representation
>>> of an Element which is found in the newly parsed source). The
>>> resulting javadoc is a plain text (with @inheritDoc resolved).
>>>
>>> Any feedback is welcome.
>>>
>>> Thanks!
>>>
>>> Jan
>>>
>>>
>>>>
>>>> -- Jon
>>



From jan.lahoda at oracle.com  Thu Oct 27 20:25:12 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 27 Oct 2016 22:25:12 +0200
Subject: RFR 8167643 JShell: silently ignore access modifiers (as
	semantically irrelevant)
In-Reply-To: <58102157.6090509@oracle.com>
References: <58102157.6090509@oracle.com>
Message-ID: <581262A8.5080902@oracle.com>

Seems OK to me.

Jan

On 26.10.2016 05:21, Robert Field wrote:
> Please review...
>
> See bug for back-story:
>
>      https://bugs.openjdk.java.net/browse/JDK-8167643
>
> Webrev:
>
>      http://cr.openjdk.java.net/~rfield/8167643v0.webrev/
>
> Thanks,
> Robert
>

From robert.field at oracle.com  Fri Oct 28 03:32:37 2016
From: robert.field at oracle.com (Robert Field)
Date: Thu, 27 Oct 2016 20:32:37 -0700
Subject: RFR 8161969, 8166637, 8154513, 8167552: jshell tool: ... truncation, 
	welcome, /reload help
Message-ID: <5812C6D5.2040901@oracle.com>

Please review the fix to these four bugs:

Bugs:

     8161969: jshell tool: /var value is not truncated per feedback setting
     https://bugs.openjdk.java.net/browse/JDK-8161969

     8166637: jshell tool: confusing truncation of long result values
     https://bugs.openjdk.java.net/browse/JDK-8166637

     8154513: JShell tool: welcome message should match feedback mode
     https://bugs.openjdk.java.net/browse/JDK-8154513

     8167552: jshell tool: Typo in jshell command '/? /reload' description
     https://bugs.openjdk.java.net/browse/JDK-8167552

Webrev:

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

Thanks,
Robert