JEP 102 Process Updates revised API draft

[Peter Levart]

On 03/11/2015 12:51 PM, Chris Hegarty wrote:
> On 11/03/15 11:34, Peter Levart wrote:
>> On 03/11/2015 11:29 AM, Chris Hegarty wrote:
>>> can be removed, no?
>>>>      long getPID() throws USO { throw new USO; }
>>>
>>> I think ProcessHandle needs a protected constructor, otherwise it
>>> cannot be implemented outside of the platform. Or is this the intent?
>>> In which case Process.getPid() may need to remain.
>>
>> I think in majority of cases it needs not be implemented outside the
>> platform.
>
> Is there any time where it would be required to implemented outside of 
> the platform?

Only for special implementations that don't map to local processed of 
supported platforms, I think. Such as remote execution facility 
disguised as a Process API. Or a facility that breaks out of sandboxed 
environment for execution of local processes that are otherwise not 
accessible by JVM process directly. This is all hypothetical.


>
> > Process.getPid() can remain as a quick shortcut and by default
>> it can be implemented as:
>>
>> public long getPid() throws USO {
>>      return toHandle().getPid();
>> }
>>
>> ...and overridden in internal implementations with more optimal thing.
>>
>> Ok, then the same can be said for Process.onExit() (which can now have a
>> different signature than ProcessHandle.onExit()):
>>
>> public abstract class Process {
>>
>>      public CompletableFuture<Process> onExit() {
>>          return toHandle().onExit().thenApply(ph -> this);
>>      }
>
> Are we not back where we started, since toHandle() can throw UOE?

Yes, number of such methods should be minimized. Perhaps just getPid() 
since it can have much more optimal implementation in internal ProcessImpl.

Regards, Peter


>
> -Chris.
>
>> Peter
>>