JEP 102 Process Updates revised API draft

[Roger Riggs]

Hi,

Also, is there a proposal for Process.compareTo?
It can be left out for the status quo, but otherwise the issue with 
getPid()/toHandle and UOE remains.
Though the previously described artificial pid workarounds can be used.

Roger


On 3/11/2015 7:57 AM, Peter Levart wrote:
> 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
>>>
>