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

[Alan Bateman]

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.