commandStop() and the in-process execution of snippets

[Robert Field]

Jan, any insights on stop?

Grigory, JDI was chosen for redefine classes functionality.  Remote 
execution, in general, was chosen to insulate the tool from crashes and 
other code misbehavior.  Stop was an extra benefit that Jan discovered 
after we switched to remote/JDI.

Very cool on the LocalExcutionControl implementation.  I think you can get 
quite useful functionality without redefine classes or stop (though I think 
there may be less elegant solutions to the latter).  If you are able to 
launch with -javaagent there should be a solution for redefine too.

-Robert



On April 7, 2016 9:33:51 AM Grigory Ptashko <grigory.ptashko at gmail.com> wrote:

> Hello.
>
> I want to implement the in-process execution of JShell snippets without using
> the JDI env and a separate VM.
>
> I've studied the ExecutionControl and the RemoteAgent sources and 
> understood how
> JShell works in this part. Actually, I've already wrote a simple 
> LocalExcutionControl which allows
> executing the snippets in-process. I now see the problem in the stopping of the
> client code, i.e. the implementation of the commandStop() method.
>
> So I've got a question. Do I get it right that the JDI was chosen
> in order to be able to stop all the client code threads? I mean that a user
> is possibly able to create as muany threads as she wants. And the only way to
> stop them all at once is executing them in a separate VM?
>
> Do you see any solution to this when launching the client code in-process?
>
> Thank you.
>
> --
> Best regards,
> Grigory Ptashko
>
> +7 (916) 1489766
> grigory.ptashko at gmail.com
> facebook.com/GrigoryPtashko
>