On Mar 11, 2015, at 11:29 AM, Chris Hegarty <chris.hega...@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.
