JEP 102 Process Updates revised API draft

[Paul Sandoz]

On Mar 11, 2015, at 11:29 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>> 
>> I still think that conflates the "OS says no" and the "Subtype of Process does not support the contract of ProcessHandle".
>> 
>> Process as designed feels kind of limited and we are stuck with that. ProcessHandle is then also limited by Process extending it. Thus my inclination is still for Process to not extend from ProcessHandle, let's keep then at a distance.
> 
> I think this design should work out cleaner. There can be just a single point where UOE can be thrown, from toHandle().
> 
> My inclination, with this design, is to remove Process.getPid(), since the pid can be retrieved from the handle. This should be possible since Process.getPid() is @since 1.9.
> 
>> For arguments sake let's say we go with that approach:
>> 
>>   public abstract class Process {
> 
> 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 tried to keep within certain constraints of Rodger's existing design and the existing methods (even if recently added). IIUC Roger wanted ProcessHandle impls to be under platform control.

Paul.