Revisiting MayHoldCloseableResource

[Doug Lea]

Fine with me. Let's claim success.

-Doug


On 08/21/2013 02:20 PM, Brian Goetz wrote:
>> This might be more straighforward changing "statically known" to
>> just "known".
>  > Otherwise some people will be thinking that there is some static type
>  > that would tell them which kind they have, which there isn't.
>
> OK, did that, integrating my sentence about "generality" with your latest,
> below.  I think they say the same thing but is a little harder to misread as
> "always use TWR".
>
>> /**
>>   * An object that may hold resources (such as file or socket handles)
>>   * until it is closed. The {@link #close()} method of an AutoCloseable
>>   * object is called automatically when exiting a {@code
>>   * try}-with-resources block for which the object has been declared in
>>   * the header. This construction ensures prompt release, avoiding
>>   * resource exhaustion exceptions and errors that may otherwise occur.
>>   *
>>   * @apiNote
>>   * <p>It is possible, and in fact common, for a base class to
>>   * implement AutoCloseable even though not all of its subclasses or
>>   * instances will hold releasable resources. For code that must operate
>>   * in complete generality, or when it is known that the AutoCloseable
>  >   * instance requires resource release, it is recommended to use {@code
>>   * try}-with-resources constructions. However, when using facilities such as
>>   * {@link java.util.Stream} that support both IO-based and
>>   * non-IO-based forms, {@code try}-with-resources blocks are in
>>   * general unnecessary when using non-IO-based forms.
>>   *
>>
>