JEP 102 Process Updates revised API draft

[Chris Hegarty]

On 06/03/15 19:34, Jason Mehrens wrote:
> Hi Chris,

>
> Since getPid can throw UOE that means that compareTo could now throw UOE.

Ooh... I don't like this.

Has any consideration been given to getPid returning -1, if unknown or 
the default implementation? Or would this be any better?

-Chris

>
>
>
> Jason
>
>
> ----------------------------------------
>> Subject: Re: JEP 102 Process Updates revised API draft
>> From: chris.hegarty at oracle.com
>> Date: Fri, 6 Mar 2015 11:59:28 +0000
>> To: Roger.Riggs at oracle.com
>> CC: core-libs-dev at openjdk.java.net
>>
>> Roger,
>>
>> I’ve taken a look at these changes in the sandbox ( JDK-8046092-branch ). Overall I welcome this addition.
>>
>> Some comments, most of which I stuffed into a webrev based on your branch,
>> http://cr.openjdk.java.net/~chegar/process_comments/webrev/
>>
>> 1) ProcessHandle.compareTo() can drop the ClassCastException
>> Also, I think the comparison is the wrong way around. It should
>> be compare(this, other), rather than compare(other, this), right?
>>
>> 2) I know there has been a lot of discussion about the use of CF,
>> but I have a few more comments:
>>
>> a) Both onExist and onProcessExit are implemented to unconditionally
>> throw UOE. Is the intention to make the implementation of these
>> methods optional? If so, then UOE should be documented, If not,
>> then I think they can be abstract, right?
>>
>> b) The wording in the spec talks about async functions and actions.
>> I think this may be not quite right. The intention is to support, as is
>> provided by CF, the ability to chain both sync and async tasks.
>> [ I suggested some wording in the webrev ]
>>
>> c) Why the need for ISE if the process is the current process, and not
>> just return a CF that never completes? Do you consider this an
>> error situation that you want to notify, or consistency with other
>> parts of the API ?
>>
>> d) I wonder if onProcessExit should have a small API note, saying
>> that it is preferred over onExit, when you have a Process. Or
>> something to promote its use over onExit, or briefly explain its
>> existence. ( I know why it is there, but it may appear as duplication )
>>
>> e) Maybe onProcessExit would benefit from an apiNote to indicate
>> that it is essentially an alternative to waitFor() ?
>>
>> 3) Should ProcessHandle.getPid declare that it can throw IOE?
>> Process.getPid declares UOE.
>>
>> 4) ProcessHandle.Info.user() ? owner() seems more appropriate, no?
>>
>> 5) The description of info() talks about fields, when it is an interface.
>> I added some suggested rewording. Also, all methods now return
>> references, so -1 can be removed. Similar for the Info class description.
>>
>> 6) There are a couple of @since 1.9 tags missing from Process
>> supportsDestroyForcibly and onProcessExit
>>
>> That’s all for now.
>>
>> -Chris.
>>
>>
>>