On Mar 11, 2015, at 11:29 AM, Chris Hegarty <[email protected]> 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.
