Some Classes with a public void close() don't implement AutoCloseable

[Joe Darcy]

Hello,

On 4/22/2020 6:12 AM, Alan Bateman wrote:
> On 22/04/2020 13:50, Andrew Haley wrote:
>> :
>> 1. Should close() always be idempotent, where practical? I would have
>>     thought so, but perhaps there are downsides.
>>
>> 2. Should classes which implement close() with the standard meaning be
>>     AutoCloseable?
>>
> I'm sure Joe Darcy can say more on this but I remember there was a lot 
> of effort put into this topic when AutoCloseable was added in Java 7 
> (and Project Coin). Closeable close is idempotent but AutoCloseable 
> close could not require it. AutoCloseable's API docs recommend it of 
> course. There was effort in Java 7 and beyond to retrofit existing 
> classes that defined a close method to be Closeable or AutoCloseable. 
> There are only a handful of exported APIs remaining that have a close 
> method that don't extend or implement AutoCloseable. I don't know the 
> history of the XML stream interface to know why they close to define 
> them not to close the underlying stream but I doubt these could be 
> changed now.


Yes, the JSR 334 EG had some discussions about both "SilentCloseable" 
(no exceptions) and "IdempotentCloseable" as possible library additions 
back in the JDK 7 time frame. These were not judged to have sufficient 
marginal utility over Closeable and AutoCloseable to include in the 
platform.

It was impractical to require idempotent close methods in call cases, 
but they are recommended. Generally, a type with a void close method 
should implement AutoClosable. Most of the candidate types in the JDK 
were updated for JDK 7; a few stragglers were updated since then, but 
there are a few remaining cases that could be updated as discussed 
earlier in this thread.

HTH,

-Joe