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

[Martin Buchholz]

The following kind of code is broken by the change to UOE:

boolean haveTrue = false;
try {
  new ProcessBuilder("/bin/true").start();
  haveTrue = true;
} catch (IOException e) { haveTrue = false; }

On Thu, Feb 19, 2015 at 2:31 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

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