JEP 102 Process Updates revised API draft

[Paul Sandoz]

On Mar 10, 2015, at 3:16 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> On 3/10/2015 5:50 AM, Paul Sandoz wrote:
>> On Mar 6, 2015, at 7:58 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
>>>> 2) I know there has been a lot of discussion about the use of CF,
>>>>     but I have a few more comments:
>>>>          a) Both onExit 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?
>>> There are existing non-jdk implementations of Process and it would be source
>>> incompatible if default implementations were not supplied.  So, not abstract.
>>> 
>>> Since the behavior applies to Process, the note in the class documentation
>>> defines the behavior.
>>> "Methods of {@code Process} that are not otherwise specified or overridden throw
>>> {@link java.lang.UnsupportedOperationException}."
>>> 
>>> More direct documentation could be provided in the override of onExit
>>> but that would raise the visibility to ordinary developers who should use
>>> onProcessExit that returns the correctly typed CF and not onExit.
>>> The note should be sufficient for implementers without distracting the ordinary developer.
>>> 
>>> Perhaps, a description similar to that used in destroy(), the behavior of Processes
>>> returned from ProcessBuilder can be more tightly specified. Alternatively,
>>> ProcessBuilder could specify the behavior of Process instances it returns, at present,
>>> the behavior of the Process instances is split between the two classes.
>>> 
>> Throwing USO for default implementations is a warning sign to me that something does not fit quite right. It feels like we are giving up :-)
> It is an artifact of extending the API of an externally subclassable class.
>> 
>> I now see Process.getPid was previously added and it throws USO by default. So we might be stuck due to the tricky nature of this area.
> Added early in 9, IMHO it can be revisited if necessary.

Perhaps, it seems more to point to a fundamental trickiness we cannot easily avoid.


>> 
>> Any sub-type of Process that does not override getPid will essentially result in that USO being propagated to many ProcessHandle methods that depend on the PID (parent, children, allChildren, info, compareTo). That effectively renders ProcessHandle almost useless for sub-types outside of our control that that not been updated.
> For those methods, the default behavior can be specified, except for compareTo
> they already have return values that allow for the fact that the information may
> not be available, either due to OS restrictions (permissions) or is not provided.
> Empty lists for children, nulls returned from info, and even allowing for an unavailable parent.

That's a separate issue. 

If i get a ProcessHandle given to me, i do not know it's source, i dunno if it's gonna barf if i operate on it.


>> 
>> Is it common to sub-type Process?
> Subclassing is very limited; usually for some kind of interposition or delegation.

Ok.


>> If so then perhaps Process should not extend ProcessHandle and instead there should be a way to view a Process as a ProcessHandle, whose default implementation is:
>> 
>>   return ProcessHandle.of(getPid()); // throws USO if getPid does
>> 
>> (java.lang.ProcessImpl could implement Processhandle thereby the implementation is "return this".)
> Only if ProcessImpl extends ProcessHandle but it already extends Process and if Process does not extend ProcessHandle...
> 

Doh! scrap that optimisation, i keep wanting ProcessHandle to be an iface.


> Regardless, the same methods parent, children, allChldren, info, compareTo would be useful
> on Process and will have the same issues with subclassing and default implementations.
> 

For all but comparison one could go through the view, it's a little more verbose, but not terrible.


> It is not a high priority to provide first class support for external subclasses of Process.
> The focus is on Processes created by ProcessBuilder.
> 

Ok. We should probably call that out more clearly in the docs if that is the design direction.

Paul.