he 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 8
ed 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: marti...@google.com
> To: roger.ri...@oracle.com
FWIW, I think UOE is clearly the right exception for a method that is
unsupported. An IOExeption is very much associated with the actual IO
system.
Stephen
On 20 February 2015 at 21:06, Martin Buchholz wrote:
> I totally disagree about "recoverable condition". Instead of thinking
> about "recove
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
wrote:
> Hi Martin,
>
> As I
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 te
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 recov
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
pla
gt;>
>>
>> I do appreciate the arguments on both sides but, I'm assuming that
>> compatibility is given more weight vs. correcting choices made in the
>> original design.
>>
>>
>> Jason
>>
>>
>>
>> -
choices made in the original
design.
Jason
Date: Wed, 18 Feb 2015 21:41:40 -0800
Subject: Re: RFR 9 8055330: (process spec) ProcessBuilder.start and
Runtime.exec should throw UnsupportedOperationException ...
From: marti...@google.com
To: alan.b
015 21:41:40 -0800
> Subject: Re: RFR 9 8055330: (process spec) ProcessBuilder.start and
> Runtime.exec should throw UnsupportedOperationException ...
> From: marti...@google.com
> To: alan.bate...@oracle.com
> CC: core-libs-dev@openjdk.java.net
>
> On Thu, Feb 12, 2015 at 1:07 A
On Thu, Feb 12, 2015 at 1:07 AM, Alan Bateman
wrote:
> On 12/02/2015 02:08, Martin Buchholz wrote:
>
>> 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
On 12/02/2015 02:08, Martin Buchholz wrote:
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 avai
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
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 b
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
wrote:
> On 02/02/201
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.
Ther
On Mon, Feb 2, 2015 at 12:39 PM, Roger Riggs 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 shoul
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
UnsupportedOperationExcep
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=12
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
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 Buchh
>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 IOExcep
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
* In such cases an exception will be thro
It's not a big deal, but I am opposed to this change. The old spec
* 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.
On 30/01/2015 21:48, Roger Riggs wrote:
Hi,
That does read better.
As in this webrev:
http://cr.openjdk.java.net/~rriggs/webrev-process-8072034/
This looks better, thanks.
-Alan.
It often happens that some ancient thought was in my head 10 years ago, and
it takes a day or two to get paged back in.
Now I think that 10 years ago I definitely considered the possibility of an
OS that had no subprocess support at all, and I was comfortable with simply
throwing IOException, much
Hi,
That does read better.
As in this webrev:
http://cr.openjdk.java.net/~rriggs/webrev-process-8072034/
Roger
On 1/30/2015 4:30 PM, Alan Bateman wrote:
On 30/01/2015 15:58, Roger Riggs wrote:
Please review this clarification to the optional behavior of
java.lang.Runtime and java.lang.Pr
On 30/01/2015 15:58, Roger Riggs wrote:
Please review this clarification to the optional behavior of
java.lang.Runtime and java.lang.ProcessBuilder
on platforms that don't support process creation.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-process-8055330/
One suggest is to move this
Hi Martin,
Since very few developers will care about this case, it doesn't seem
necessary to
repeat the javadoc unless consistency is more important than readability.
In Runtime, the change is in the full exec method; all of the other
exec methods are
described as convenience methods and exp
Seems OK, but:
UOE should be specified in ProcessBuilder if and only if it is also
specified for the Runtime.exec family of methods, since they are wrappers
around ProcessBuilder.
Because there are so many methods, it may be better to have a blanket UOE
disclaimer added to the class descriptions
Looks good to me Roger.
-- daniel
On 30/01/15 16:58, Roger Riggs wrote:
Please review this clarification to the optional behavior of
java.lang.Runtime and java.lang.ProcessBuilder
on platforms that don't support process creation.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-process-805
31 matches
Mail list logo
