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: marti...@google.com
To: alan.bate...@oracle.com
CC: core-libs-dev@openjdk.java.net
On Thu, Feb 12, 2015 at 1:07 AM, Alan Bateman <alan.bate...@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.
