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

[Roger Riggs]

Hi Martin,

I'm still looking for additional support for using IOException instead of
UnsupportedOperationException;  the prevailing view is that UOE is 
appropriate.

The usual definition of UnsupportedOperationException seem to fit this 
case well.
The behavior of the methods is not supported by the implementation; it 
is unconditional,
it is not a question of OS policy or Java runtime policy.

The examples cited avoid using Process if the OS dependent programs are not
available and in those cases the UOE would not be encountered so this should
not raise issues for existing programs.

Roger







On 2/3/15 2:30 PM, Martin Buchholz wrote:
> I agree that we should not be throwing SecurityException. We should be 
> throwing IOException.
>
> But given a choice between SecurityException and 
> UnsupportedOperationException, I would regard the former as the lesser 
> of two evils.
>
> On Tue, Feb 3, 2015 at 12:40 AM, Alan Bateman <Alan.Bateman at oracle.com 
> <mailto:Alan.Bateman at oracle.com>> wrote:
>
>     On 02/02/2015 21:06, Martin Buchholz wrote:
>
>         :
>         The historic spec allows for both SecurityException and
>         IOException (but
>         not UOE).
>         Locked-down systems typically (but not necessarily) have a
>         SecurityManager
>         that helps enforce the restrictions and so SecurityException
>         seems vaguely
>         appropriate.
>
>     There are a small number of places where SecurityException is
>     thrown when not running with a security manager (defineClass,
>     package sealing) but it can be confusing for developers to get
>     this exception when there isn't a Java security manager. So I
>     don't think we should be using it here.
>
>     -Alan
>
>