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

[Roger Riggs]

Hi Martin,

The choice of UnsupportedOperationException specifies a complete inability
of the runtime to ever launch a Process.  IOException on the other hand
is appropriate in cases where there are configuration or OS implementation
dependencies or transient behavior.

Existing applications that expect to spawn processes are very unlikely to be
appropriate for a target platform without Process support.  For new and
retargeted applications identifying such a basic mismatch should be
immediate and conclusive.

Adding a subtype of IOException doesn't help existing applications and
adds to the already overloaded IOException.

It seems more valuable to make a clear distinction in the specification
than to add to the current vagaries of OS dependencies.

Roger



On 2/1/15 3:18 PM, Martin Buchholz wrote:
> More generally, it seems like an API design mistake (for the Java 
> language with its controversial checked exceptions) to throw UOE 
> instead of IOE for any operation that interacts with the environment 
> external to the JVM.
>
> What is the benefit for users?
>
> On Sat, Jan 31, 2015 at 1:30 PM, Martin Buchholz <martinrb at google.com 
> <mailto:martinrb at google.com>> wrote:
>
>     From a tck point of view, Process has always seems untestable,
>     since any process creation can fail at any time for any (external)
>     reason.  Adding special handling for OSes where a Process can
>     never be created doesn't help... please explain.
>
>     My feeling that we should consistently fail with IOException is
>     hardening.  It's reasonable to throw a subclass that explains that
>     you're on an OS where no subprocesses are allowed, or you can only
>     start subprocesses after 7pm, or the only command you can run is {
>     "cthulu" }.
>
>     On Sat, Jan 31, 2015 at 1:03 PM, Alan Bateman
>     <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote:
>
>         On 31/01/2015 16:15, Martin Buchholz wrote:
>
>             It's not a big deal, but I am opposed to this change.
>
>         Just an FYI that Roger seems to have pushed the original
>         patch, this new patch just moves the text down so that it
>         flows a bit better.
>
>             The old spec
>
>                  * <p>In such cases an exception will be thrown. The
>             exact nature
>                  * of the exception is system-dependent, but it will
>             always be a
>                  * subclass of {@link IOException}.
>
>             is perfectly adequate for OSes with no subprocesses.
>             Users should be catching and handling IOException in any
>             case.  Throwing a RuntimeException seems wrong, and breaks
>             the above promise!
>
>         It's lack of clarity in the above text that has been causing
>         the testability issue for so long so I think it is good to
>         make it clear how an implementation that does not support
>         processes should behave. The options on the table seem to be
>         to define a sub-type of IOE for this case, specify that an IOE
>         be thrown with an UOE as the cause, or just throw UOE when
>         this feature is not supported.
>
>         -Alan
>
>
>
>
>