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
