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

[Roger Riggs]

Hi,

The original protagonist is on vacation this week so the resolution may 
be delayed.
I picked up what seemed like the relatively simple task of making the 
change.

On 2/2/15 11:50 AM, Martin Buchholz wrote:
> Hi,
>
> Y'all seem determined to continue on this course of 
> UnsupportedOperationException-ization, but to me it seems the wrong 
> direction to take.
>
> You are reversing the standard Java dogma of checked vs. unchecked 
> exceptions as explained e.g. at 
> http://www.javapractices.com/topic/TopicAction.do?Id=129 creating an 
> increasingly inconsistent and capricious platform, with no benefit to 
> users.
Using the phrase from Unchecked exceptions: "cannot be reasonably 
recovered from at runtime"
covers the case that the JRE does not support Process spawning.  If the 
application expects to be
able to spawn Processes and the platform unconditionally does not 
support it, there is nothing the
application can do to recover.

Citing this principle suggests there is some alternative, but what?
>
> Code will need to start checking both UOE and IOE for "os errors". For 
> the case of ProcessBuilder, this is particularly egregious, since the 
> javadoc goes out of its way to explicitly guarantee that catching IOE 
> is sufficient.
>
> There is no sharp distinction for platforms that don't support 
> exceptions, but CantCreateSubprocessesDuringPeakHoursException and 
> PleasePayYourBillException are semantically very close.
I'm not sure of the use of 'exceptions' here. IOExceptions can cover a 
whole host
of OS specific behaviors including those that might arise by way of a 
policy not of the OS
but by the operational environment. But I would expect these examples to 
be covered by the
current IOException.
>
> I believe that current platforms that allow absolutely no subprocess 
> creation will see pressure to relax that, especially for creating new 
> instances of the JVM itself recursively.  Not allowing process 
> creation is essentially a bug, that future releases of the platform 
> are likely to fix. I foresee a future where some carefully supervised 
> process creation is allowed on "locked-down systems", and I fear that 
> other process creation will continue to throw a now nonsensical UOE 
> "for compatibility".
If those platforms change their implementation from not supported ever 
to maybe-sometimes
under the right conditions then they would supply an implementation that 
reports
failures using IOException.  In some cases, policy choices should be 
reflected perhaps
in SecurityException rather than IOExceptions.

The points raised imply that there are use cases that take advantage of 
the vagaries
of the current under specified Process.

Roger

>
>
>
>
> On Mon, Feb 2, 2015 at 5:35 AM, Roger Riggs <Roger.Riggs at oracle.com 
> <mailto:Roger.Riggs at oracle.com>> wrote:
>
>     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
>>
>>
>>
>>
>>
>
>