From robert.field at oracle.com  Fri Dec  2 07:48:48 2016
From: robert.field at oracle.com (Robert Field)
Date: Thu, 01 Dec 2016 23:48:48 -0800
Subject: RFR 8168615: JShell API: jdk.jshell.spi should be a pluggable
	ServiceLoader SPI
Message-ID: <58412760.3080500@oracle.com>

Please review...

Bug:

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


Webrev:

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

Thanks,
Robert


From jan.lahoda at oracle.com  Fri Dec  2 09:48:21 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 2 Dec 2016 10:48:21 +0100
Subject: RFR (s) 8167185: JShell API: Exported elements referring to
	inaccessible types in jdk.jshell
In-Reply-To: <583CB490.1050307@oracle.com>
References: <583CB490.1050307@oracle.com>
Message-ID: <58414365.8090403@oracle.com>

Seems OK.

Jan

On 28.11.2016 23:49, Robert Field wrote:
> Please review....
>
> Bugs:
>
>      8167185: JShell API: Exported elements referring to inaccessible
> types in jdk.jshell
>      https://bugs.openjdk.java.net/browse/JDK-8167185
>
> Sub-Task:
>
>      8170406: JShell (jdk): remove exports exclusion from -Xlint for
> jdk.jshell
>      https://bugs.openjdk.java.net/browse/JDK-8170406
>
> Webrevs:
>
>      http://cr.openjdk.java.net/~rfield/8167185v0.webrev/
>
>      http://cr.openjdk.java.net/~rfield/8170406v0.webrev/
>
> Thanks,
> Robert
>

From jan.lahoda at oracle.com  Fri Dec  2 13:54:00 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 2 Dec 2016 14:54:00 +0100
Subject: RFR JDK-8165564: langtools\test\jdk\jshell\CommandCompletionTest.java
	fails on some windows
Message-ID: <58417CF8.6040009@oracle.com>

Hi,

It seems the completion and the tests sometimes don't agree on valid 
default FileSystem roots. This patch fixes that.

Bug: https://bugs.openjdk.java.net/browse/JDK-8165564
Webrev: http://cr.openjdk.java.net/~jlahoda/8165564/webrev.00/

Any feedback is welcome!

Thanks,
     Jan

From robert.field at oracle.com  Sat Dec  3 01:46:06 2016
From: robert.field at oracle.com (Robert Field)
Date: Fri, 02 Dec 2016 17:46:06 -0800
Subject: RFR 8168615: JShell API: jdk.jshell.spi should be a pluggable
	ServiceLoader SPI
In-Reply-To: <58412760.3080500@oracle.com>
References: <58412760.3080500@oracle.com>
Message-ID: <584223DE.4060706@oracle.com>

Updated webrev:

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

Only change is two additional tests that test using user execution 
engines via ServiceLoader look-up of their modules.
Thanks, Jan, module infrastructure help!

     ExecutionControlSpecTest.java
     FailOverDirectExecutionControlTest.java

Robert

On 12/01/16 23:48, Robert Field wrote:
> Please review...
>
> Bug:
>
>      https://bugs.openjdk.java.net/browse/JDK-8168615
>
>
> Webrev:
>
>     http://cr.openjdk.java.net/~rfield/8168615v0.webrev/
>
> Thanks,
> Robert
>


From robert.field at oracle.com  Mon Dec  5 16:15:23 2016
From: robert.field at oracle.com (Robert Field)
Date: Mon, 05 Dec 2016 08:15:23 -0800
Subject: RFR JDK-8165564:
	langtools\test\jdk\jshell\CommandCompletionTest.java
	fails on some windows
In-Reply-To: <58417CF8.6040009@oracle.com>
References: <58417CF8.6040009@oracle.com>
Message-ID: <5845929B.6070507@oracle.com>

Makes sense.
Thumbs up.

-Robert

On 12/02/16 05:54, Jan Lahoda wrote:
> Hi,
>
> It seems the completion and the tests sometimes don't agree on valid 
> default FileSystem roots. This patch fixes that.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8165564
> Webrev: http://cr.openjdk.java.net/~jlahoda/8165564/webrev.00/
>
> Any feedback is welcome!
>
> Thanks,
>     Jan


From jan.lahoda at oracle.com  Tue Dec  6 18:14:47 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 6 Dec 2016 19:14:47 +0100
Subject: RFR 8168615: JShell API: jdk.jshell.spi should be a pluggable
	ServiceLoader SPI
In-Reply-To: <58412760.3080500@oracle.com>
References: <58412760.3080500@oracle.com>
Message-ID: <58470017.1080806@oracle.com>

A few comments:
-the -X help will (in my understanding) produce this:
+\    --execution <spec>                 Specify an alternate execution 
engine.\n\
+\                                        Where <spec> is an 
ExecutionControldProvider spec.\n\
+\                                        See jdk.jshell.spi\n\

As this is a user-level help (although a very experienced user, 
presumably), it would be better I think to provide some details - e.g. 
the grammar for the spec; known provider; and ideally, parameters of the 
known providers

-I would reorganize the rules in the spec grammar to go from the top down:
+     * spec := name : params
+     *       | name
+     * name := id
+     * params := param , params
+     *        | param
+     *        |
+     * param := id ( value )

(might be also good to say what is "id")

-ExecutionControlProvider.logMessages seems weird. Is it used outside of 
tests?

-after this patch, both the ExecutionControls and their Providers are 
public - is that desirable? Is there a usecase for the client to 
call/instantiate the Providers directly without going through the 
ServiceLoader?

Jan

On 2.12.2016 08:48, Robert Field wrote:
> Please review...
>
> Bug:
>
>       https://bugs.openjdk.java.net/browse/JDK-8168615
>
>
> Webrev:
>
>      http://cr.openjdk.java.net/~rfield/8168615v0.webrev/
>
> Thanks,
> Robert
>

From robert.field at oracle.com  Wed Dec  7 05:08:58 2016
From: robert.field at oracle.com (Robert Field)
Date: Tue, 06 Dec 2016 21:08:58 -0800
Subject: RFR 8168615: JShell API: jdk.jshell.spi should be a pluggable
	ServiceLoader SPI
In-Reply-To: <58470017.1080806@oracle.com>
References: <58412760.3080500@oracle.com> <58470017.1080806@oracle.com>
Message-ID: <5847996A.7080005@oracle.com>

Thanks for the review, Jan.

See responses inline.

On 12/06/16 10:14, Jan Lahoda wrote:
> A few comments:
> -the -X help will (in my understanding) produce this:
> +\    --execution <spec>                 Specify an alternate 
> execution engine.\n\
> +\                                        Where <spec> is an 
> ExecutionControldProvider spec.\n\
> +\                                        See jdk.jshell.spi\n\
>
> As this is a user-level help (although a very experienced user, 
> presumably), it would be better I think to provide some details - e.g. 
> the grammar for the spec; known provider; and ideally, parameters of 
> the known providers

OK, so better doc references are in order.  I think including the 
grammar and explanatory information is probably too bulky for 
command-line help.  But I've clarified this help as follows (the 
formatting is right if fix-width, but formatted text cannot be sent to 
this list):

          % jshell -X
              --add-exports <module>/<package>   Export specified 
module-private package to snippets
              --execution <spec>                 Specify an alternate 
execution engine.
                                                   Where <spec> is an 
ExecutionControl spec.
                                                   See the documentation 
of the package
                                                   jdk.jshell.spi for 
the syntax of the spec

          These options are non-standard and subject to change without 
notice.

Where the jdk.jshell.spi javadocs are now:

http://cr.openjdk.java.net/~rfield/8168615v1.jshellAPI/jdk/jshell/spi/package-summary.html

It is OK that they would need to reference the SPI docs because if they 
implemented an execution engine they would have implemented these 
interfaces,  If they are just tweaking parameters (and this isn't 
something we want a typical user to do) they would need to be familiar 
with the parameters, which are described in these docs.


>
> -I would reorganize the rules in the spec grammar to go from the top 
> down:
> +     * spec := name : params
> +     *       | name
> +     * name := id
> +     * params := param , params
> +     *        | param
> +     *        |
> +     * param := id ( value )
>
> (might be also good to say what is "id")

Both good ideas implemented in the above.

>
> -ExecutionControlProvider.logMessages seems weird. Is it used outside 
> of tests?

Not currently, but we really need logging of failures and failover to 
track-down rare intermittent issues.  Adding logging is out of scope for 
9, but this gives a needed hook.

>
> -after this patch, both the ExecutionControls and their Providers are 
> public - is that desirable? Is there a usecase for the client to 
> call/instantiate the Providers directly without going through the 
> ServiceLoader?

The ExecutionControls were public before.  jdk.jshell.execution contains 
the default execution engines, but it is exposed because it is a library 
of classes for implementing ExecutionControl (and now 
ExecutionControlProvider).

The SPI and the jdk.jshell.execution library were created because of a 
request from an IDE developer.

OK, here is the new version.  No executable code was changed, but I've 
spruced-up the documentation, including what is mentioned above.

The docs:

     http://cr.openjdk.java.net/~rfield/8168615v1.jshellAPI/

Specdiff:

http://cr.openjdk.java.net/~rfield/8168615v1.specdiff/overview-summary.html

New webrev:

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

-Robert

>
> Jan
>
> On 2.12.2016 08:48, Robert Field wrote:
>> Please review...
>>
>> Bug:
>>
>>       https://bugs.openjdk.java.net/browse/JDK-8168615
>>
>>
>> Webrev:
>>
>>      http://cr.openjdk.java.net/~rfield/8168615v0.webrev/
>>
>> Thanks,
>> Robert
>>


From jonathan.gibbons at oracle.com  Thu Dec  8 02:50:28 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 07 Dec 2016 18:50:28 -0800
Subject: RFR 8170162: jshell tool: no mechanism to programmatically launch
In-Reply-To: <583A0A5B.6050100@oracle.com>
References: <583A0A5B.6050100@oracle.com>
Message-ID: <5848CA74.3070405@oracle.com>

Many of the new files in the langtools webrev do not have the correct, 
required, legal header. This is a MUST-FIX,

In the new package-info file, this comment is a little bit hokey and/or 
out of place.

   52  * Note: The Java&trade; shell tool is built on the {@link jdk.jshell} API,
   53  * but the tool is at a different level, and this launching SPI does not
   54  * interact with the {@link jdk.jshell} API.

At a minimum, I suggest making it an @apiNote, but I would recommend 
trying to rethink/reconsider
what you are trying to say here.

I think you should figure a way and place to specify the non-null name 
used by the standard implementation
of the JShellToolProvider. That being said ....

I guess I'm surprised you need to define a JShellToolProvider PAI -- do 
you expect there to be multiple
implementations of JShell on any system?   Why not just have
     static JShellToolProvider.instance()
to return an instance of the one true jshell implementation?

-- Jon


On 11/26/2016 02:19 PM, Robert Field wrote:
> Goldilocks and the three launching mechanisms...
>
> She lay down in the first bed, but it was too hard.
>     java.util.spi.ToolProvider (8169821) has a severe impedance 
> mismatch: the use of Writers, no InputStream, and no flexibility.
>
> Then she lay in the second bed, but it was too soft.
>     javax.tools.ToolProvider (8170044) would require significant 
> changes that are not possible at this time, it is limited, and is old 
> mechanism.
>
> Then she lay down in the third bed and it was just right. Goldilocks 
> fell asleep.
>     jdk.jshell.tool (8170162) provides a matching, clean, and 
> configurable launching mechanism
>
> Please review...
>
> Bug:
>
>     8170162: jshell tool: no mechanism to programmatically launch
>     https://bugs.openjdk.java.net/browse/JDK-8170162
>
> Sub-Tasks (tiny tweaks to other repos):
>
>     8170194: jshell tool (jdk repo): launch tool from JShellToolProvider
>     https://bugs.openjdk.java.net/browse/JDK-8170194
>
>     8170195: jshell tool (make): update javadoc generation for jdk.jshell
>     https://bugs.openjdk.java.net/browse/JDK-8170195
>
> Webrevs:
>
>     http://cr.openjdk.java.net/~rfield/8170162v0.webrev/
>
>     http://cr.openjdk.java.net/~rfield/8170194v0.webrev/
>
>     http://cr.openjdk.java.net/~rfield/8170195v0.webrev/
>
> API:
>
>     http://cr.openjdk.java.net/~rfield/8170162v0.jshellAPI/
>
> SpecDiff:
>
> http://cr.openjdk.java.net/~rfield/8170162v0.specdiff/overview-summary.html 
>
>
> Thanks,
> Robert
>


From robert.field at oracle.com  Thu Dec  8 04:26:55 2016
From: robert.field at oracle.com (Robert Field)
Date: Wed, 07 Dec 2016 20:26:55 -0800
Subject: RFR 8170162: jshell tool: no mechanism to programmatically launch
In-Reply-To: <5848CA74.3070405@oracle.com>
References: <583A0A5B.6050100@oracle.com> <5848CA74.3070405@oracle.com>
Message-ID: <5848E10F.8000108@oracle.com>

Thank you for the review, Jon!

Responses in-line below.

On 12/07/16 18:50, Jonathan Gibbons wrote:
> Many of the new files in the langtools webrev do not have the correct, 
> required, legal header. This is a MUST-FIX,

Oops!!

>
> In the new package-info file, this comment is a little bit hokey 
> and/or out of place.
>
>   52  * Note: The Java&trade; shell tool is built on the {@link 
> jdk.jshell} API,
>   53  * but the tool is at a different level, and this launching SPI 
> does not
>   54  * interact with the {@link jdk.jshell} API.

Not sure what is hokey, but the additional documentation I added to 
overview,html clarifies the relationship between the layers more clearly 
and is more appropriately placed than this, so, I will remove.
BTW: Seems I should dump overview.html, putting that in module-info.java?

>
> At a minimum, I suggest making it an @apiNote, but I would recommend 
> trying to rethink/reconsider
> what you are trying to say here.
>
> I think you should figure a way and place to specify the non-null name 
> used by the standard implementation
> of the JShellToolProvider. That being said ....

"The name of the standard implementation is 'jshell'" ???
In jdk.jshell.tool.JavaShellToolProvider.name()

>
> I guess I'm surprised you need to define a JShellToolProvider PAI -- 
> do you expect there to be multiple
> implementations of JShell on any system?

Maybe not.  But who knows, we already have an external fork..
I suppose we could have experimental versions in incubator modules...
I could also imagine a future with the jshell tool implementation broken 
into a separate module and slimmed-down runtime images built.

>   Why not just have
>     static JShellToolProvider.instance()
> to return an instance of the one true jshell implementation?

Certainly an option (depending on the above).  Though the difference in 
interface is:

     findFirst(String)
     name()

vs

     instance()

So, we get future-proofing almost for free.

The interfaces and implementation classes are separate, but I'd want 
this anyhow, since I very intentionally have them in separate packages.

-Robert


>
> -- Jon
>
>
> On 11/26/2016 02:19 PM, Robert Field wrote:
>> Goldilocks and the three launching mechanisms...
>>
>> She lay down in the first bed, but it was too hard.
>>     java.util.spi.ToolProvider (8169821) has a severe impedance 
>> mismatch: the use of Writers, no InputStream, and no flexibility.
>>
>> Then she lay in the second bed, but it was too soft.
>>     javax.tools.ToolProvider (8170044) would require significant 
>> changes that are not possible at this time, it is limited, and is old 
>> mechanism.
>>
>> Then she lay down in the third bed and it was just right. Goldilocks 
>> fell asleep.
>>     jdk.jshell.tool (8170162) provides a matching, clean, and 
>> configurable launching mechanism
>>
>> Please review...
>>
>> Bug:
>>
>>     8170162: jshell tool: no mechanism to programmatically launch
>>     https://bugs.openjdk.java.net/browse/JDK-8170162
>>
>> Sub-Tasks (tiny tweaks to other repos):
>>
>>     8170194: jshell tool (jdk repo): launch tool from JShellToolProvider
>>     https://bugs.openjdk.java.net/browse/JDK-8170194
>>
>>     8170195: jshell tool (make): update javadoc generation for 
>> jdk.jshell
>>     https://bugs.openjdk.java.net/browse/JDK-8170195
>>
>> Webrevs:
>>
>>     http://cr.openjdk.java.net/~rfield/8170162v0.webrev/
>>
>>     http://cr.openjdk.java.net/~rfield/8170194v0.webrev/
>>
>>     http://cr.openjdk.java.net/~rfield/8170195v0.webrev/
>>
>> API:
>>
>>     http://cr.openjdk.java.net/~rfield/8170162v0.jshellAPI/
>>
>> SpecDiff:
>>
>> http://cr.openjdk.java.net/~rfield/8170162v0.specdiff/overview-summary.html 
>>
>>
>> Thanks,
>> Robert
>>
>


From robert.field at oracle.com  Thu Dec  8 15:37:46 2016
From: robert.field at oracle.com (Robert Field)
Date: Thu, 08 Dec 2016 07:37:46 -0800
Subject: RFR 8170162: jshell tool: no mechanism to programmatically launch
In-Reply-To: <5848E10F.8000108@oracle.com>
References: <583A0A5B.6050100@oracle.com> <5848CA74.3070405@oracle.com>
	<5848E10F.8000108@oracle.com>
Message-ID: <58497E4A.5070707@oracle.com>

Updated per review --

Webrevs:

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

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

API:

     http://cr.openjdk.java.net/~rfield/8170162v1.jshellAPI/

SpecDiff:

http://cr.openjdk.java.net/~rfield/8170162v1.specdiff/overview-summary.html

References in-line...

On 12/07/16 20:26, Robert Field wrote:
> Thank you for the review, Jon!
>
> Responses in-line below.
>
> On 12/07/16 18:50, Jonathan Gibbons wrote:
>> Many of the new files in the langtools webrev do not have the 
>> correct, required, legal header. This is a MUST-FIX,
>
> Oops!!

http://cr.openjdk.java.net/~rfield/8170162v1.webrev/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellToolBuilder.java.html
http://cr.openjdk.java.net/~rfield/8170162v1.webrev/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellToolProvider.java.html
http://cr.openjdk.java.net/~rfield/8170162v1.webrev/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/PersistentStorage.java.html

>
>>
>> In the new package-info file, this comment is a little bit hokey 
>> and/or out of place.
>>
>>   52  * Note: The Java&trade; shell tool is built on the {@link 
>> jdk.jshell} API,
>>   53  * but the tool is at a different level, and this launching SPI 
>> does not
>>   54  * interact with the {@link jdk.jshell} API.
>
> Not sure what is hokey, but the additional documentation I added to 
> overview,html clarifies the relationship between the layers more 
> clearly and is more appropriately placed than this, so, I will remove.

http://cr.openjdk.java.net/~rfield/8170162v1.jshellAPI/jdk/jshell/tool/package-summary.html

http://cr.openjdk.java.net/~rfield/8170162v1.jshellAPI/jdk.jshell-summary.html

> BTW: Seems I should dump overview.html, putting that in module-info.java?

Removed --

http://cr.openjdk.java.net/~rfield/8170195v1.webrev/make/Javadoc.gmk.sdiff.html

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


>
>>
>> At a minimum, I suggest making it an @apiNote, but I would recommend 
>> trying to rethink/reconsider
>> what you are trying to say here.
>>
>> I think you should figure a way and place to specify the non-null 
>> name used by the standard implementation
>> of the JShellToolProvider. That being said ....
>
> "The name of the standard implementation is 'jshell'" ???
> In jdk.jshell.tool.JavaShellToolProvider.name()

http://cr.openjdk.java.net/~rfield/8170162v1.jshellAPI/jdk/jshell/tool/JavaShellToolProvider.html

>
>>
>> I guess I'm surprised you need to define a JShellToolProvider PAI -- 
>> do you expect there to be multiple
>> implementations of JShell on any system?
>
> Maybe not.  But who knows, we already have an external fork..
> I suppose we could have experimental versions in incubator modules...
> I could also imagine a future with the jshell tool implementation 
> broken into a separate module and slimmed-down runtime images built.
>
>>   Why not just have
>>     static JShellToolProvider.instance()
>> to return an instance of the one true jshell implementation?
>
> Certainly an option (depending on the above).  Though the difference 
> in interface is:
>
>     findFirst(String)
>     name()
>
> vs
>
>     instance()
>
> So, we get future-proofing almost for free.

No changes made here until we come to a fixed-point.

Note: an additional option, rather than "instance()" is a static 
"builder()" method on the provider since "instance().builder()" is the 
only interesting thind you could do with it.   Could add while leaving 
or removing the other methods.

Thanks,
Robert

>
> The interfaces and implementation classes are separate, but I'd want 
> this anyhow, since I very intentionally have them in separate packages.
>
> -Robert
>
>
>>
>> -- Jon
>>
>>
>> On 11/26/2016 02:19 PM, Robert Field wrote:
>>> Goldilocks and the three launching mechanisms...
>>>
>>> She lay down in the first bed, but it was too hard.
>>>     java.util.spi.ToolProvider (8169821) has a severe impedance 
>>> mismatch: the use of Writers, no InputStream, and no flexibility.
>>>
>>> Then she lay in the second bed, but it was too soft.
>>>     javax.tools.ToolProvider (8170044) would require significant 
>>> changes that are not possible at this time, it is limited, and is 
>>> old mechanism.
>>>
>>> Then she lay down in the third bed and it was just right. Goldilocks 
>>> fell asleep.
>>>     jdk.jshell.tool (8170162) provides a matching, clean, and 
>>> configurable launching mechanism
>>>
>>> Please review...
>>>
>>> Bug:
>>>
>>>     8170162: jshell tool: no mechanism to programmatically launch
>>>     https://bugs.openjdk.java.net/browse/JDK-8170162
>>>
>>> Sub-Tasks (tiny tweaks to other repos):
>>>
>>>     8170194: jshell tool (jdk repo): launch tool from 
>>> JShellToolProvider
>>>     https://bugs.openjdk.java.net/browse/JDK-8170194
>>>
>>>     8170195: jshell tool (make): update javadoc generation for 
>>> jdk.jshell
>>>     https://bugs.openjdk.java.net/browse/JDK-8170195
>>>
>>> Webrevs:
>>>
>>>     http://cr.openjdk.java.net/~rfield/8170162v0.webrev/
>>>
>>>     http://cr.openjdk.java.net/~rfield/8170194v0.webrev/
>>>
>>>     http://cr.openjdk.java.net/~rfield/8170195v0.webrev/
>>>
>>> API:
>>>
>>>     http://cr.openjdk.java.net/~rfield/8170162v0.jshellAPI/
>>>
>>> SpecDiff:
>>>
>>> http://cr.openjdk.java.net/~rfield/8170162v0.specdiff/overview-summary.html 
>>>
>>>
>>> Thanks,
>>> Robert
>>>
>>
>


From jan.lahoda at oracle.com  Thu Dec  8 21:02:49 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 8 Dec 2016 22:02:49 +0100
Subject: RFR 8168615: JShell API: jdk.jshell.spi should be a pluggable
	ServiceLoader SPI
In-Reply-To: <5847996A.7080005@oracle.com>
References: <58412760.3080500@oracle.com> <58470017.1080806@oracle.com>
	<5847996A.7080005@oracle.com>
Message-ID: <5849CA79.4070903@oracle.com>

On 7.12.2016 06:08, Robert Field wrote:
> Thanks for the review, Jan.
>
> See responses inline.
>
> On 12/06/16 10:14, Jan Lahoda wrote:
>> A few comments:
>> -the -X help will (in my understanding) produce this:
>> +\    --execution <spec>                 Specify an alternate
>> execution engine.\n\
>> +\                                        Where <spec> is an
>> ExecutionControldProvider spec.\n\
>> +\                                        See jdk.jshell.spi\n\
>>
>> As this is a user-level help (although a very experienced user,
>> presumably), it would be better I think to provide some details - e.g.
>> the grammar for the spec; known provider; and ideally, parameters of
>> the known providers
>
> OK, so better doc references are in order.  I think including the
> grammar and explanatory information is probably too bulky for
> command-line help.  But I've clarified this help as follows (the
> formatting is right if fix-width, but formatted text cannot be sent to
> this list):
>
>           % jshell -X
>               --add-exports <module>/<package>   Export specified
> module-private package to snippets
>               --execution <spec>                 Specify an alternate
> execution engine.
>                                                    Where <spec> is an
> ExecutionControl spec.
>                                                    See the documentation
> of the package
>                                                    jdk.jshell.spi for
> the syntax of the spec
>
>           These options are non-standard and subject to change without
> notice.
>
> Where the jdk.jshell.spi javadocs are now:
>
> http://cr.openjdk.java.net/~rfield/8168615v1.jshellAPI/jdk/jshell/spi/package-summary.html
>
>
> It is OK that they would need to reference the SPI docs because if they
> implemented an execution engine they would have implemented these
> interfaces,  If they are just tweaking parameters (and this isn't
> something we want a typical user to do) they would need to be familiar
> with the parameters, which are described in these docs.

Still not sure if it is polite to not provide enough information for the 
user to construct the option, but OK.

>
>
>>
>> -I would reorganize the rules in the spec grammar to go from the top
>> down:
>> +     * spec := name : params
>> +     *       | name
>> +     * name := id
>> +     * params := param , params
>> +     *        | param
>> +     *        |
>> +     * param := id ( value )
>>
>> (might be also good to say what is "id")
>
> Both good ideas implemented in the above.
>
>>
>> -ExecutionControlProvider.logMessages seems weird. Is it used outside
>> of tests?
>
> Not currently, but we really need logging of failures and failover to
> track-down rare intermittent issues.  Adding logging is out of scope for
> 9, but this gives a needed hook.

So, why not use a logging framework (e.g. System.getLogger) for logging?

>
>>
>> -after this patch, both the ExecutionControls and their Providers are
>> public - is that desirable? Is there a usecase for the client to
>> call/instantiate the Providers directly without going through the
>> ServiceLoader?
>
> The ExecutionControls were public before.  jdk.jshell.execution contains
> the default execution engines, but it is exposed because it is a library
> of classes for implementing ExecutionControl (and now
> ExecutionControlProvider).

What is the usecase for having the LocalExecutionControlProvider, 
JdiExecutionControlProvider and FailOverExecutionControlProvider public?

Jan

>
> The SPI and the jdk.jshell.execution library were created because of a
> request from an IDE developer.
>
> OK, here is the new version.  No executable code was changed, but I've
> spruced-up the documentation, including what is mentioned above.
>
> The docs:
>
>      http://cr.openjdk.java.net/~rfield/8168615v1.jshellAPI/
>
> Specdiff:
>
> http://cr.openjdk.java.net/~rfield/8168615v1.specdiff/overview-summary.html
>
> New webrev:
>
>      http://cr.openjdk.java.net/~rfield/8168615v1.webrev/
>
> -Robert
>
>>
>> Jan
>>
>> On 2.12.2016 08:48, Robert Field wrote:
>>> Please review...
>>>
>>> Bug:
>>>
>>>       https://bugs.openjdk.java.net/browse/JDK-8168615
>>>
>>>
>>> Webrev:
>>>
>>>      http://cr.openjdk.java.net/~rfield/8168615v0.webrev/
>>>
>>> Thanks,
>>> Robert
>>>
>

From michael.mueller at mueller-bruehl.de  Thu Dec  8 22:34:30 2016
From: michael.mueller at mueller-bruehl.de (=?UTF-8?Q?Michael_M=c3=bcller?=)
Date: Thu, 8 Dec 2016 23:34:30 +0100
Subject: repeat statement by using /-n
Message-ID: <63d51ee6-c0c6-f2cd-1d6c-1e3d4df09f03@mueller-bruehl.de>

Hi Robert,

Let's suppose, I entered 7 statements and like to repeat all of them in 
the same order.

I will use /-7 seven times. This is quite faster and less error-prone 
than using seven times seven arrow-up keystrokes, which would repeat the 
last seven command also.

I like to repeat the last commands even more faster. I can use the 
arrow-up key to repeat the last command. But I can't repeat the "/-n" 
because it is processed by the shell and replaced by the appropriate 
command. Arrow-up will repeat this command.

I suggest to add another keyboard shortcut to repeat the last input 
as-is. For example Ctrl-+Arrow-up will repeat "/-n". Instead of 
re-typing "/-n" this will do the same by just one key combination. Thoughts?


-- 

Herzliche Gr??e - Best Regards,

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


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



From robert.field at oracle.com  Fri Dec  9 02:50:43 2016
From: robert.field at oracle.com (Robert Field)
Date: Thu, 08 Dec 2016 18:50:43 -0800
Subject: RFR 8168615: JShell API: jdk.jshell.spi should be a pluggable
	ServiceLoader SPI
In-Reply-To: <5849CA79.4070903@oracle.com>
References: <58412760.3080500@oracle.com> <58470017.1080806@oracle.com>
	<5847996A.7080005@oracle.com> <5849CA79.4070903@oracle.com>
Message-ID: <584A1C03.8010608@oracle.com>

Updated version (v2) --

JShell docs:
http://cr.openjdk.java.net/~rfield/8168615v2.jshellAPI/

Specdiff:
http://cr.openjdk.java.net/~rfield/8168615v2.specdiff/overview-summary.html

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

Responses and references to the above in-line...

On 12/08/16 13:02, Jan Lahoda wrote:
> On 7.12.2016 06:08, Robert Field wrote:
>> Thanks for the review, Jan.
>>
>> See responses inline.
>>
>> On 12/06/16 10:14, Jan Lahoda wrote:
>>> A few comments:
>>> -the -X help will (in my understanding) produce this:
>>> +\    --execution <spec>                 Specify an alternate
>>> execution engine.\n\
>>> +\                                        Where <spec> is an
>>> ExecutionControldProvider spec.\n\
>>> +\                                        See jdk.jshell.spi\n\
>>>
>>> As this is a user-level help (although a very experienced user,
>>> presumably), it would be better I think to provide some details - e.g.
>>> the grammar for the spec; known provider; and ideally, parameters of
>>> the known providers
>>
>> OK, so better doc references are in order.  I think including the
>> grammar and explanatory information is probably too bulky for
>> command-line help.  But I've clarified this help as follows (the
>> formatting is right if fix-width, but formatted text cannot be sent to
>> this list):
>>
>>           % jshell -X
>>               --add-exports <module>/<package> Export specified
>> module-private package to snippets
>>               --execution <spec>                 Specify an alternate
>> execution engine.
>>                                                    Where <spec> is an
>> ExecutionControl spec.
>>                                                    See the documentation
>> of the package
>> jdk.jshell.spi for
>> the syntax of the spec
>>
>>           These options are non-standard and subject to change without
>> notice.
>>
>> Where the jdk.jshell.spi javadocs are now:
>>
>> http://cr.openjdk.java.net/~rfield/8168615v1.jshellAPI/jdk/jshell/spi/package-summary.html 
>>
>>
>>
>> It is OK that they would need to reference the SPI docs because if they
>> implemented an execution engine they would have implemented these
>> interfaces,  If they are just tweaking parameters (and this isn't
>> something we want a typical user to do) they would need to be familiar
>> with the parameters, which are described in these docs.
>
> Still not sure if it is polite to not provide enough information for 
> the user to construct the option, but OK.

The SPI is and documents the interface, so it doesn't seem an ideal 
place to document the set of current implementations -- though, by 
example, it demonstrates specs for all the predefined providers and 
almost all of the their parameters.

The only reason this is here or interesting is if they are defining 
their own execution engine, in which case they need to be familiar.

In fact, I'm negatively inclined to have the average users throwing 
random spec strings at it and submitting bugs when they get failures.


>
>>
>>
>>>
>>> -I would reorganize the rules in the spec grammar to go from the top
>>> down:
>>> +     * spec := name : params
>>> +     *       | name
>>> +     * name := id
>>> +     * params := param , params
>>> +     *        | param
>>> +     *        |
>>> +     * param := id ( value )
>>>
>>> (might be also good to say what is "id")
>>
>> Both good ideas implemented in the above.
>>
>>>
>>> -ExecutionControlProvider.logMessages seems weird. Is it used outside
>>> of tests?
>>
>> Not currently, but we really need logging of failures and failover to
>> track-down rare intermittent issues.  Adding logging is out of scope for
>> 9, but this gives a needed hook.
>
> So, why not use a logging framework (e.g. System.getLogger) for logging?

Fair enough.  I've switched to the logging framework and removed 
ExecutionControlProvider.logMessages.

http://cr.openjdk.java.net/~rfield/8168615v2.jshellAPI/jdk/jshell/spi/ExecutionControlProvider.html

http://cr.openjdk.java.net/~rfield/8168615v2.webrev/src/jdk.jshell/share/classes/jdk/jshell/execution/FailOverExecutionControlProvider.java.html
http://cr.openjdk.java.net/~rfield/8168615v2.webrev/test/jdk/jshell/FailOverDirectExecutionControlTest.java.html

>
>>
>>>
>>> -after this patch, both the ExecutionControls and their Providers are
>>> public - is that desirable? Is there a usecase for the client to
>>> call/instantiate the Providers directly without going through the
>>> ServiceLoader?
>>
>> The ExecutionControls were public before.  jdk.jshell.execution contains
>> the default execution engines, but it is exposed because it is a library
>> of classes for implementing ExecutionControl (and now
>> ExecutionControlProvider).
>
> What is the usecase for having the LocalExecutionControlProvider, 
> JdiExecutionControlProvider and FailOverExecutionControlProvider public?

jdk.jshell.execution is for public implementations of the jdk.jshell.spi 
interfaces, and those interfaces now include ExecutionControlProvider, 
basically replacing ExecutionControl.Generator.

JdiDefaultExecutionControl or JdiExecutionControl are designed to 
function as both standard implementation and subclassable code for 
constructing new execution engines.  The provider is the face of this 
body, it would seem strange to expose the body and not the face.  For 
example, JdiExecutionControlProvider, were JdiDefaultExecutionControl 
subclassed, it would need a provider -- the obvious choice would be to 
subclass  JdiExecutionControlProvider changng out the ExecutionControl 
implementation and retaining the rest of the provider functionality.

The subclassing is far less compelling for LocalExecutionControlProvider 
since both its methods would need to be overridden.

For each of them, this is where the parameters are specified -- so they 
need to be in public documentation.  Given that though, 
defaultParameters() should be overriden in LocalExecutionControlProvider 
to specify there are no parameters.

http://cr.openjdk.java.net/~rfield/8168615v2.jshellAPI/jdk/jshell/execution/LocalExecutionControlProvider.html#defaultParameters--

-Robert

>
> Jan
>
>>
>> The SPI and the jdk.jshell.execution library were created because of a
>> request from an IDE developer.
>>
>> OK, here is the new version.  No executable code was changed, but I've
>> spruced-up the documentation, including what is mentioned above.
>>
>> The docs:
>>
>>      http://cr.openjdk.java.net/~rfield/8168615v1.jshellAPI/
>>
>> Specdiff:
>>
>> http://cr.openjdk.java.net/~rfield/8168615v1.specdiff/overview-summary.html 
>>
>>
>> New webrev:
>>
>>      http://cr.openjdk.java.net/~rfield/8168615v1.webrev/
>>
>> -Robert
>>
>>>
>>> Jan
>>>
>>> On 2.12.2016 08:48, Robert Field wrote:
>>>> Please review...
>>>>
>>>> Bug:
>>>>
>>>>       https://bugs.openjdk.java.net/browse/JDK-8168615
>>>>
>>>>
>>>> Webrev:
>>>>
>>>>      http://cr.openjdk.java.net/~rfield/8168615v0.webrev/
>>>>
>>>> Thanks,
>>>> Robert
>>>>
>>


From robert.field at oracle.com  Fri Dec  9 03:45:57 2016
From: robert.field at oracle.com (Robert Field)
Date: Thu, 08 Dec 2016 19:45:57 -0800
Subject: RFR 8170162: jshell tool: no mechanism to programmatically launch
In-Reply-To: <58497E4A.5070707@oracle.com>
References: <583A0A5B.6050100@oracle.com>
	<5848CA74.3070405@oracle.com>	<5848E10F.8000108@oracle.com>
	<58497E4A.5070707@oracle.com>
Message-ID: <584A28F5.9010107@oracle.com>

More on sole-instance vs ServiceLoader loader look-up...

The choice is between:
   * A fixed sole-instance of the jshell tool baked into the platform, 
with a very simple access to that instance
   * A ServiceLoader-based look-up of the tool, with a couple more 
methods in the interface, and a couple more calls to get the instance

The philosophy of KISS (Keep It Simple Stupid) would argue for 
sole-instance unless it foreclosed or severely constrained on an 
interesting future.  It does not, in that the ServiceLoader approach 
could, if needed, be layered on top of what would become 
standard-instance access.

Given that, there a few options of what the interface should be --

(1) As current, but replace the look-up with access:

   public interface JavaShellToolProvider {
     String name();
     JavaShellToolBuilder builder();
     static JavaShellToolProvider instance();
   }

(2) But, the name will always return the same thing, and then the only 
interesting thing you can do is call the builder, so it could go 
directly to the builder:

   public interface JavaShellToolProvider {
     static JavaShellToolBuilder builder();
   }

(3) But, an interface with one static method seems silly, rather, the 
factory could sit directly on the builder:

   public interface JavaShellToolBuilder {

     ...

     static JavaShellToolBuilder builder();
   }

Thoughts?

-Robert


On 12/08/16 07:37, Robert Field wrote:
> Updated per review --
>
> Webrevs:
>
>     http://cr.openjdk.java.net/~rfield/8170162v1.webrev/
>
>     http://cr.openjdk.java.net/~rfield/8170195v1.webrev/
>
> API:
>
>     http://cr.openjdk.java.net/~rfield/8170162v1.jshellAPI/
>
> SpecDiff:
>
> http://cr.openjdk.java.net/~rfield/8170162v1.specdiff/overview-summary.html 
>
>
> References in-line...
>
> On 12/07/16 20:26, Robert Field wrote:
>> Thank you for the review, Jon!
>>
>> Responses in-line below.
>>
>> On 12/07/16 18:50, Jonathan Gibbons wrote:
>>> Many of the new files in the langtools webrev do not have the 
>>> correct, required, legal header. This is a MUST-FIX,
>>
>> Oops!!
>
> http://cr.openjdk.java.net/~rfield/8170162v1.webrev/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellToolBuilder.java.html 
>
> http://cr.openjdk.java.net/~rfield/8170162v1.webrev/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellToolProvider.java.html 
>
> http://cr.openjdk.java.net/~rfield/8170162v1.webrev/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/PersistentStorage.java.html 
>
>
>>
>>>
>>> In the new package-info file, this comment is a little bit hokey 
>>> and/or out of place.
>>>
>>>   52  * Note: The Java&trade; shell tool is built on the {@link 
>>> jdk.jshell} API,
>>>   53  * but the tool is at a different level, and this launching SPI 
>>> does not
>>>   54  * interact with the {@link jdk.jshell} API.
>>
>> Not sure what is hokey, but the additional documentation I added to 
>> overview,html clarifies the relationship between the layers more 
>> clearly and is more appropriately placed than this, so, I will remove.
>
> http://cr.openjdk.java.net/~rfield/8170162v1.jshellAPI/jdk/jshell/tool/package-summary.html 
>
>
> http://cr.openjdk.java.net/~rfield/8170162v1.jshellAPI/jdk.jshell-summary.html 
>
>
>> BTW: Seems I should dump overview.html, putting that in 
>> module-info.java?
>
> Removed --
>
> http://cr.openjdk.java.net/~rfield/8170195v1.webrev/make/Javadoc.gmk.sdiff.html 
>
>
> http://cr.openjdk.java.net/~rfield/8170162v1.webrev/
>
>
>>
>>>
>>> At a minimum, I suggest making it an @apiNote, but I would recommend 
>>> trying to rethink/reconsider
>>> what you are trying to say here.
>>>
>>> I think you should figure a way and place to specify the non-null 
>>> name used by the standard implementation
>>> of the JShellToolProvider. That being said ....
>>
>> "The name of the standard implementation is 'jshell'" ???
>> In jdk.jshell.tool.JavaShellToolProvider.name()
>
> http://cr.openjdk.java.net/~rfield/8170162v1.jshellAPI/jdk/jshell/tool/JavaShellToolProvider.html 
>
>
>>
>>>
>>> I guess I'm surprised you need to define a JShellToolProvider PAI -- 
>>> do you expect there to be multiple
>>> implementations of JShell on any system?
>>
>> Maybe not.  But who knows, we already have an external fork..
>> I suppose we could have experimental versions in incubator modules...
>> I could also imagine a future with the jshell tool implementation 
>> broken into a separate module and slimmed-down runtime images built.
>>
>>>   Why not just have
>>>     static JShellToolProvider.instance()
>>> to return an instance of the one true jshell implementation?
>>
>> Certainly an option (depending on the above).  Though the difference 
>> in interface is:
>>
>>     findFirst(String)
>>     name()
>>
>> vs
>>
>>     instance()
>>
>> So, we get future-proofing almost for free.
>
> No changes made here until we come to a fixed-point.
>
> Note: an additional option, rather than "instance()" is a static 
> "builder()" method on the provider since "instance().builder()" is the 
> only interesting thind you could do with it.   Could add while leaving 
> or removing the other methods.
>
> Thanks,
> Robert
>
>>
>> The interfaces and implementation classes are separate, but I'd want 
>> this anyhow, since I very intentionally have them in separate packages.
>>
>> -Robert
>>
>>
>>>
>>> -- Jon
>>>
>>>
>>> On 11/26/2016 02:19 PM, Robert Field wrote:
>>>> Goldilocks and the three launching mechanisms...
>>>>
>>>> She lay down in the first bed, but it was too hard.
>>>>     java.util.spi.ToolProvider (8169821) has a severe impedance 
>>>> mismatch: the use of Writers, no InputStream, and no flexibility.
>>>>
>>>> Then she lay in the second bed, but it was too soft.
>>>>     javax.tools.ToolProvider (8170044) would require significant 
>>>> changes that are not possible at this time, it is limited, and is 
>>>> old mechanism.
>>>>
>>>> Then she lay down in the third bed and it was just right. 
>>>> Goldilocks fell asleep.
>>>>     jdk.jshell.tool (8170162) provides a matching, clean, and 
>>>> configurable launching mechanism
>>>>
>>>> Please review...
>>>>
>>>> Bug:
>>>>
>>>>     8170162: jshell tool: no mechanism to programmatically launch
>>>>     https://bugs.openjdk.java.net/browse/JDK-8170162
>>>>
>>>> Sub-Tasks (tiny tweaks to other repos):
>>>>
>>>>     8170194: jshell tool (jdk repo): launch tool from 
>>>> JShellToolProvider
>>>>     https://bugs.openjdk.java.net/browse/JDK-8170194
>>>>
>>>>     8170195: jshell tool (make): update javadoc generation for 
>>>> jdk.jshell
>>>>     https://bugs.openjdk.java.net/browse/JDK-8170195
>>>>
>>>> Webrevs:
>>>>
>>>>     http://cr.openjdk.java.net/~rfield/8170162v0.webrev/
>>>>
>>>>     http://cr.openjdk.java.net/~rfield/8170194v0.webrev/
>>>>
>>>>     http://cr.openjdk.java.net/~rfield/8170195v0.webrev/
>>>>
>>>> API:
>>>>
>>>>     http://cr.openjdk.java.net/~rfield/8170162v0.jshellAPI/
>>>>
>>>> SpecDiff:
>>>>
>>>> http://cr.openjdk.java.net/~rfield/8170162v0.specdiff/overview-summary.html 
>>>>
>>>>
>>>> Thanks,
>>>> Robert
>>>>
>>>
>>
>


From robert.field at oracle.com  Sat Dec 10 04:27:37 2016
From: robert.field at oracle.com (Robert Field)
Date: Fri, 09 Dec 2016 20:27:37 -0800
Subject: RFR 8170162: jshell tool: no mechanism to programmatically launch
In-Reply-To: <584A28F5.9010107@oracle.com>
References: <583A0A5B.6050100@oracle.com>	<5848CA74.3070405@oracle.com>	<5848E10F.8000108@oracle.com>	<58497E4A.5070707@oracle.com>
	<584A28F5.9010107@oracle.com>
Message-ID: <584B8439.80306@oracle.com>

Here is version 2, which includes the the doc changes made in v1 plus 
moving from a ServiceLoader based SPI to a simple sole-instance SPI. --

API:

     http://cr.openjdk.java.net/~rfield/8170162v2.jshellAPI/

Webrev:

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

Specdiff:

http://cr.openjdk.java.net/~rfield/8170162v2.specdiff/overview-summary.html

The root workspace javadoc make delta is the same as v1:

http://cr.openjdk.java.net/~rfield/8170195v1.webrev/make/Javadoc.gmk.sdiff.html

The jdk workspace launching delta is the same as the original v0:

http://cr.openjdk.java.net/~rfield/8170194v0.webrev/make/launcher/Launcher-jdk.jshell.gmk.sdiff.html

Since it has been a while, the bugs --

Bug:

     8170162: jshell tool: no mechanism to programmatically launch
     https://bugs.openjdk.java.net/browse/JDK-8170162

Sub-Tasks (tiny tweaks to other repos):

     8170194: jshell tool (jdk repo): launch tool from JShellToolProvider
     https://bugs.openjdk.java.net/browse/JDK-8170194

     8170195: jshell tool (make): update javadoc generation for jdk.jshell
     https://bugs.openjdk.java.net/browse/JDK-8170195

Discussion --

The simplest of the options below (3) was chosen -- builder() factory on 
JavaShellToolBuilder.

http://cr.openjdk.java.net/~rfield/8170162v2.jshellAPI/jdk/jshell/tool/package-summary.html

The uses/provides changes to module-info.java have been removed, leaving 
the addition of "exports jdk.jshell.tool", and, to work with the 
merged-in jigsaw, the java.prefs requires is now transitive:

http://cr.openjdk.java.net/~rfield/8170162v2.webrev/src/jdk.jshell/share/classes/module-info.java.sdiff.html

JavaShellToolProvider has been removed.

Before you ask, I have left the internal JShellToolProvider, which will 
make more sense when javax.tools.Tool is hooked in, but for now it 
uniformly channels all jshell tool launching through the builder (rather 
than entering via JShellTool).

Note: specdiff doesn't see the changes to overview.html (removal) and 
module docs, which are now:

http://cr.openjdk.java.net/~rfield/8170162v2.jshellAPI/jdk.jshell-summary.html

Thanks,
Robert


On 12/08/16 19:45, Robert Field wrote:
> More on sole-instance vs ServiceLoader loader look-up...
>
> The choice is between:
>   * A fixed sole-instance of the jshell tool baked into the platform, 
> with a very simple access to that instance
>   * A ServiceLoader-based look-up of the tool, with a couple more 
> methods in the interface, and a couple more calls to get the instance
>
> The philosophy of KISS (Keep It Simple Stupid) would argue for 
> sole-instance unless it foreclosed or severely constrained on an 
> interesting future.  It does not, in that the ServiceLoader approach 
> could, if needed, be layered on top of what would become 
> standard-instance access.
>
> Given that, there a few options of what the interface should be --
>
> (1) As current, but replace the look-up with access:
>
>   public interface JavaShellToolProvider {
>     String name();
>     JavaShellToolBuilder builder();
>     static JavaShellToolProvider instance();
>   }
>
> (2) But, the name will always return the same thing, and then the only 
> interesting thing you can do is call the builder, so it could go 
> directly to the builder:
>
>   public interface JavaShellToolProvider {
>     static JavaShellToolBuilder builder();
>   }
>
> (3) But, an interface with one static method seems silly, rather, the 
> factory could sit directly on the builder:
>
>   public interface JavaShellToolBuilder {
>
>     ...
>
>     static JavaShellToolBuilder builder();
>   }
>
> Thoughts?
>
> -Robert
>
>
> On 12/08/16 07:37, Robert Field wrote:
>> Updated per review --
>>
>> Webrevs:
>>
>>     http://cr.openjdk.java.net/~rfield/8170162v1.webrev/
>>
>>     http://cr.openjdk.java.net/~rfield/8170195v1.webrev/
>>
>> API:
>>
>>     http://cr.openjdk.java.net/~rfield/8170162v1.jshellAPI/
>>
>> SpecDiff:
>>
>> http://cr.openjdk.java.net/~rfield/8170162v1.specdiff/overview-summary.html 
>>
>>
>> References in-line...
>>
>> On 12/07/16 20:26, Robert Field wrote:
>>> Thank you for the review, Jon!
>>>
>>> Responses in-line below.
>>>
>>> On 12/07/16 18:50, Jonathan Gibbons wrote:
>>>> Many of the new files in the langtools webrev do not have the 
>>>> correct, required, legal header. This is a MUST-FIX,
>>>
>>> Oops!!
>>
>> http://cr.openjdk.java.net/~rfield/8170162v1.webrev/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellToolBuilder.java.html 
>>
>> http://cr.openjdk.java.net/~rfield/8170162v1.webrev/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellToolProvider.java.html 
>>
>> http://cr.openjdk.java.net/~rfield/8170162v1.webrev/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/PersistentStorage.java.html 
>>
>>
>>>
>>>>
>>>> In the new package-info file, this comment is a little bit hokey 
>>>> and/or out of place.
>>>>
>>>>   52  * Note: The Java&trade; shell tool is built on the {@link 
>>>> jdk.jshell} API,
>>>>   53  * but the tool is at a different level, and this launching 
>>>> SPI does not
>>>>   54  * interact with the {@link jdk.jshell} API.
>>>
>>> Not sure what is hokey, but the additional documentation I added to 
>>> overview,html clarifies the relationship between the layers more 
>>> clearly and is more appropriately placed than this, so, I will remove.
>>
>> http://cr.openjdk.java.net/~rfield/8170162v1.jshellAPI/jdk/jshell/tool/package-summary.html 
>>
>>
>> http://cr.openjdk.java.net/~rfield/8170162v1.jshellAPI/jdk.jshell-summary.html 
>>
>>
>>> BTW: Seems I should dump overview.html, putting that in 
>>> module-info.java?
>>
>> Removed --
>>
>> http://cr.openjdk.java.net/~rfield/8170195v1.webrev/make/Javadoc.gmk.sdiff.html 
>>
>>
>> http://cr.openjdk.java.net/~rfield/8170162v1.webrev/
>>
>>
>>>
>>>>
>>>> At a minimum, I suggest making it an @apiNote, but I would 
>>>> recommend trying to rethink/reconsider
>>>> what you are trying to say here.
>>>>
>>>> I think you should figure a way and place to specify the non-null 
>>>> name used by the standard implementation
>>>> of the JShellToolProvider. That being said ....
>>>
>>> "The name of the standard implementation is 'jshell'" ???
>>> In jdk.jshell.tool.JavaShellToolProvider.name()
>>
>> http://cr.openjdk.java.net/~rfield/8170162v1.jshellAPI/jdk/jshell/tool/JavaShellToolProvider.html 
>>
>>
>>>
>>>>
>>>> I guess I'm surprised you need to define a JShellToolProvider PAI 
>>>> -- do you expect there to be multiple
>>>> implementations of JShell on any system?
>>>
>>> Maybe not.  But who knows, we already have an external fork..
>>> I suppose we could have experimental versions in incubator modules...
>>> I could also imagine a future with the jshell tool implementation 
>>> broken into a separate module and slimmed-down runtime images built.
>>>
>>>>   Why not just have
>>>>     static JShellToolProvider.instance()
>>>> to return an instance of the one true jshell implementation?
>>>
>>> Certainly an option (depending on the above).  Though the difference 
>>> in interface is:
>>>
>>>     findFirst(String)
>>>     name()
>>>
>>> vs
>>>
>>>     instance()
>>>
>>> So, we get future-proofing almost for free.
>>
>> No changes made here until we come to a fixed-point.
>>
>> Note: an additional option, rather than "instance()" is a static 
>> "builder()" method on the provider since "instance().builder()" is 
>> the only interesting thind you could do with it.   Could add while 
>> leaving or removing the other methods.
>>
>> Thanks,
>> Robert
>>
>>>
>>> The interfaces and implementation classes are separate, but I'd want 
>>> this anyhow, since I very intentionally have them in separate packages.
>>>
>>> -Robert
>>>
>>>
>>>>
>>>> -- Jon
>>>>
>>>>
>>>> On 11/26/2016 02:19 PM, Robert Field wrote:
>>>>> Goldilocks and the three launching mechanisms...
>>>>>
>>>>> She lay down in the first bed, but it was too hard.
>>>>>     java.util.spi.ToolProvider (8169821) has a severe impedance 
>>>>> mismatch: the use of Writers, no InputStream, and no flexibility.
>>>>>
>>>>> Then she lay in the second bed, but it was too soft.
>>>>>     javax.tools.ToolProvider (8170044) would require significant 
>>>>> changes that are not possible at this time, it is limited, and is 
>>>>> old mechanism.
>>>>>
>>>>> Then she lay down in the third bed and it was just right. 
>>>>> Goldilocks fell asleep.
>>>>>     jdk.jshell.tool (8170162) provides a matching, clean, and 
>>>>> configurable launching mechanism
>>>>>
>>>>> Please review...
>>>>>
>>>>> Bug:
>>>>>
>>>>>     8170162: jshell tool: no mechanism to programmatically launch
>>>>>     https://bugs.openjdk.java.net/browse/JDK-8170162
>>>>>
>>>>> Sub-Tasks (tiny tweaks to other repos):
>>>>>
>>>>>     8170194: jshell tool (jdk repo): launch tool from 
>>>>> JShellToolProvider
>>>>>     https://bugs.openjdk.java.net/browse/JDK-8170194
>>>>>
>>>>>     8170195: jshell tool (make): update javadoc generation for 
>>>>> jdk.jshell
>>>>>     https://bugs.openjdk.java.net/browse/JDK-8170195
>>>>>
>>>>> Webrevs:
>>>>>
>>>>>     http://cr.openjdk.java.net/~rfield/8170162v0.webrev/
>>>>>
>>>>>     http://cr.openjdk.java.net/~rfield/8170194v0.webrev/
>>>>>
>>>>>     http://cr.openjdk.java.net/~rfield/8170195v0.webrev/
>>>>>
>>>>> API:
>>>>>
>>>>> http://cr.openjdk.java.net/~rfield/8170162v0.jshellAPI/
>>>>>
>>>>> SpecDiff:
>>>>>
>>>>> http://cr.openjdk.java.net/~rfield/8170162v0.specdiff/overview-summary.html 
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Robert
>>>>>
>>>>
>>>
>>
>


From robert.field at oracle.com  Sun Dec 11 02:10:44 2016
From: robert.field at oracle.com (Robert Field)
Date: Sat, 10 Dec 2016 18:10:44 -0800
Subject: Where is the JShell API?
Message-ID: <158eba47348.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>

I've had that question asked individually of me by two people in the last 
two days, so I'll answer it here.

All of JShell, including API and tool, are in the standard early access 
builds of JDK 9.  All built and ready to use.  JDK not JRE.

If the release team is building new JDK APIs, I'm not seeing them yet.  But 
code reviews often include the corresponding docs.  So here are the docs 
from a review request from yesterday:

http://cr.openjdk.java.net/~rfield/8170162v2.jshellAPI/

JShell is not available for JDK 8.

Robert


http://cr.openjdk.java.net/~rfield/8170162v2.jshellAPI/



From jonathan.gibbons at oracle.com  Sun Dec 11 02:28:06 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Sat, 10 Dec 2016 18:28:06 -0800
Subject: Where is the JShell API?
In-Reply-To: <158eba47348.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
References: <158eba47348.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
Message-ID: <31e6621a-9fc0-6fe0-942c-df030d925a8a@oracle.com>

The JShell docs for the latest EA build should be visible here:

http://download.java.net/java/jdk9/docs/jdk/api/jshell/index.html

-- Jon

On 12/10/16 6:10 PM, Robert Field wrote:
> I've had that question asked individually of me by two people in the 
> last two days, so I'll answer it here.
>
> All of JShell, including API and tool, are in the standard early 
> access builds of JDK 9.  All built and ready to use.  JDK not JRE.
>
> If the release team is building new JDK APIs, I'm not seeing them 
> yet.  But code reviews often include the corresponding docs.  So here 
> are the docs from a review request from yesterday:
>
> http://cr.openjdk.java.net/~rfield/8170162v2.jshellAPI/
>
> JShell is not available for JDK 8.
>
> Robert
>
>
> http://cr.openjdk.java.net/~rfield/8170162v2.jshellAPI/
>
>


From robert.field at oracle.com  Sun Dec 11 05:11:00 2016
From: robert.field at oracle.com (Robert Field)
Date: Sat, 10 Dec 2016 21:11:00 -0800
Subject: Where is the JShell API?
In-Reply-To: <158eba47348.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
References: <158eba47348.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
Message-ID: <158ec4a8eb8.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>

Thanks Jon,

Here's the link to the official docs:

http://download.java.net/java/jdk9/docs/jdk/api/jshell/index.html

Robert



On December 10, 2016 6:10:44 PM Robert Field <robert.field at oracle.com> wrote:

> I've had that question asked individually of me by two people in the last 
> two days, so I'll answer it here.
>
> All of JShell, including API and tool, are in the standard early access 
> builds of JDK 9.  All built and ready to use.  JDK not JRE.
>
> If the release team is building new JDK APIs, I'm not seeing them yet.  But 
> code reviews often include the corresponding docs.  So here are the docs 
> from a review request from yesterday:
>
> http://cr.openjdk.java.net/~rfield/8170162v2.jshellAPI/
>
> JShell is not available for JDK 8.
>
> Robert
>
>
> http://cr.openjdk.java.net/~rfield/8170162v2.jshellAPI/



From michael.mueller at mueller-bruehl.de  Sun Dec 11 16:13:28 2016
From: michael.mueller at mueller-bruehl.de (=?UTF-8?Q?Michael_M=c3=bcller?=)
Date: Sun, 11 Dec 2016 17:13:28 +0100
Subject: Where is the JShell API?
In-Reply-To: <31e6621a-9fc0-6fe0-942c-df030d925a8a@oracle.com>
References: <158eba47348.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<31e6621a-9fc0-6fe0-942c-df030d925a8a@oracle.com>
Message-ID: <7ad9593c-af73-4ee6-1519-4d5e8bb8e402@mueller-bruehl.de>

Robert & Jon: Thank you.


Herzliche Gr??e - Best Regards,

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


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


On 11.12.2016 03:28, Jonathan Gibbons wrote:
> The JShell docs for the latest EA build should be visible here:
>
> http://download.java.net/java/jdk9/docs/jdk/api/jshell/index.html
>
> -- Jon
>
> On 12/10/16 6:10 PM, Robert Field wrote:
>> I've had that question asked individually of me by two people in the 
>> last two days, so I'll answer it here.
>>
>> All of JShell, including API and tool, are in the standard early 
>> access builds of JDK 9.  All built and ready to use.  JDK not JRE.
>>
>> If the release team is building new JDK APIs, I'm not seeing them 
>> yet.  But code reviews often include the corresponding docs.  So here 
>> are the docs from a review request from yesterday:
>>
>> http://cr.openjdk.java.net/~rfield/8170162v2.jshellAPI/
>>
>> JShell is not available for JDK 8.
>>
>> Robert
>>
>>
>> http://cr.openjdk.java.net/~rfield/8170162v2.jshellAPI/
>>
>>
>
>


From jan.lahoda at oracle.com  Mon Dec 12 15:20:06 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 12 Dec 2016 16:20:06 +0100
Subject: RFR 8168615: JShell API: jdk.jshell.spi should be a pluggable
	ServiceLoader SPI
In-Reply-To: <584A1C03.8010608@oracle.com>
References: <58412760.3080500@oracle.com> <58470017.1080806@oracle.com>
	<5847996A.7080005@oracle.com> <5849CA79.4070903@oracle.com>
	<584A1C03.8010608@oracle.com>
Message-ID: <584EC026.3080806@oracle.com>

Seems Ok.

Minor nit: in JShell.java, there is (twice):
+         * Use, at most. one of these overloaded {@code 
executionEngine} builder
+         * methods.

note the dot after "most" - should presumably be comma.

Jan

On 9.12.2016 03:50, Robert Field wrote:
> Updated version (v2) --
>
> JShell docs:
> http://cr.openjdk.java.net/~rfield/8168615v2.jshellAPI/
>
> Specdiff:
> http://cr.openjdk.java.net/~rfield/8168615v2.specdiff/overview-summary.html
>
> Webrev:
> http://cr.openjdk.java.net/~rfield/8168615v2.webrev/
>
> Responses and references to the above in-line...
>
> On 12/08/16 13:02, Jan Lahoda wrote:
>> On 7.12.2016 06:08, Robert Field wrote:
>>> Thanks for the review, Jan.
>>>
>>> See responses inline.
>>>
>>> On 12/06/16 10:14, Jan Lahoda wrote:
>>>> A few comments:
>>>> -the -X help will (in my understanding) produce this:
>>>> +\    --execution <spec>                 Specify an alternate
>>>> execution engine.\n\
>>>> +\                                        Where <spec> is an
>>>> ExecutionControldProvider spec.\n\
>>>> +\                                        See jdk.jshell.spi\n\
>>>>
>>>> As this is a user-level help (although a very experienced user,
>>>> presumably), it would be better I think to provide some details - e.g.
>>>> the grammar for the spec; known provider; and ideally, parameters of
>>>> the known providers
>>>
>>> OK, so better doc references are in order.  I think including the
>>> grammar and explanatory information is probably too bulky for
>>> command-line help.  But I've clarified this help as follows (the
>>> formatting is right if fix-width, but formatted text cannot be sent to
>>> this list):
>>>
>>>           % jshell -X
>>>               --add-exports <module>/<package> Export specified
>>> module-private package to snippets
>>>               --execution <spec>                 Specify an alternate
>>> execution engine.
>>>                                                    Where <spec> is an
>>> ExecutionControl spec.
>>>                                                    See the documentation
>>> of the package
>>> jdk.jshell.spi for
>>> the syntax of the spec
>>>
>>>           These options are non-standard and subject to change without
>>> notice.
>>>
>>> Where the jdk.jshell.spi javadocs are now:
>>>
>>> http://cr.openjdk.java.net/~rfield/8168615v1.jshellAPI/jdk/jshell/spi/package-summary.html
>>>
>>>
>>>
>>> It is OK that they would need to reference the SPI docs because if they
>>> implemented an execution engine they would have implemented these
>>> interfaces,  If they are just tweaking parameters (and this isn't
>>> something we want a typical user to do) they would need to be familiar
>>> with the parameters, which are described in these docs.
>>
>> Still not sure if it is polite to not provide enough information for
>> the user to construct the option, but OK.
>
> The SPI is and documents the interface, so it doesn't seem an ideal
> place to document the set of current implementations -- though, by
> example, it demonstrates specs for all the predefined providers and
> almost all of the their parameters.
>
> The only reason this is here or interesting is if they are defining
> their own execution engine, in which case they need to be familiar.
>
> In fact, I'm negatively inclined to have the average users throwing
> random spec strings at it and submitting bugs when they get failures.
>
>
>>
>>>
>>>
>>>>
>>>> -I would reorganize the rules in the spec grammar to go from the top
>>>> down:
>>>> +     * spec := name : params
>>>> +     *       | name
>>>> +     * name := id
>>>> +     * params := param , params
>>>> +     *        | param
>>>> +     *        |
>>>> +     * param := id ( value )
>>>>
>>>> (might be also good to say what is "id")
>>>
>>> Both good ideas implemented in the above.
>>>
>>>>
>>>> -ExecutionControlProvider.logMessages seems weird. Is it used outside
>>>> of tests?
>>>
>>> Not currently, but we really need logging of failures and failover to
>>> track-down rare intermittent issues.  Adding logging is out of scope for
>>> 9, but this gives a needed hook.
>>
>> So, why not use a logging framework (e.g. System.getLogger) for logging?
>
> Fair enough.  I've switched to the logging framework and removed
> ExecutionControlProvider.logMessages.
>
> http://cr.openjdk.java.net/~rfield/8168615v2.jshellAPI/jdk/jshell/spi/ExecutionControlProvider.html
>
>
> http://cr.openjdk.java.net/~rfield/8168615v2.webrev/src/jdk.jshell/share/classes/jdk/jshell/execution/FailOverExecutionControlProvider.java.html
>
> http://cr.openjdk.java.net/~rfield/8168615v2.webrev/test/jdk/jshell/FailOverDirectExecutionControlTest.java.html
>
>
>>
>>>
>>>>
>>>> -after this patch, both the ExecutionControls and their Providers are
>>>> public - is that desirable? Is there a usecase for the client to
>>>> call/instantiate the Providers directly without going through the
>>>> ServiceLoader?
>>>
>>> The ExecutionControls were public before.  jdk.jshell.execution contains
>>> the default execution engines, but it is exposed because it is a library
>>> of classes for implementing ExecutionControl (and now
>>> ExecutionControlProvider).
>>
>> What is the usecase for having the LocalExecutionControlProvider,
>> JdiExecutionControlProvider and FailOverExecutionControlProvider public?
>
> jdk.jshell.execution is for public implementations of the jdk.jshell.spi
> interfaces, and those interfaces now include ExecutionControlProvider,
> basically replacing ExecutionControl.Generator.
>
> JdiDefaultExecutionControl or JdiExecutionControl are designed to
> function as both standard implementation and subclassable code for
> constructing new execution engines.  The provider is the face of this
> body, it would seem strange to expose the body and not the face.  For
> example, JdiExecutionControlProvider, were JdiDefaultExecutionControl
> subclassed, it would need a provider -- the obvious choice would be to
> subclass  JdiExecutionControlProvider changng out the ExecutionControl
> implementation and retaining the rest of the provider functionality.
>
> The subclassing is far less compelling for LocalExecutionControlProvider
> since both its methods would need to be overridden.
>
> For each of them, this is where the parameters are specified -- so they
> need to be in public documentation.  Given that though,
> defaultParameters() should be overriden in LocalExecutionControlProvider
> to specify there are no parameters.
>
> http://cr.openjdk.java.net/~rfield/8168615v2.jshellAPI/jdk/jshell/execution/LocalExecutionControlProvider.html#defaultParameters--
>
>
> -Robert
>
>>
>> Jan
>>
>>>
>>> The SPI and the jdk.jshell.execution library were created because of a
>>> request from an IDE developer.
>>>
>>> OK, here is the new version.  No executable code was changed, but I've
>>> spruced-up the documentation, including what is mentioned above.
>>>
>>> The docs:
>>>
>>>      http://cr.openjdk.java.net/~rfield/8168615v1.jshellAPI/
>>>
>>> Specdiff:
>>>
>>> http://cr.openjdk.java.net/~rfield/8168615v1.specdiff/overview-summary.html
>>>
>>>
>>> New webrev:
>>>
>>>      http://cr.openjdk.java.net/~rfield/8168615v1.webrev/
>>>
>>> -Robert
>>>
>>>>
>>>> Jan
>>>>
>>>> On 2.12.2016 08:48, Robert Field wrote:
>>>>> Please review...
>>>>>
>>>>> Bug:
>>>>>
>>>>>       https://bugs.openjdk.java.net/browse/JDK-8168615
>>>>>
>>>>>
>>>>> Webrev:
>>>>>
>>>>>      http://cr.openjdk.java.net/~rfield/8168615v0.webrev/
>>>>>
>>>>> Thanks,
>>>>> Robert
>>>>>
>>>
>

From robert.field at oracle.com  Thu Dec 15 07:31:51 2016
From: robert.field at oracle.com (Robert Field)
Date: Wed, 14 Dec 2016 23:31:51 -0800
Subject: RFR 8170162: jshell tool: no mechanism to programmatically launch
In-Reply-To: <584B8439.80306@oracle.com>
References: <583A0A5B.6050100@oracle.com>	<5848CA74.3070405@oracle.com>	<5848E10F.8000108@oracle.com>	<58497E4A.5070707@oracle.com>	<584A28F5.9010107@oracle.com>
	<584B8439.80306@oracle.com>
Message-ID: <585246E7.3050206@oracle.com>

Feedback on v2 was that the features it had for supporting 
javax.tools.Tool shouldn't be there without that support in-place.
So, v3.  I'm including that support (8170044).

Bugs:

     8170044: jshell tool: jshell missing from javax.tools.ToolProvider
     https://bugs.openjdk.java.net/browse/JDK-8170044

     8170162: jshell tool: no mechanism to programmatically launch
     https://bugs.openjdk.java.net/browse/JDK-8170162

Sub-Tasks (tiny tweaks to other repos):

     8170194: jshell tool (jdk repo): launch tool from JShellToolProvider
     https://bugs.openjdk.java.net/browse/JDK-8170194

     8170195: jshell tool (make): update javadoc generation for jdk.jshell
     https://bugs.openjdk.java.net/browse/JDK-8170195


API:
http://cr.openjdk.java.net/~rfield/8170162v3.jshellAPI/

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

Specdiff:
http://cr.openjdk.java.net/~rfield/8170162v3.specdiff/overview-summary.html

The changes to the root workspace (in support of javadoc make) are 
unchanged since v1:
http://cr.openjdk.java.net/~rfield/8170195v1.webrev/make/Javadoc.gmk.sdiff.html

The change to the jdk workspace (in support of launching) is unchanged 
from the original v0:
http://cr.openjdk.java.net/~rfield/8170194v0.webrev/make/launcher/Launcher-jdk.jshell.gmk.sdiff.html


Discussion --

Addition of javax.tools.Tool support is straight-forward:

http://cr.openjdk.java.net/~rfield/8170162v3.jshellAPI/jdk.jshell-summary.html

http://cr.openjdk.java.net/~rfield/8170162v3.webrev/src/jdk.jshell/share/classes/module-info.java.sdiff.html
http://cr.openjdk.java.net/~rfield/8170162v3.webrev/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellToolProvider.java.html

New test was most of the work:
http://cr.openjdk.java.net/~rfield/8170162v3.webrev/test/jdk/jshell/ToolProviderTest.java.html
http://cr.openjdk.java.net/~rfield/8170162v3.webrev/test/jdk/jshell/StartOptionTest.java.sdiff.html



Discussion from v2 (amended) --

The simplest of the options below was chosen -- builder() factory on 
JavaShellToolBuilder.  JavaShellToolProvider has been removed.
http://cr.openjdk.java.net/~rfield/8170162v3.jshellAPI/jdk/jshell/tool/package-summary.html

The uses/provides changes to module-info.java have been removed, leaving 
the addition of "exports jdk.jshell.tool", and, to work with the 
merged-in jigsaw, the java.prefs requires is now transitive.

.... now all jshell tool launching is channeled through the builder 
(rather than entering via JShellTool).

Note: specdiff doesn't see the changes to overview.html (removal) and 
module docs

Thanks,
Robert


From jonathan.gibbons at oracle.com  Fri Dec 16 19:50:04 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 16 Dec 2016 11:50:04 -0800
Subject: RFR 8170162: jshell tool: no mechanism to programmatically launch
In-Reply-To: <585246E7.3050206@oracle.com>
References: <583A0A5B.6050100@oracle.com>	<5848CA74.3070405@oracle.com>	<5848E10F.8000108@oracle.com>	<58497E4A.5070707@oracle.com>	<584A28F5.9010107@oracle.com>	<584B8439.80306@oracle.com>
	<585246E7.3050206@oracle.com>
Message-ID: <5854456C.4060100@oracle.com>

The v3 support for launching the tool looks OK.  The name 
JShellToolProvider is a bit clunky, but it's an internal class (i.e. a 
class in an internal package) and you're running out of names, so it's 
OK, I guess.

-- Jon

On 12/14/2016 11:31 PM, Robert Field wrote:
> Feedback on v2 was that the features it had for supporting 
> javax.tools.Tool shouldn't be there without that support in-place.
> So, v3.  I'm including that support (8170044).
>
> Bugs:
>
>     8170044: jshell tool: jshell missing from javax.tools.ToolProvider
>     https://bugs.openjdk.java.net/browse/JDK-8170044
>
>     8170162: jshell tool: no mechanism to programmatically launch
>     https://bugs.openjdk.java.net/browse/JDK-8170162
>
> Sub-Tasks (tiny tweaks to other repos):
>
>     8170194: jshell tool (jdk repo): launch tool from JShellToolProvider
>     https://bugs.openjdk.java.net/browse/JDK-8170194
>
>     8170195: jshell tool (make): update javadoc generation for jdk.jshell
>     https://bugs.openjdk.java.net/browse/JDK-8170195
>
>
> API:
> http://cr.openjdk.java.net/~rfield/8170162v3.jshellAPI/
>
> Webrev:
> http://cr.openjdk.java.net/~rfield/8170162v3.webrev/
>
> Specdiff:
> http://cr.openjdk.java.net/~rfield/8170162v3.specdiff/overview-summary.html 
>
>
> The changes to the root workspace (in support of javadoc make) are 
> unchanged since v1:
> http://cr.openjdk.java.net/~rfield/8170195v1.webrev/make/Javadoc.gmk.sdiff.html 
>
>
> The change to the jdk workspace (in support of launching) is unchanged 
> from the original v0:
> http://cr.openjdk.java.net/~rfield/8170194v0.webrev/make/launcher/Launcher-jdk.jshell.gmk.sdiff.html 
>
>
>
> Discussion --
>
> Addition of javax.tools.Tool support is straight-forward:
>
> http://cr.openjdk.java.net/~rfield/8170162v3.jshellAPI/jdk.jshell-summary.html 
>
>
> http://cr.openjdk.java.net/~rfield/8170162v3.webrev/src/jdk.jshell/share/classes/module-info.java.sdiff.html 
>
> http://cr.openjdk.java.net/~rfield/8170162v3.webrev/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellToolProvider.java.html 
>
>
> New test was most of the work:
> http://cr.openjdk.java.net/~rfield/8170162v3.webrev/test/jdk/jshell/ToolProviderTest.java.html 
>
> http://cr.openjdk.java.net/~rfield/8170162v3.webrev/test/jdk/jshell/StartOptionTest.java.sdiff.html 
>
>
>
>
> Discussion from v2 (amended) --
>
> The simplest of the options below was chosen -- builder() factory on 
> JavaShellToolBuilder.  JavaShellToolProvider has been removed.
> http://cr.openjdk.java.net/~rfield/8170162v3.jshellAPI/jdk/jshell/tool/package-summary.html 
>
>
> The uses/provides changes to module-info.java have been removed, 
> leaving the addition of "exports jdk.jshell.tool", and, to work with 
> the merged-in jigsaw, the java.prefs requires is now transitive.
>
> .... now all jshell tool launching is channeled through the builder 
> (rather than entering via JShellTool).
>
> Note: specdiff doesn't see the changes to overview.html (removal) and 
> module docs
>
> Thanks,
> Robert
>


From robert.field at oracle.com  Fri Dec 23 06:00:38 2016
From: robert.field at oracle.com (Robert Field)
Date: Thu, 22 Dec 2016 22:00:38 -0800
Subject: RFR 8171892: JShell: incorrect printing of multidemensional arrays
Message-ID: <585CBD86.6010401@oracle.com>

Please review...

Bugs:

     8171892: JShell: incorrect printing of multidemensional arrays
     https://bugs.openjdk.java.net/browse/JDK-8171892

     8171387: jshell tool: message inconsistencies
     https://bugs.openjdk.java.net/browse/JDK-8171387

Webrev:

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

Thanks,
Robert


From sundararajan.athijegannathan at oracle.com  Fri Dec 23 07:31:22 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 23 Dec 2016 13:01:22 +0530
Subject: RFR 8171892: JShell: incorrect printing of multidemensional arrays
In-Reply-To: <585CBD86.6010401@oracle.com>
References: <585CBD86.6010401@oracle.com>
Message-ID: <a79b3111-b107-02d2-991e-b5b3cb9dbcf0@oracle.com>

+1


On 12/23/2016 11:30 AM, Robert Field wrote:
> Please review...
>
> Bugs:
>
>     8171892: JShell: incorrect printing of multidemensional arrays
>     https://bugs.openjdk.java.net/browse/JDK-8171892
>
>     8171387: jshell tool: message inconsistencies
>     https://bugs.openjdk.java.net/browse/JDK-8171387
>
> Webrev:
>
>     http://cr.openjdk.java.net/~rfield/8171892v0.webrev/
>
> Thanks,
> Robert
>


From daniel.smith at oracle.com  Fri Dec 23 17:21:47 2016
From: daniel.smith at oracle.com (Dan Smith)
Date: Fri, 23 Dec 2016 10:21:47 -0700
Subject: RFR 8171892: JShell: incorrect printing of multidemensional arrays
In-Reply-To: <585CBD86.6010401@oracle.com>
References: <585CBD86.6010401@oracle.com>
Message-ID: <62F78F24-C43A-4FD4-A66D-738D14A92936@oracle.com>

> On Dec 22, 2016, at 11:00 PM, Robert Field <robert.field at oracle.com> wrote:
> 
> Please review...
> 
> Bugs:
> 
>    8171892: JShell: incorrect printing of multidemensional arrays
>    https://bugs.openjdk.java.net/browse/JDK-8171892
> 
>    8171387: jshell tool: message inconsistencies
>    https://bugs.openjdk.java.net/browse/JDK-8171387
> 
> Webrev:
> 
>    http://cr.openjdk.java.net/~rfield/8171892v0.webrev/
> 
> Thanks,
> Robert
> 

Looks good, thanks for fixing.

(If you need an OpenJDK Reviewer, BTW, I am not one. Looks like Sundar is, though.)

?Dan

From robert.field at oracle.com  Fri Dec 30 18:08:12 2016
From: robert.field at oracle.com (Robert Field)
Date: Fri, 30 Dec 2016 10:08:12 -0800
Subject: RFR 8172102: jshell tool: remove print method forwarding to System.out
	from default startup
Message-ID: <5866A28C.6050407@oracle.com>

Please review...

Bug:

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

Webrev:

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

Thanks,
Robert


From brian.goetz at oracle.com  Fri Dec 30 18:17:33 2016
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 30 Dec 2016 13:17:33 -0500
Subject: RFR 8172102: jshell tool: remove print method forwarding to
	System.out from default startup
In-Reply-To: <5866A28C.6050407@oracle.com>
References: <5866A28C.6050407@oracle.com>
Message-ID: <6b159d4c-8398-56f1-7062-9fbb6b027682@oracle.com>

I think the use of path syntax here is a bit of an abuse.  Typically, a 
path A:B represents a search path; first look in A, and then, if not 
found, look in B.  But what you want to indicate is that we should 
process A *and* B at startup; this isn't a path.

Unfortunately, there's not a universally accepted "and" character, where 
you could say "A,B" or "A+B" that people would immediately grok.  So 
better to use repeated flags:

     jshell --startup A --startup B

which is a bit verbose, but I think is more standard.

I'd also prefer to see the standard startup be an actual, checked-in 
file called something like resources/DEFAULT.jsh, which is placed in the 
output directory alongside classfiles through the usual build mechanics, 
rather than living in code.  I don't see that in the webrev?



On 12/30/2016 1:08 PM, Robert Field wrote:
> Please review...
>
> Bug:
>
>     https://bugs.openjdk.java.net/browse/JDK-8172102
>
> Webrev:
>
>     http://cr.openjdk.java.net/~rfield/8172102v0.webrev/
>
> Thanks,
> Robert
>


From robert.field at oracle.com  Fri Dec 30 18:35:55 2016
From: robert.field at oracle.com (Robert Field)
Date: Fri, 30 Dec 2016 10:35:55 -0800
Subject: RFR 8172102: jshell tool: remove print method forwarding to
	System.out from default startup
In-Reply-To: <6b159d4c-8398-56f1-7062-9fbb6b027682@oracle.com>
References: <5866A28C.6050407@oracle.com>
	<6b159d4c-8398-56f1-7062-9fbb6b027682@oracle.com>
Message-ID: <5866A90B.1010403@oracle.com>

My bad.  I didn't check in the new files.  The standard startups are 
checked-in files.  Here is the new webrev:

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

-Robert



On 12/30/16 10:17, Brian Goetz wrote:
> I think the use of path syntax here is a bit of an abuse.  Typically, 
> a path A:B represents a search path; first look in A, and then, if not 
> found, look in B.  But what you want to indicate is that we should 
> process A *and* B at startup; this isn't a path.
>
> Unfortunately, there's not a universally accepted "and" character, 
> where you could say "A,B" or "A+B" that people would immediately 
> grok.  So better to use repeated flags:
>
>     jshell --startup A --startup B
>
> which is a bit verbose, but I think is more standard.
>
> I'd also prefer to see the standard startup be an actual, checked-in 
> file called something like resources/DEFAULT.jsh, which is placed in 
> the output directory alongside classfiles through the usual build 
> mechanics, rather than living in code.  I don't see that in the webrev?
>
>
>
> On 12/30/2016 1:08 PM, Robert Field wrote:
>> Please review...
>>
>> Bug:
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8172102
>>
>> Webrev:
>>
>>     http://cr.openjdk.java.net/~rfield/8172102v0.webrev/
>>
>> Thanks,
>> Robert
>>
>


From robert.field at oracle.com  Fri Dec 30 20:34:03 2016
From: robert.field at oracle.com (Robert Field)
Date: Fri, 30 Dec 2016 12:34:03 -0800
Subject: RFR 8172102: jshell tool: remove print method forwarding to
	System.out from default startup
In-Reply-To: <6b159d4c-8398-56f1-7062-9fbb6b027682@oracle.com>
References: <5866A28C.6050407@oracle.com>
	<6b159d4c-8398-56f1-7062-9fbb6b027682@oracle.com>
Message-ID: <5866C4BB.5080806@oracle.com>

Thanks for the comments!

Addressing the concerns....

Use of path-separator removed.  Now multiple uses of --startup.
Make changes (sub-task) included below.
Dynamically generated includes removed.  Fixed JAVASE added.
JDK 10 bug added for build-time generation:
        https://bugs.openjdk.java.net/browse/JDK-8172154

Main bug::
     jshell tool: remove print method forwarding to System.out from 
default startup
     https://bugs.openjdk.java.net/browse/JDK-8172102

Sub-task bug:
     jshell tool (make): include built-in startup scripts in image
     https://bugs.openjdk.java.net/browse/JDK-8172155

Langtools webrev:
     http://cr.openjdk.java.net/~rfield/8172102v2.webrev/

Top level webrev:
http://cr.openjdk.java.net/~rfield/8172155v2.webrev/make/CompileJavaModules.gmk.sdiff.html

-Robert

On 12/30/16 10:17, Brian Goetz wrote:
> I think the use of path syntax here is a bit of an abuse.  Typically, 
> a path A:B represents a search path; first look in A, and then, if not 
> found, look in B.  But what you want to indicate is that we should 
> process A *and* B at startup; this isn't a path.
>
> Unfortunately, there's not a universally accepted "and" character, 
> where you could say "A,B" or "A+B" that people would immediately 
> grok.  So better to use repeated flags:
>
>     jshell --startup A --startup B
>
> which is a bit verbose, but I think is more standard.
>
> I'd also prefer to see the standard startup be an actual, checked-in 
> file called something like resources/DEFAULT.jsh, which is placed in 
> the output directory alongside classfiles through the usual build 
> mechanics, rather than living in code.  I don't see that in the webrev?
>