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

[Jason Mehrens]

Hi Roger,

For what it is worth, the most common production use case for me is:

1. Generate output from some source to a temp file.
2. Use ProcessBuilder to launch process (native or JVM) for using temp file.
3. If that fails with IOException fallback to opening a save dialog.
4. The end user will use #2 or #3 to save the file to a known location.
5. The end user will finish final product or get it to a machine that works then finish the final product.
6. (non)Profit.


So in this case you wait around for #1 to get done and as long as #2 or #3 work then #1 wasn't a wasted effort. In the UOE case 3 through 6 are skipped which is a bad deal for the end user.  This is 15+ years still in production code where the steps were crafted by a natural evolution of the Murphy's Law based environment that it exists in.  End of life for this code is not in sight.


Save your health and don't think too hard about the example, try to apply logic to it, or tear it down.  It is not my intent to hold this example up as 'the best counter argument', 'sky is falling' or to drag this thread out.  The point is, no where in the example does the calling code or user care about the distinction between never being able to create a process or creating a process failed this time.  For this code, throwing UOE is a breaking feature not a bug fix.  The only known thing was the API contract.  Everything else was assumed to be broken.


I do appreciate your time, Alan's time, the time you have spent on this issue, and your arguments as they are logical.  We just differ on applying the logic to this case.  I also understand the decision has been made and that will be the future.  I'll just have to be prepared for it and Murphy.


Respectfully,


Jason


----------------------------------------
> Date: Fri, 20 Feb 2015 13:06:05 -0800
> Subject: Re: RFR 9 8055330: (process spec) ProcessBuilder.start and Runtime.exec should throw UnsupportedOperationException ...
> From: martinrb at google.com
> To: Roger.Riggs at oracle.com
> CC: core-libs-dev at openjdk.java.net
>
> I totally disagree about "recoverable condition". Instead of thinking
> about "recovering", think instead about whether it ever makes sense to
> catch the resulting exception. See my sample code broken by the switch to
> UOE.
>
> On Fri, Feb 20, 2015 at 11:58 AM, Roger Riggs <Roger.Riggs at oracle.com>
> wrote:
>
>> Hi Martin,
>>
>> As I said earlier, launching a Process when process is not implemented
>> is not a recoverable condition; there are no conditions under which it will
>> succeed. If the application is probing to determine what
>> is supported on a platform then it should be prepared to handle UOE
>> or using a test for the specific capability it requires.
>>
>> Roger
>>
>>
>>
>> On 2/20/2015 1:34 PM, Martin Buchholz wrote:
>>
>>> One reason I keep pouring salt on this tiny wound is that throwing
>>> (unchecked) UOE for system-dependent failures when normally IOE is thrown
>>> is a fundamental design mistake for java and its checked exception design.
>>> I think it violates Josh's Effective Java Item 58: Use checked exceptions
>>> for recoverable conditions and runtime exceptions for programming errors.
>>> I don't think it's worth fixing places in jdk8 where this small mistake
>>> was
>>> made, but we can at least stop the incompatible worsening of existing
>>> APIs.
>>>
>>> On Fri, Feb 20, 2015 at 3:49 AM, Alan Bateman <Alan.Bateman at oracle.com>
>>> wrote:
>>>
>>> On 19/02/2015 21:54, Jason Mehrens wrote:
>>>>
>>>> I'm assuming that compatibility is given more weight vs. correcting
>>>>> choices made in the original design.
>>>>>
>>>>> Yes, I think we've spent more than enough time on it. In this case
>>>>> it's
>>>>>
>>>> for a major release only and the compatibility impact seems to be only
>>>> platforms or implementations that don't support launching of processes
>>>> today but are running applications that attempt to start processes
>>>> anyway.
>>>> So overall it doesn't seem to be something to be overly concerned with.
>>>>
>>>> -Alan
>>>>
>>>>
>>