On 6/14/2012 10:37 AM, Phil Race wrote:
On 6/14/2012 10:09 AM, Martin Desruisseaux wrote:
Le 14/06/12 18:59, Phil Race a écrit :
Perhaps the real issue is that the interface Closeable should not
have made
claims about what all the existing close methods it was added to do
in all cases.
FileInputStream.close() made no such claim.
AutoCloseable makes no such claim, but Closeable does. If the intend
was to support ARM without complying with the idempotent criterion,
then ImageInputStream should have extended AutoCloseable rather than
Closeable...
The list of classes implementing each of these looks to be the same
and I'm not sure if there
was careful consideration. But its a very long list and I've not
examined it closely.
I just assume that it would not make sense for either of these to add
requirements beyond
what FileInputStream.close() already did. But its too late to undo
this in any case.
Mea culpa; when I retrofitted Closeable/AutoCloseable to this batch of
classes, since the close methods are not idempoent, the *Image*Stream
types should have been marked AutoCloseable rather than Closeable, a
policy recommended elsewhere:
"Project Coin: Bringing it to a Close(able)"
https://blogs.oracle.com/darcy/entry/project_coin_bring_close
Since JDK 7 has already shipped, changing the implemented interface from
Closeable to AutoCloseble would be a binary incompatible change and
those strongly recommended against. If possible, I think the best way
to address this problem would be to make the methods idempotent.
-Joe
