Hi Roger
In my opinion, the method "supportsDestroyForcibly" is unintuitive, for
the following 2 reasons:
- it's named "supportsXxx", where Xxx is the name of a method in the
same class. So as a user of this API, I would intuitively assume that
"supportsDestroyForcibly" is related to "destroyForcibly", and means
whether or not "destroyForcibly" actually forcibly terminates the process.
- "supports" has a positive connotation. However, if
"supportsDestroyForcibly" returns true, this means that the
implementation of "destroy" is forcible. And "destroyForcibly" either
invokes "destroy" (default implementation) or is overridden with a
compliant implementation. So in other words: if
"supportsDestroyForcibly" returns true, it's impossible to allow the
process to shut down cleanly. This, in my opinion, is a bad thing, so
the method indicating this behavior should not start with "supports".
Therefore I would like to propose to replace "supportsDestroyForcibly"
with "supportsDestroy", which returns the negation of what's currently
returned by "supportsDestroyForcibly".
Another question I have is: what happens if "destroy" or
"destroyForcibly" are called on processes other than the current process
& its children, i.e. a process that is in "allProcesses" but isn't
"current" & isn't in "allChildren" (e.g. the parent process of the
current process)?
Kind regards,
Anthony
On 9/04/2015 22:00, Roger Riggs wrote:
Please review the API and implementation of the Process API Updates
described inJEP 102
<https://bugs.openjdk.java.net/browse/JDK-8046092>. Please review and
comment by April 23rd.
The recommendation to make ProcessHandle an interface is included
allowing the new functions to be extended by Process subclasses.
The implementation covers all functions on Unix, Windows, Solaris, and
Mac OS X.
The API doc: http://cr.openjdk.java.net/~rriggs/ph-apidraft/
The webrev: http://cr.openjdk.java.net/~rriggs/webrev-ph
Issue: JDK-8077350 <https://bugs.openjdk.java.net/browse/JDK-8077350>
Process API Updates Implementation
The code is in the jdk9 sandbox on branch JDK-8046092-branch.
Please review and comment, Roger
