RFR: 8017513: Support for closeable streams

Brian Goetz brian.goetz at oracle.com
Fri Jul 12 17:25:24 UTC 2013

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.


       .filter(s -> s.startsWith("foo"))


   List<String result;
   try ( Stream s = list.stream().filter(...).map(...) ) {
     result = s.collect(toList());

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."

On 7/11/2013 5:17 PM, roger riggs wrote:
> 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 call it.  Or am I missing some point
> about
> generating code or in some cases not needing/wanting to close it?
> Roger
> On 7/11/2013 5: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 it holds a
>> resource, call close(), otherwise you need not call close(), but it's
>> not wrong to call it anyway - you know whether it holds resource by
>> looking at @HoldsResource annotation"
>> AutoClosable contract says: "It holds a resource, you should call
>> close()"
>> Now imagine code that was written for the AutoClosable contract. Would
>> it work if you pass it an instance of MayHoldCloseableResource? Allways.
>> Now imagine generic code that was written for MayHoldCloseableResource
>> contract and which uses the lookup of @HoldsResource at runtime to
>> decide whether to call close() or not. Would it work if you pass it an
>> instance of AutoClosable? Never (since AutoClosable says nothing about
>> any annotation).
>> So I argue that MayHoldCloseableResource should be a subtype of
>> AutoClosable and not the other way around.
>> (I have not said anything about whether the MayHoldCloseableResource
>> is actually needed or not.)
>> Regards, Peter
>> On 07/11/2013 10: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.
>>> However, the choice to make MayHoldCloseableResource a sub-interface of
>>> AutoClosable should be resisted. It's an inverted design. The Liskov
>>> *substitution
>>> principle *says that sub-interfaces can't loosen the contracts of their
>>> superinterface. If anything, AutoCloseable should be subclass of this
>>> new
>>> interface, which MIGHT hold a resource that requires closing. The
>>> current
>>> choice is just plainly backwards.
>>> For the above reason stated, and for the fact the interface adds no new
>>> functionality, it's superfluous. If the interface relationship can't be
>>> inverted, then chuck it -- it does nothing anyway. At the least, keep
>>> the
>>> annotation.
>>> Paul
>>> On Thu, Jul 11, 2013 at 3:01 PM, Henry Jen <henry.jen at oracle.com> wrote:
>>>> 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 much a developer can do on that situation. The
>>>> API simply make it not throw a *checked* exception.
>>>> See EG discussion on this topic,
>>>> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-June/002081.html
>>>>>> Annotation {@link HoldsResource} may be used to guide users/static
>>>>>> analysis tools that a MHCR instance that definitely hold a Closeable
>>>>>> resource.
>>>>> All this looks a bit odd to me.  I suppose the idea is that you don't
>>>>> want to give up the last reference to a closeable resource without
>>>>> calling close()—and not leak references which out-live the call to
>>>>> close().  This is definitely not a property of the type of the
>>>>> resource,
>>>>> so I don't see why the MayHoldCloseableResource interface is needed
>>>>> (or
>>>>> can confer relevant information).  The HoldsResource annotation
>>>>> could be
>>>>> useful, but based on the current documentation, it's not clear if
>>>>> it is
>>>>> actually intended to express the data flow property.
>>>> I would suggest you look at EG discussion on this topic. The MHCR is
>>>> different from AutoCloseable on the chances of holding critical
>>>> resources.
>>>> Perhaps that suggests the javadoc is not clear enough, I would like to
>>>> know what is important and missing.
>>>> Cheers,
>>>> Henry

More information about the core-libs-dev mailing list