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.
