JEP 102 Process Updates revised API draft

[Roger Riggs]

Hi,

I think the 'convenience' methods for onExit() and getPid() are 
useful/desirable on Process.
It should not be necessary to shuttle over to ProcessHandle to do basic 
functions on the Process.

Roger


On 3/11/2015 7:34 AM, 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. 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);
>     }
>
> Peter
>