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

Martin Buchholz martinrb at google.com
Thu Feb 19 05:41:40 UTC 2015


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.



More information about the core-libs-dev mailing list