RFR: 8017513: Support for closeable streams

[Zhong Yu]

On Fri, Jul 12, 2013 at 6:22 AM, David Holmes <david.holmes at oracle.com> 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 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.
>
> Not quite. It says:
>
> - Preconditions cannot be strengthened in a subtype.
> - Postconditions cannot be weakened in a subtype.
> - Invariants of the supertype must be preserved in a subtype.
>
> Question is: what kind of property is "closeability"?
>
>
>> 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.
>
>
> No what you just said is "plainly backwards". If AutoCloseable is a subtype
> of MHCR then you should be able to use an AC instance anywhere you use a
> MHCR. But valid code doesn't have to close a MHCR, so if you replace it with

If the only information we have is that the object is a MHCR, we must close it.

If we have other information, e.g. it's a Stream is from an ArrayList,
then we may omit the close() call.

The annotation @HoldsResource is meant to add extra information;
particularly, *lack* of the annotation is meant to be a definitive
information that close() can be omitted ! That's incredibly brittle.

Zhong Yu


> an AC which requires closing then you have broken code. Hence not
> substitutable, hence invalid inheritance relationship.
>
> But if anything this is just another variation of the Square/Rectangle
> inheritance fallacy. While you can define either as a specialization of the
> other, you can always violate substitutability by doing something that
> relies on the property that gets specialized.
>
> David
> -----
>
>
>>
>> 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
>>>
>>>
>>>
>>
>>
>