On Mon, Feb 2, 2015 at 12:39 PM, Roger Riggs <roger.ri...@oracle.com> wrote:
> 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 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.
> The points raised imply that there are use cases that take advantage of
> the vagaries
> of the current under specified Process.
>
Creating subclasses of IOException for use by Process seems reasonable, but
too little, too late...
It's hard to get right because everything is grey and nuanced, so coming up
with good specs for useful subclasses is hard.
And in the end, will not really help users.
All of this activity won't really help users of Process in any case. You
can't create a Process in a useful way without knowledge of the OS you're
running on. People now do things like
if (new File("/bin/bash").isExecutable()) ...
and that will continue to be the only way to use Process in a "portable"
way.
