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

[Roger Riggs]

Hi Jason,

In the case where there is *any* implementation of Process, IOException is
the right way to expose OS dependencies.  But in the case where there is 
never
going to be a successful Process, UOE is by far the more conventional and
understandable exception.  Backward compatibility is not an absolute
requirement.  I have no expectation that any existing application will run
on the target device/OS combinations that this change is intended to support
even without taking processes into account.
No one has offered a use case or example to the contrary.  If this is not an
academic or theoretical question, I'd appreciate a concrete example.

Thanks, Roger

On 2/19/2015 4:54 PM, Jason Mehrens wrote:
> 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.