RFR 9 8055330: (process spec) ProcessBuilder.start and Runtime.exec should throw UnsupportedOperationException ...

Martin Buchholz martinrb at google.com
Sat Jan 31 21:30:43 UTC 2015

>From a tck point of view, Process has always seems untestable, since any
process creation can fail at any time for any (external) reason.  Adding
special handling for OSes where a Process can never be created doesn't
help... please explain.

My feeling that we should consistently fail with IOException is hardening.
It's reasonable to throw a subclass that explains that you're on an OS
where no subprocesses are allowed, or you can only start subprocesses after
7pm, or the only command you can run is { "cthulu" }.

On Sat, Jan 31, 2015 at 1:03 PM, Alan Bateman <Alan.Bateman at oracle.com>

> On 31/01/2015 16:15, Martin Buchholz wrote:
>> It's not a big deal, but I am opposed to this change.
> Just an FYI that Roger seems to have pushed the original patch, this new
> patch just moves the text down so that it flows a bit better.
>  The old spec
>>      * <p>In such cases an exception will be thrown. The exact nature
>>      * of the exception is system-dependent, but it will always be a
>>      * subclass of {@link IOException}.
>> is perfectly adequate for OSes with no subprocesses.
>> Users should be catching and handling IOException in any case.  Throwing
>> a RuntimeException seems wrong, and breaks the above promise!
>>  It's lack of clarity in the above text that has been causing the
> testability issue for so long so I think it is good to make it clear how an
> implementation that does not support processes should behave. The options
> on the table seem to be to define a sub-type of IOE for this case, specify
> that an IOE be thrown with an UOE as the cause, or just throw UOE when this
> feature is not supported.
> -Alan

More information about the core-libs-dev mailing list