On Mar 10, 2015, at 3:16 PM, Roger Riggs <roger.ri...@oracle.com> wrote:
> On 3/10/2015 5:50 AM, Paul Sandoz wrote:
>> On Mar 6, 2015, at 7:58 PM, Roger Riggs <roger.ri...@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.
