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