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

[Martin Buchholz]

It's not a big deal, but I am opposed to this change.  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!

I wish CCC deliberations were public and included API authors, where
available...


On Fri, Jan 30, 2015 at 3:41 PM, Martin Buchholz <martinrb at google.com>
wrote:

> It often happens that some ancient thought was in my head 10 years ago,
> and it takes a day or two to get paged back in.
>
> Now I think that 10 years ago I definitely considered the possibility of
> an OS that had no subprocess support at all, and I was comfortable with
> simply throwing IOException, much as if whatever command you were looiking
> for could not be found.  Maybe there are no files in the file system...
> Right now I'm thinking a sandboxed OS should throw IOException, in part
> because UOE is not documented, while IOException is.  Nothing is stopping
> you from throwing a new subclass of IOException, e.g.
> YouAreTrappedInASandboxException extends IOException ...
>
> On Fri, Jan 30, 2015 at 1:48 PM, Roger Riggs <Roger.Riggs at oracle.com>
> wrote:
>
>> Hi,
>>
>> That does read better.
>>
>> As in this webrev:
>>    http://cr.openjdk.java.net/~rriggs/webrev-process-8072034/
>>
>> Roger
>>
>>
>>
>> On 1/30/2015 4:30 PM, Alan Bateman wrote:
>>
>>> On 30/01/2015 15:58, Roger Riggs wrote:
>>>
>>>> Please review this clarification to the optional behavior of
>>>> java.lang.Runtime and java.lang.ProcessBuilder
>>>> on platforms that don't support process creation.
>>>>
>>>> Webrev:
>>>>   http://cr.openjdk.java.net/~rriggs/webrev-process-8055330/
>>>>
>>> One suggest is to move this to after the "Starting an operating system
>>> .." paragraph. The reason is that it more logically following the list of
>>> highly platform specific issues. Otherwise looks okay to me.
>>>
>>> -Alan
>>>
>>>
>>>
>>
>