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.ri...@oracle.com
<mailto:roger.ri...@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
<marti...@google.com <mailto:marti...@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.bate...@oracle.com <mailto:alan.bate...@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
