JEP 102 Process Updates revised API draft
Chris Hegarty
chris.hegarty at oracle.com
Wed Mar 11 11:51:08 UTC 2015
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?
> 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?
-Chris.
> Peter
>
More information about the core-libs-dev
mailing list