From robert.field at oracle.com  Wed Jun  1 16:01:43 2016
From: robert.field at oracle.com (Robert Field)
Date: Wed, 01 Jun 2016 09:01:43 -0700
Subject: RFR 8131029: JShell: recover from VMConnection launch failure
Message-ID: <574F06E7.9000605@oracle.com>

Please review --

Attempt recovery from launch failure caused by either rare intermittent 
JDI failures or bad configurations by using an alternative connection 
and process-creation mechanism.
Necessitated a clean-up of the JShell JDI code: removed JDIEnv which 
provided no useful abstraction, coalescing the JDI connection 
functionality in JDIConnection;
remove unused and commented-out code from that class.
Add a meta-ExecutionControl class, FailOverExecutionControl, which 
cycles through ExecutionControl instances until one starts.

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

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

Thanks,
Robert


From robert.field at oracle.com  Thu Jun  2 00:26:26 2016
From: robert.field at oracle.com (Robert Field)
Date: Wed, 01 Jun 2016 17:26:26 -0700
Subject: RFR 8131024: JShell: multi-line comment not detected as incomplete
Message-ID: <574F7D32.4030209@oracle.com>

Please review...

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

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

Thanks,
Robert

[z]


From vicente.romero at oracle.com  Thu Jun  2 18:44:54 2016
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Thu, 2 Jun 2016 14:44:54 -0400
Subject: RFR 8131024: JShell: multi-line comment not detected as incomplete
In-Reply-To: <574F7D32.4030209@oracle.com>
References: <574F7D32.4030209@oracle.com>
Message-ID: <57507EA6.1010904@oracle.com>

accepted,

Thanks,
Vicente

On 06/01/2016 08:26 PM, Robert Field wrote:
> Please review...
>
> Bug:
>     https://bugs.openjdk.java.net/browse/JDK-8131024
>
> Webrev:
>     http://cr.openjdk.java.net/~rfield/8131024v0.webrev/
>
> Thanks,
> Robert
>
> [z]
>


From vicente.romero at oracle.com  Thu Jun  2 20:07:10 2016
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Thu, 2 Jun 2016 16:07:10 -0400
Subject: RFR 8131029: JShell: recover from VMConnection launch failure
In-Reply-To: <574F06E7.9000605@oracle.com>
References: <574F06E7.9000605@oracle.com>
Message-ID: <575091EE.3000609@oracle.com>

Looks good,

Vicente

On 06/01/2016 12:01 PM, Robert Field wrote:
> Please review --
>
> Attempt recovery from launch failure caused by either rare 
> intermittent JDI failures or bad configurations by using an 
> alternative connection and process-creation mechanism.
> Necessitated a clean-up of the JShell JDI code: removed JDIEnv which 
> provided no useful abstraction, coalescing the JDI connection 
> functionality in JDIConnection;
> remove unused and commented-out code from that class.
> Add a meta-ExecutionControl class, FailOverExecutionControl, which 
> cycles through ExecutionControl instances until one starts.
>
> Bug:
>     https://bugs.openjdk.java.net/browse/JDK-8131029
>
> Webrev:
>     http://cr.openjdk.java.net/~rfield/8131029v0.webrev/
>
> Thanks,
> Robert
>


From robert.field at oracle.com  Fri Jun  3 22:59:12 2016
From: robert.field at oracle.com (Robert Field)
Date: Fri, 03 Jun 2016 15:59:12 -0700
Subject: RFR 8139829: JShell API: No use of fields to return information from
	public types
Message-ID: <57520BC0.7060202@oracle.com>

Please review....

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

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

Webrev before (per Joe's suggestion) I changed all <code>abc</code> to 
{@code abc}which introduces a lot of noise in the webrev:
      http://cr.openjdk.java.net/~rfield/8139829v0.webrev/

The generate API docs:
      http://cr.openjdk.java.net/~rfield/jshell/

Thanks,
Robert


From vicente.romero at oracle.com  Sat Jun  4 16:54:04 2016
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Sat, 4 Jun 2016 12:54:04 -0400
Subject: RFR 8139829: JShell API: No use of fields to return information
	from public types
In-Reply-To: <57520BC0.7060202@oracle.com>
References: <57520BC0.7060202@oracle.com>
Message-ID: <575307AC.5030200@oracle.com>

accepted *v1.webrev

Thanks,
Vicente

On 06/03/2016 06:59 PM, Robert Field wrote:
> Please review....
>
> Bug:
>     https://bugs.openjdk.java.net/browse/JDK-8139829
>
> Webrev:
>      http://cr.openjdk.java.net/~rfield/8139829v1.webrev/
>
> Webrev before (per Joe's suggestion) I changed all <code>abc</code> to 
> {@code abc}which introduces a lot of noise in the webrev:
>      http://cr.openjdk.java.net/~rfield/8139829v0.webrev/
>
> The generate API docs:
>      http://cr.openjdk.java.net/~rfield/jshell/
>
> Thanks,
> Robert
>


From jan.lahoda at oracle.com  Wed Jun  8 17:00:22 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 8 Jun 2016 19:00:22 +0200
Subject: RFR 8158174: jshell tool: leaks threads waiting on
	StopDetectingInputStream
Message-ID: <57584F26.8050300@oracle.com>

Hello,

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

Webrev:
http://cr.openjdk.java.net/~jlahoda/8158174/webrev/index.html

The fix is to stop the StopDetectingInputStream when closing the 
ConsoleIOContext. I chose "shutdown" for the name of the method, mostly 
to be consistent with ConsoleReader.shutdown().

Any feedback is welcome!

Thanks,
     Jan

From robert.field at oracle.com  Wed Jun  8 17:26:39 2016
From: robert.field at oracle.com (Robert Field)
Date: Wed, 8 Jun 2016 10:26:39 -0700
Subject: RFR 8158174: jshell tool: leaks threads waiting on
	StopDetectingInputStream
In-Reply-To: <57584F26.8050300@oracle.com>
References: <57584F26.8050300@oracle.com>
Message-ID: <AFB1B5D1-BB65-481A-8ED4-7B7A59C515EF@oracle.com>

Thumbs up.

Welcome back!

-Robert


> On Jun 8, 2016, at 10:00 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:
> 
> Hello,
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8158174
> 
> Webrev:
> http://cr.openjdk.java.net/~jlahoda/8158174/webrev/index.html
> 
> The fix is to stop the StopDetectingInputStream when closing the ConsoleIOContext. I chose "shutdown" for the name of the method, mostly to be consistent with ConsoleReader.shutdown().
> 
> Any feedback is welcome!
> 
> Thanks,
>    Jan


From robert.field at oracle.com  Thu Jun 16 18:39:05 2016
From: robert.field at oracle.com (Robert Field)
Date: Thu, 16 Jun 2016 11:39:05 -0700
Subject: RFR 8159111: JShell API: Add access to wrappers and dependencies
Message-ID: <5762F249.3070909@oracle.com>

Please review --

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

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

Spec:
     http://cr.openjdk.java.net/~rfield/jshell_8159111/

     Specifically --
http://cr.openjdk.java.net/~rfield/jshell_8159111/jdk/jshell/SourceCodeAnalysis.SnippetWrapper.html
http://cr.openjdk.java.net/~rfield/jshell_8159111/jdk/jshell/SourceCodeAnalysis.html#wrapper-jdk.jshell.Snippet-
http://cr.openjdk.java.net/~rfield/jshell_8159111/jdk/jshell/SourceCodeAnalysis.html#wrappers-java.lang.String-
http://cr.openjdk.java.net/~rfield/jshell_8159111/jdk/jshell/SourceCodeAnalysis.html#dependents-jdk.jshell.Snippet-
http://cr.openjdk.java.net/~rfield/jshell_8159111/jdk/jshell/ErroneousSnippet.html#probableKind--

Thanks,
Robert


From robert.field at oracle.com  Sat Jun 18 06:40:41 2016
From: robert.field at oracle.com (Robert Field)
Date: Fri, 17 Jun 2016 23:40:41 -0700
Subject: RFR 8159635: JShell API: Set compiler options
Message-ID: <5764ECE9.1070501@oracle.com>

Please review --

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

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

Spec:
     http://cr.openjdk.java.net/~rfield/jshell_8159635/

     Specifically:
http://cr.openjdk.java.net/~rfield/jshell_8159635/jdk/jshell/JShell.Builder.html#compilerOptions-java.lang.String...-

Thanks,
Robert


From jan.lahoda at oracle.com  Mon Jun 20 12:17:56 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 20 Jun 2016 14:17:56 +0200
Subject: RFR 8159111: JShell API: Add access to wrappers and dependencies
In-Reply-To: <5762F249.3070909@oracle.com>
References: <5762F249.3070909@oracle.com>
Message-ID: <5767DEF4.2040304@oracle.com>

Seem OK to me.

Jan

On 16.6.2016 20:39, Robert Field wrote:
> Please review --
>
> Bug:
>      https://bugs.openjdk.java.net/browse/JDK-8159111
>
> Webrev:
>      http://cr.openjdk.java.net/~rfield/8159111v0.webrev/
>
> Spec:
>      http://cr.openjdk.java.net/~rfield/jshell_8159111/
>
>      Specifically --
> http://cr.openjdk.java.net/~rfield/jshell_8159111/jdk/jshell/SourceCodeAnalysis.SnippetWrapper.html
>
> http://cr.openjdk.java.net/~rfield/jshell_8159111/jdk/jshell/SourceCodeAnalysis.html#wrapper-jdk.jshell.Snippet-
>
> http://cr.openjdk.java.net/~rfield/jshell_8159111/jdk/jshell/SourceCodeAnalysis.html#wrappers-java.lang.String-
>
> http://cr.openjdk.java.net/~rfield/jshell_8159111/jdk/jshell/SourceCodeAnalysis.html#dependents-jdk.jshell.Snippet-
>
> http://cr.openjdk.java.net/~rfield/jshell_8159111/jdk/jshell/ErroneousSnippet.html#probableKind--
>
>
> Thanks,
> Robert
>

From jan.lahoda at oracle.com  Mon Jun 20 13:07:07 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 20 Jun 2016 15:07:07 +0200
Subject: RFR 8159635: JShell API: Set compiler options
In-Reply-To: <5764ECE9.1070501@oracle.com>
References: <5764ECE9.1070501@oracle.com>
Message-ID: <5767EA7B.8090904@oracle.com>

Hi,

A few comments:
-should these extra options also be used by AnalyzeTasks created by 
SourceCodeAnalysisImpl? I am not sure if the options we expect people to 
set could have impact e.g. on the tab completion.
-JShell.Builder.compilerOptions says:
Sets additional compiler options for generating bytecode.

But it adds the new options to the list - it might be better to say 
"Adds additional ..." or "Appends additional compiler options..." so 
that it is clearer it won't clear options that were set before. (I am 
also thinking if the method should be "addCompilerOptions", but given 
the other methods are not prefixed with "set", "add" is probably not 
necessary.)

Jan

On 18.6.2016 08:40, Robert Field wrote:
> Please review --
>
> Bug:
>      https://bugs.openjdk.java.net/browse/JDK-8159635
>
> Webrev:
>      http://cr.openjdk.java.net/~rfield/8159635v0.webrev/
>
> Spec:
>      http://cr.openjdk.java.net/~rfield/jshell_8159635/
>
>      Specifically:
> http://cr.openjdk.java.net/~rfield/jshell_8159635/jdk/jshell/JShell.Builder.html#compilerOptions-java.lang.String...-
>
>
> Thanks,
> Robert
>

From robert.field at oracle.com  Mon Jun 20 23:56:12 2016
From: robert.field at oracle.com (Robert Field)
Date: Mon, 20 Jun 2016 16:56:12 -0700
Subject: RFR 8159635: JShell API: Set compiler options
In-Reply-To: <5767EA7B.8090904@oracle.com>
References: <5764ECE9.1070501@oracle.com> <5767EA7B.8090904@oracle.com>
Message-ID: <5768829C.4070408@oracle.com>

I've updated the docs and changed the added options to be applied 
uniformly.  The latter causes code simplification.

Please review V1 --

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

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

Spec:
      http://cr.openjdk.java.net/~rfield/jshell_8159635v1/

      Specifically:
http://cr.openjdk.java.net/~rfield/jshell_8159635v1/jdk/jshell/JShell.Builder.html#compilerOptions-java.lang.String...-

Thanks,
Robert


On 06/20/16 06:07, Jan Lahoda wrote:
> Hi,
>
> A few comments:
> -should these extra options also be used by AnalyzeTasks created by 
> SourceCodeAnalysisImpl? I am not sure if the options we expect people 
> to set could have impact e.g. on the tab completion.
> -JShell.Builder.compilerOptions says:
> Sets additional compiler options for generating bytecode.
>
> But it adds the new options to the list - it might be better to say 
> "Adds additional ..." or "Appends additional compiler options..." so 
> that it is clearer it won't clear options that were set before. (I am 
> also thinking if the method should be "addCompilerOptions", but given 
> the other methods are not prefixed with "set", "add" is probably not 
> necessary.)
>
> Jan
>
> On 18.6.2016 08:40, Robert Field wrote:
>> Please review --
>>
>> Bug:
>>      https://bugs.openjdk.java.net/browse/JDK-8159635
>>
>> Webrev:
>>      http://cr.openjdk.java.net/~rfield/8159635v0.webrev/
>>
>> Spec:
>>      http://cr.openjdk.java.net/~rfield/jshell_8159635/
>>
>>      Specifically:
>> http://cr.openjdk.java.net/~rfield/jshell_8159635/jdk/jshell/JShell.Builder.html#compilerOptions-java.lang.String...- 
>>
>>
>>
>> Thanks,
>> Robert
>>


From robert.field at oracle.com  Tue Jun 21 02:48:54 2016
From: robert.field at oracle.com (Robert Field)
Date: Mon, 20 Jun 2016 19:48:54 -0700
Subject: RFR 8159935:JShell API: Reorganize execution support code into
	jdk.jshell.execution
Message-ID: <5768AB16.4050207@oracle.com>

In preparation for defining the execution engine library, consolidate 
jdk.internal.jshell.jdi and jdk.internal.jshell.remote as the base of 
the JDI execution control implementation library.

Only the file/class moves and corresponding renames and adjustments are 
included.  The jdk.jshell.execution package is added to module-info 
because, with this, it is exported.  These changes are broken out as a 
separate step to facilitate review.  Will be pushed with its parent issue.

Please review.

Bug:
      8159935:JShell API: Reorganize execution support code into 
jdk.jshell.execution
      https://bugs.openjdk.java.net/browse/JDK-8159935

Parent bug:
      8159118: JShell API: Provide abstract and concrete implementations 
of ExecutionControl SPI
      https://bugs.openjdk.java.net/browse/JDK-8159118

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

Thanks,
Robert


From ljw1001 at gmail.com  Tue Jun 21 04:32:53 2016
From: ljw1001 at gmail.com (Larry White)
Date: Tue, 21 Jun 2016 00:32:53 -0400
Subject: A question on functionality
Message-ID: <CAMdbzVhJAG6VGPt_x_hcjr0_U9UeH-CPnHa=GCiKww4BinGRgw@mail.gmail.com>

My apologies in advance if this is the wrong forum. If there's a better
place for this kind of question, please let me know.

Will it be possible to open a window (Swing or JavaFX) from the REPL
initialized with data from the REPL? I'm specifically asking about the
ability to initialize it with arbitrary data (as opposed to a string array
passed through main() or the JavaFX launch() method).

Alternately, will there be a way to open a window such that the method
called to open it, returns a reference that can be used to pass data that
can be displayed?

My use case is to manipulate some data, then open a window to display a
plot, as is common in an R or Python REPL.

Thank you very much.

larry

From bitterfoxc at gmail.com  Tue Jun 21 05:05:25 2016
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Tue, 21 Jun 2016 14:05:25 +0900
Subject: A question on functionality
In-Reply-To: <CAMdbzVhJAG6VGPt_x_hcjr0_U9UeH-CPnHa=GCiKww4BinGRgw@mail.gmail.com>
References: <CAMdbzVhJAG6VGPt_x_hcjr0_U9UeH-CPnHa=GCiKww4BinGRgw@mail.gmail.com>
Message-ID: <CAHjBcHP7WSarRmAt+JGD6SbFpjvAzam-GfgK-1Cgt211yc5ATQ@mail.gmail.com>

Hi Larry,
You can open the window with Swing directly using the plain jshell.
(But it will not executed in the Swing thread, so you should be careful!)

For the JavaFX, you cannot execute it from plain jshell, due to JavaFX
checks that it's already initialized and executed from the JavaFX thread as
you pointed out.
Please use jfxshell which is the extension tool of jshell and can execute
JavaFX code:
https://bitbucket.org/bitter_fox/jfxshell/overview

In the following example, using jdk9b122.

$ wget https://bitbucket.org/bitter_fox/jfxshell/downloads/jfxshellb122.zip
$ unzip jfxshellb122.zip

$ PATH/TO/jdk9b122/bin/java -Xpatch:jdk.jshell=jfxshellb122/jdk.jshell -m
jdk.jshell/jdk.internal.jshell.tool.JShellTool
|  Welcome to JShell -- Version 9-ea
|  For an introduction type: /help intro

jshell> Stage s = new Stage()
s ==> javafx.stage.Stage at 1d29cf23

jshell> s.show() // the window will be opened

jshell>

Regards,
shinyafox(Shinya Yoshida)


2016-06-21 13:32 GMT+09:00 Larry White <ljw1001 at gmail.com>:

> My apologies in advance if this is the wrong forum. If there's a better
> place for this kind of question, please let me know.
>
> Will it be possible to open a window (Swing or JavaFX) from the REPL
> initialized with data from the REPL? I'm specifically asking about the
> ability to initialize it with arbitrary data (as opposed to a string array
> passed through main() or the JavaFX launch() method).
>
> Alternately, will there be a way to open a window such that the method
> called to open it, returns a reference that can be used to pass data that
> can be displayed?
>
> My use case is to manipulate some data, then open a window to display a
> plot, as is common in an R or Python REPL.
>
> Thank you very much.
>
> larry
>

From robert.field at oracle.com  Tue Jun 21 05:11:09 2016
From: robert.field at oracle.com (Robert Field)
Date: Mon, 20 Jun 2016 22:11:09 -0700
Subject: A question on functionality
In-Reply-To: <CAMdbzVhJAG6VGPt_x_hcjr0_U9UeH-CPnHa=GCiKww4BinGRgw@mail.gmail.com>
References: <CAMdbzVhJAG6VGPt_x_hcjr0_U9UeH-CPnHa=GCiKww4BinGRgw@mail.gmail.com>
Message-ID: <155715e89c8.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>

I'm afraid I don't understand your question. You can evaluate any code that 
you can evaluate in Java. The code evaluates on a fixed thread , which is 
an issue for JavaFX but not Swing. And the event dispatch thread issue will 
be resolved.

Can you give an example of what is not working.

Robert



On June 20, 2016 9:33:01 PM Larry White <ljw1001 at gmail.com> wrote:

> My apologies in advance if this is the wrong forum. If there's a better
> place for this kind of question, please let me know.
>
> Will it be possible to open a window (Swing or JavaFX) from the REPL
> initialized with data from the REPL? I'm specifically asking about the
> ability to initialize it with arbitrary data (as opposed to a string array
> passed through main() or the JavaFX launch() method).
>
> Alternately, will there be a way to open a window such that the method
> called to open it, returns a reference that can be used to pass data that
> can be displayed?
>
> My use case is to manipulate some data, then open a window to display a
> plot, as is common in an R or Python REPL.
>
> Thank you very much.
>
> larry



From ljw1001 at gmail.com  Tue Jun 21 09:35:06 2016
From: ljw1001 at gmail.com (Larry White)
Date: Tue, 21 Jun 2016 05:35:06 -0400
Subject: A question on functionality
In-Reply-To: <155715e89c8.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
References: <CAMdbzVhJAG6VGPt_x_hcjr0_U9UeH-CPnHa=GCiKww4BinGRgw@mail.gmail.com>
	<155715e89c8.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
Message-ID: <CAMdbzVjkZoezN9Qct8mHw+OVoOAA-N2ToNkRd6Wx6f9i0eT9GA@mail.gmail.com>

Hi Robert, and Yoshi,

What I was asking about specifically is this. In the R REPL, you can write
this:

> cars <- c(1, 3, 6, 4, 9)
> plot(cars)

And a window opens and renders a plot of the array 'cars'.

I want to be able to write a library with a static method plot() that does
the same thing.

I can't see how to do this using JavaFX without making the end user write a
class that implements Application and (in it's own code), creates the cars
array before calling launch. This is because (at the API level) the only
way to open an FX window from other java code is to call the static method

void launch(String[] args);

 which takes only a String[] and returns void.

What I *really* want to do, is pass 'cars' to webEngine and plot it in
Javascript. While I can wrap WebEngine in a Jframe, it seems that
initializing it ultimately has the same constraint, in that I cannot pass
it any non-string params. In other words, you have to write and launch an
application to open a window.

I will take a look at jfxframe and bitterfox, but wow, it seems very early.

thanks very much.

larry





On Tue, Jun 21, 2016 at 1:11 AM, Robert Field <robert.field at oracle.com>
wrote:

> I'm afraid I don't understand your question. You can evaluate any code
> that you can evaluate in Java. The code evaluates on a fixed thread , which
> is an issue for JavaFX but not Swing. And the event dispatch thread issue
> will be resolved.
>
> Can you give an example of what is not working.
>
> Robert
>
>
>
>
> On June 20, 2016 9:33:01 PM Larry White <ljw1001 at gmail.com> wrote:
>
> My apologies in advance if this is the wrong forum. If there's a better
>> place for this kind of question, please let me know.
>>
>> Will it be possible to open a window (Swing or JavaFX) from the REPL
>> initialized with data from the REPL? I'm specifically asking about the
>> ability to initialize it with arbitrary data (as opposed to a string array
>> passed through main() or the JavaFX launch() method).
>>
>> Alternately, will there be a way to open a window such that the method
>> called to open it, returns a reference that can be used to pass data that
>> can be displayed?
>>
>> My use case is to manipulate some data, then open a window to display a
>> plot, as is common in an R or Python REPL.
>>
>> Thank you very much.
>>
>> larry
>>
>
>
>

From jan.lahoda at oracle.com  Tue Jun 21 19:00:11 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 21 Jun 2016 21:00:11 +0200
Subject: RFR 8159635: JShell API: Set compiler options
In-Reply-To: <5768829C.4070408@oracle.com>
References: <5764ECE9.1070501@oracle.com> <5767EA7B.8090904@oracle.com>
	<5768829C.4070408@oracle.com>
Message-ID: <57698EBB.4070505@oracle.com>

Seems OK to me.

Jan

On 21.6.2016 01:56, Robert Field wrote:
> I've updated the docs and changed the added options to be applied
> uniformly.  The latter causes code simplification.
>
> Please review V1 --
>
> Bug:
>       https://bugs.openjdk.java.net/browse/JDK-8159635
>
> Webrev:
>       http://cr.openjdk.java.net/~rfield/8159635v1.webrev/
>
> Spec:
>       http://cr.openjdk.java.net/~rfield/jshell_8159635v1/
>
>       Specifically:
> http://cr.openjdk.java.net/~rfield/jshell_8159635v1/jdk/jshell/JShell.Builder.html#compilerOptions-java.lang.String...-
>
>
> Thanks,
> Robert
>
>
> On 06/20/16 06:07, Jan Lahoda wrote:
>> Hi,
>>
>> A few comments:
>> -should these extra options also be used by AnalyzeTasks created by
>> SourceCodeAnalysisImpl? I am not sure if the options we expect people
>> to set could have impact e.g. on the tab completion.
>> -JShell.Builder.compilerOptions says:
>> Sets additional compiler options for generating bytecode.
>>
>> But it adds the new options to the list - it might be better to say
>> "Adds additional ..." or "Appends additional compiler options..." so
>> that it is clearer it won't clear options that were set before. (I am
>> also thinking if the method should be "addCompilerOptions", but given
>> the other methods are not prefixed with "set", "add" is probably not
>> necessary.)
>>
>> Jan
>>
>> On 18.6.2016 08:40, Robert Field wrote:
>>> Please review --
>>>
>>> Bug:
>>>      https://bugs.openjdk.java.net/browse/JDK-8159635
>>>
>>> Webrev:
>>>      http://cr.openjdk.java.net/~rfield/8159635v0.webrev/
>>>
>>> Spec:
>>>      http://cr.openjdk.java.net/~rfield/jshell_8159635/
>>>
>>>      Specifically:
>>> http://cr.openjdk.java.net/~rfield/jshell_8159635/jdk/jshell/JShell.Builder.html#compilerOptions-java.lang.String...-
>>>
>>>
>>>
>>> Thanks,
>>> Robert
>>>
>

From robert.field at oracle.com  Wed Jun 22 18:42:34 2016
From: robert.field at oracle.com (Robert Field)
Date: Wed, 22 Jun 2016 11:42:34 -0700
Subject: RFR 8160009 / 8160035 : multi-package javadoc for JShell
Message-ID: <576ADC1A.4030803@oracle.com>

Please review these two interrelated bugs --

Bugs:

     8160009: JShell: Add SPI and execution to generated JShell javadoc 
(root ws)
     https://bugs.openjdk.java.net/browse/JDK-8160009

     8160035: JShell API: Add javadoc overview and package files
     https://bugs.openjdk.java.net/browse/JDK-8160035

Parent bug:

     8159118: JShell API: Provide abstract and concrete implementations 
of ExecutionControl SPI
     https://bugs.openjdk.java.net/browse/JDK-8159118

Webrevs:

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

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

Generate javadoc:

    http://cr.openjdk.java.net/~rfield/jshell_8160009/

Thanks,
Robert


From jan.lahoda at oracle.com  Thu Jun 23 20:51:31 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 23 Jun 2016 22:51:31 +0200
Subject: RFR 8160009 / 8160035 : multi-package javadoc for JShell
In-Reply-To: <576ADC1A.4030803@oracle.com>
References: <576ADC1A.4030803@oracle.com>
Message-ID: <576C4BD3.4090108@oracle.com>

To me, seems mostly fine. I wonder if RemoteCodes should be numerical 
constants - enum might be better (it could still have the numerical code 
inside).

Jan

On 22.6.2016 20:42, Robert Field wrote:
> Please review these two interrelated bugs --
>
> Bugs:
>
>      8160009: JShell: Add SPI and execution to generated JShell javadoc
> (root ws)
>      https://bugs.openjdk.java.net/browse/JDK-8160009
>
>      8160035: JShell API: Add javadoc overview and package files
>      https://bugs.openjdk.java.net/browse/JDK-8160035
>
> Parent bug:
>
>      8159118: JShell API: Provide abstract and concrete implementations
> of ExecutionControl SPI
>      https://bugs.openjdk.java.net/browse/JDK-8159118
>
> Webrevs:
>
>      Langtools
>      http://cr.openjdk.java.net/~rfield/8160035v0.webrev/
>
>      Root
>      http://cr.openjdk.java.net/~rfield/8160009v0.webrev/
>
> Generate javadoc:
>
>     http://cr.openjdk.java.net/~rfield/jshell_8160009/
>
> Thanks,
> Robert
>

From robert.field at oracle.com  Thu Jun 23 21:11:13 2016
From: robert.field at oracle.com (Robert Field)
Date: Thu, 23 Jun 2016 14:11:13 -0700
Subject: RFR 8160009 / 8160035 : multi-package javadoc for JShell
In-Reply-To: <576C4BD3.4090108@oracle.com>
References: <576ADC1A.4030803@oracle.com> <576C4BD3.4090108@oracle.com>
Message-ID: <576C5071.60400@oracle.com>


On 06/23/16 13:51, Jan Lahoda wrote:
> To me, seems mostly fine. 

Good

> I wonder if RemoteCodes should be numerical constants - enum might be 
> better (it could still have the numerical code inside).

These are ONLY used across the communication channel, and thus would 
never be usable directly as enums.  They could be encoded and decoded in 
each direction, but that seems to me that it would add complexity rather 
than clarity.

Thank,
Robert


>
> Jan
>
> On 22.6.2016 20:42, Robert Field wrote:
>> Please review these two interrelated bugs --
>>
>> Bugs:
>>
>>      8160009: JShell: Add SPI and execution to generated JShell javadoc
>> (root ws)
>>      https://bugs.openjdk.java.net/browse/JDK-8160009
>>
>>      8160035: JShell API: Add javadoc overview and package files
>>      https://bugs.openjdk.java.net/browse/JDK-8160035
>>
>> Parent bug:
>>
>>      8159118: JShell API: Provide abstract and concrete implementations
>> of ExecutionControl SPI
>>      https://bugs.openjdk.java.net/browse/JDK-8159118
>>
>> Webrevs:
>>
>>      Langtools
>>      http://cr.openjdk.java.net/~rfield/8160035v0.webrev/
>>
>>      Root
>>      http://cr.openjdk.java.net/~rfield/8160009v0.webrev/
>>
>> Generate javadoc:
>>
>>     http://cr.openjdk.java.net/~rfield/jshell_8160009/
>>
>> Thanks,
>> Robert
>>


From jan.lahoda at oracle.com  Fri Jun 24 16:38:10 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 24 Jun 2016 18:38:10 +0200
Subject: RFR 8150860: Mach 5 tier1 test started failing -
	jdk/jshell/ComputeFQNsTest.java (after 8131027/8150814)
Message-ID: <576D61F2.5030709@oracle.com>

Hi,

I'd like to ask for a review of fix for:
https://bugs.openjdk.java.net/browse/JDK-8150860

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

The reason why the test was failing on Windows is that the test is 
placing Path.toString() into a string literal and then compiling it. But 
as Paths on Windows contain '\', this lead to compilation errors due to 
invalid escape sequences. The solution is to escape '\'. The test should 
also not show a more appropriate exception than below when failing for a 
reason like this.

Thanks,
     Jan

From jonathan.gibbons at oracle.com  Fri Jun 24 16:51:44 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 24 Jun 2016 09:51:44 -0700
Subject: RFR 8150860: Mach 5 tier1 test started failing -
	jdk/jshell/ComputeFQNsTest.java (after 8131027/8150814)
In-Reply-To: <576D61F2.5030709@oracle.com>
References: <576D61F2.5030709@oracle.com>
Message-ID: <576D6520.5070405@oracle.com>

Looks good,

-- Jon

On 06/24/2016 09:38 AM, Jan Lahoda wrote:
> Hi,
>
> I'd like to ask for a review of fix for:
> https://bugs.openjdk.java.net/browse/JDK-8150860
>
> Webrev:
> http://cr.openjdk.java.net/~jlahoda/8150860/webrev.00/
>
> The reason why the test was failing on Windows is that the test is 
> placing Path.toString() into a string literal and then compiling it. 
> But as Paths on Windows contain '\', this lead to compilation errors 
> due to invalid escape sequences. The solution is to escape '\'. The 
> test should also not show a more appropriate exception than below when 
> failing for a reason like this.
>
> Thanks,
>     Jan


From robert.field at oracle.com  Wed Jun 29 02:51:21 2016
From: robert.field at oracle.com (Robert Field)
Date: Tue, 28 Jun 2016 19:51:21 -0700
Subject: RFR 8160127: JShell API: extract abstract JDI and abstract streaming
	implementations of ExecutionControl
Message-ID: <577337A9.8000204@oracle.com>

Please review --

Bugs:

     JShell API: extract abstract JDI and abstract streaming 
implementations of ExecutionControl
     https://bugs.openjdk.java.net/browse/JDK-8160127

     JShell API: Reorganize execution support code into 
jdk.jshell.execution (previously sent for review, and combined here)
     https://bugs.openjdk.java.net/browse/JDK-8159935

Parent bug:

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

Webrev:

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

API:

     http://cr.openjdk.java.net/~rfield/jshell_8160127/

     Specifically --
http://cr.openjdk.java.net/~rfield/jshell_8160127/jdk/jshell/execution/package-summary.html

Thanks,
Robert