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

[Martin Buchholz]

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.

On Wed, Feb 11, 2015 at 12:24 PM, Roger Riggs <Roger.Riggs at oracle.com>
wrote:

> 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
>>
>>
>>
>