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

[Martin Buchholz]

>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>
wrote:

> 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
>
>
>
>