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

[Jason Mehrens]

Standing with Martin on this, I wanted to note the following from the ProcessBuilder docs:
"The exact nature of the exception is system-dependent, but it will always be a subclass of IOException"

The type of exception thrown is the one thing that is defined in the spec.  The rest may be vague or have wiggle room but not the exception type.


I do appreciate the arguments on both sides but, I'm assuming that compatibility is given more weight vs. correcting choices made in the original design.


Jason



----------------------------------------
> Date: Wed, 18 Feb 2015 21:41:40 -0800
> Subject: Re: RFR 9 8055330: (process spec) ProcessBuilder.start and Runtime.exec should throw UnsupportedOperationException ...
> From: martinrb at google.com
> To: Alan.Bateman at oracle.com
> CC: core-libs-dev at openjdk.java.net
>
> On Thu, Feb 12, 2015 at 1:07 AM, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>> On 12/02/2015 02:08, Martin Buchholz wrote:
>>
>>> Roger et al,
>>>
>>> Whichever way we go doesn't matter much.
>>> But I continue to think that IOE is a better choice than UOE and I have
>>> trouble seeing the motivation for the change to use UOE.
>>> If you wanted to provide a way to tell if subprocess support was available
>>> at all, then it would be better to add a new static boolean method to
>>> Process (but I wouldn't support that either).
>>> But (Roger and Alan): feel free to outvote me.
>>>
>>> I think Roger's proposal is reasonable as this is a case where the API
>> will consistently throw UOE when the underlying runtime or operating system
>> doesn't support a means to start processes. It's consistent with what was
>> done for RMI activiation in JDK 8 (this was also about starting processes).
>> Another example that comes to mind is the GUI libraries where
>> HeadlessException is thrown (HeadlessException is a UOE). In the file
>> system API then UOE is also specified when trying to use optional features
>> that aren't supported by the implementation. There are probably many
>> counter examples as we don't have consistency everywhere. In practical
>> terms then I don't think this change should have an impact, but could be
>> useful for those trying to take an existing app and run it on something
>> like iOS. If that app relies on Runtime.exec or ProcessBuilder then the UOE
>> should make it easy to identify that this part of the code needs to be
>> looked at. If someday it is possible to start processes on such devices
>> then an updated port to that platform wouldn't throw UOE anymore.
>>
>> -Alan.
>>
>
> If you threw a variant of UOE that was also an IOException, it would have
> been equally clear to users, and no change to the contract of
> ProcessBuilder would have been necessary.
>
> You've broken users who relied on the old spec.