On Aug 29, 2013, at 11:15 AM, Alan Bateman wrote:
> On 29/08/2013 09:51, Paul Sandoz wrote:
>> On Aug 29, 2013, at 8:58 AM, Alan Bateman wrote:
>>
>>> :
>>>
>>> I think I mentioned this previously but in the Files.list/walk/etc. methods
>>> where you close the resource (on error|runtimeexcep
On 29/08/2013 09:51, Paul Sandoz wrote:
On Aug 29, 2013, at 8:58 AM, Alan Bateman wrote:
:
I think I mentioned this previously but in the Files.list/walk/etc. methods
where you close the resource (on error|runtimeexception) then it's probably
best to catch the IOException and add it as a su
On Aug 29, 2013, at 8:58 AM, Alan Bateman wrote:
> On 28/08/2013 22:10, Henry Jen wrote:
>> Hi,
>>
>> Please review the webrev at
>> http://cr.openjdk.java.net/~henryjen/ccc/8017513/1/webrev/
>>
>> Based on the feedback/discussion from last time, the EG decided to
>> weaken AutoCloseable contr
On 28/08/2013 22:10, Henry Jen wrote:
Hi,
Please review the webrev at
http://cr.openjdk.java.net/~henryjen/ccc/8017513/1/webrev/
Based on the feedback/discussion from last time, the EG decided to
weaken AutoCloseable contract(see RFR 8022176[1]), and have Stream
extend AutoCloseable.
A quick b
Hi,
Please review the webrev at
http://cr.openjdk.java.net/~henryjen/ccc/8017513/1/webrev/
Based on the feedback/discussion from last time, the EG decided to
weaken AutoCloseable contract(see RFR 8022176[1]), and have Stream
extend AutoCloseable.
A quick briefing of the webrev,
- Remove Closeabl
On 10/07/2013 14:30, Henry Jen wrote:
Hi,
Please review webrev at
http://cr.openjdk.java.net/~henryjen/ccc/8017513/0/webrev/index.html
This webrev improve resource release experience on Streams by
eliminating CloseableStream, instead, fold close capability into Stream.
A new interface, java.ut
Brian, you wrote: "It would be utterly criminal if someone were to
restructure the above code into the below code because some IDE inspection
complained about
"must call close or use TWR."
I agree here. However, the inheritance of AutoCloseable is going to likely
prompt some kind of action by deve
On 07/12/2013 01:22 PM, David Holmes wrote:
On 12/07/2013 6:22 AM, Paul Benedict wrote:
Paul S.'s said the "negative" of using AutoCloseable is "it is no longer
clear whether a stream should be closed or not" (6/20). That's true
because
the semantics of AutoCloseable indicates you have a resourc
On 15/07/2013 2:47 PM, Paul Benedict wrote:
It's a post-condition to using the object. I've emphasized the "must"
part of the contract but the full contract is: "must be closed when it
is no longer needed". That's a pretty clear post-condition language that
must be true. So when you're done with
It's a post-condition to using the object. I've emphasized the "must" part
of the contract but the full contract is: "must be closed when it is no
longer needed". That's a pretty clear post-condition language that must be
true. So when you're done with the AutoCloseable type, as in the
post-conditi
On 12/07/2013 11:57 PM, Paul Benedict wrote:
I see closeability as a postcondition. A subtype can't weaken it. The
contract of AutoCloseable says its a resource that "must" be closed. Now
MHCR says it can/should/doesn't have to be closed -- so it is backwards.
A "postcondition" of what? pre- an
The whole reflection thing is a red herring. As is the performance thing.
The reason not to call close() has nothing to do with the expensive of
calling close; it is about not mucking up your code for no reason.
Consider:
list.stream()
.filter(s -> s.startsWith("foo"))
.map(Str
On Fri, Jul 12, 2013 at 6:22 AM, David Holmes wrote:
> On 12/07/2013 6:22 AM, Paul Benedict wrote:
>>
>> Paul S.'s said the "negative" of using AutoCloseable is "it is no longer
>> clear whether a stream should be closed or not" (6/20). That's true
>> because
>> the semantics of AutoCloseable indi
On Fri, Jul 12, 2013 at 4:30 AM, Peter Levart wrote:
> On 07/12/2013 01:14 AM, Zhong Yu wrote:
>
> On Thu, Jul 11, 2013 at 4:08 PM, Peter Levart
> wrote:
>
> Hi Paul,
>
> I think the MayHoldCloseableResource extends AutoClosable is correct and
> AutoClosable extends MayHoldCloseableResource would
I see closeability as a postcondition. A subtype can't weaken it. The
contract of AutoCloseable says its a resource that "must" be closed. Now
MHCR says it can/should/doesn't have to be closed -- so it is backwards.
On Fri, Jul 12, 2013 at 6:22 AM, David Holmes wrote:
> On 12/07/2013 6:22 AM, Pa
On 12/07/2013 6:22 AM, Paul Benedict wrote:
Paul S.'s said the "negative" of using AutoCloseable is "it is no longer
clear whether a stream should be closed or not" (6/20). That's true because
the semantics of AutoCloseable indicates you have a resource that requires
closing.
However, the choice
On 07/12/2013 01:14 AM, Zhong Yu wrote:
On Thu, Jul 11, 2013 at 4:08 PM, Peter Levart wrote:
Hi Paul,
I think the MayHoldCloseableResource extends AutoClosable is correct and
AutoClosable extends MayHoldCloseableResource would be wrong.
And exactly because of "Liskov":
MayHoldCloseableResour
On Thu, Jul 11, 2013 at 4:08 PM, Peter Levart wrote:
> Hi Paul,
>
> I think the MayHoldCloseableResource extends AutoClosable is correct and
> AutoClosable extends MayHoldCloseableResource would be wrong.
>
> And exactly because of "Liskov":
>
> MayHoldCloseableResource contract says: "If you know
Hi,
Wouldn't the close() implementation be nil in most cases if there was no
resource.
That kind of method runs very quickly and I would expect the compiler to
inline nothing.
It would be quicker to just call close() than to engage reflection to
determine
if it really did and then decide to
Hi Paul,
I think the MayHoldCloseableResource extends AutoClosable is correct and
AutoClosable extends MayHoldCloseableResource would be wrong.
And exactly because of "Liskov":
MayHoldCloseableResource contract says: "If you know it holds a
resource, call close(), otherwise you need not call
Interesting thought, Henry. Given your explanation, I perhaps garner the
semantics of AutoCloseable should be loosen to equal what
MayHoldCloseableResource is. Rather than say AutoCloseable is a resource
that must be closed, simply say it's a resource that can be closed. Then
MayHoldCloseableResour
On 07/11/2013 01:22 PM, Paul Benedict wrote:
> Paul S.'s said the "negative" of using AutoCloseable is "it is no longer
> clear whether a stream should be closed or not" (6/20). That's true
> because the semantics of AutoCloseable indicates you have a resource
> that requires closing.
>
I believe
Paul S.'s said the "negative" of using AutoCloseable is "it is no longer
clear whether a stream should be closed or not" (6/20). That's true because
the semantics of AutoCloseable indicates you have a resource that requires
closing.
However, the choice to make MayHoldCloseableResource a sub-interf
On 07/11/2013 01:13 AM, Florian Weimer wrote:
> On 07/10/2013 11:30 PM, Henry Jen wrote:
>
>> A new interface, java.util.MayHoldCloseableResource, indicates an
>> implementation may or may not hold a resource need to be closed.
>
> Why doesn't close() throw Exception?
Because there is really muc
On 07/10/2013 03:17 PM, Zhong Yu wrote:
> A few things that require clarification:
>
> If we have
>
> interface A extends B, C
> interface B extends MayHoldCloseableResource
> interface C extends AutoCloseable
>
> is A considered definitely holding resource?
Not programatically. A i
On 07/10/2013 11:30 PM, Henry Jen wrote:
A new interface, java.util.MayHoldCloseableResource, indicates an
implementation may or may not hold a resource need to be closed.
Why doesn't close() throw Exception?
Annotation {@link HoldsResource} may be used to guide users/static
analysis tools t
A few things that require clarification:
If we have
interface A extends B, C
interface B extends MayHoldCloseableResource
interface C extends AutoCloseable
is A considered definitely holding resource?
If @HoldsResource is applied to a subtype of MayHoldCloseableResource
@HoldsR
Hi,
Please review webrev at
http://cr.openjdk.java.net/~henryjen/ccc/8017513/0/webrev/index.html
This webrev improve resource release experience on Streams by
eliminating CloseableStream, instead, fold close capability into Stream.
A new interface, java.util.MayHoldCloseableResource, indicates a
28 matches
Mail list logo
