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

[Stuart Marks]

On 4/22/20 1:42 PM, Joe Darcy wrote:
> 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.

Regarding idempotentcy, I remember some of those discussions. To the extent 
possible, JDK implementations all have idempotent close() methods. However, some 
classes that seemed useful to be AutoCloseable were extensible outside the JDK, 
and we couldn't guarantee the idempotency of those close() implementations. It 
seemed reasonable to make the JDK classes AutoCloseable but for AC not to 
require idempotency.

To answer Andrew's second question, I think whether something ought to implement 
AC this depends on the "standard meaning" of close(), but the answer is likely 
yes. I think the "standard meaning" includes some ideas such as the possibility 
of the object referencing some resource external to the JVM, not under (direct) 
control of the garbage collector, for which it would be considered a resource 
leak for close() not to be called, and for which prompt release of that resource 
is considered important.

There's another small wrinkle with AutoCloseable which is that its definition 
changed somewhat in Java 8. Prior to Java 8 there was a sense that any AC 
instance ought to be used within a try-with-resources statement, and not doing 
so merited a warning. In Java 8 this was relaxed somewhat, in that T-W-R should 
be used only for AC instances that are known to contain external resources. The 
driver here was Stream, which implements AC. A Stream might represent a resource 
-- see Files.lines() for example -- in which case T-W-R should be used. However, 
many streams represent only in-memory values, so in those cases T-W-R is 
superfluous.

Finally, several years back there was a bit of discussion on core-libs-dev on 
the issue of whether the XML streams should implement AutoCloseable; see

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/017343.html

At the time the main issue seemed to be a complication with changing the 
specifications, because these APIs were also under the control of an independent 
(non Java SE platform) JSR. In fact that might have been the original reason for 
these APIs not to have been retrofitted in Java 7. Given the passage of time, 
perhaps this is no longer an issue.

s'marks