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.
But anyway, while FileCacheImageInputStream throws explicitly an
IOException, the NullPointerException in FileCacheOutputStream looks
an oversight... To be consistent, it seems to me it should either do
nothing if already closed, or invoke the checkClosed() to throws an
IOException like FileCacheImageInputStream does...
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6363748
has some discussion as to where the nulling out came from but no particular
consideration as to what that means for calling close() twice.
I think it acceptable to make it call checkClosed() conpatibility wise
since apps must already be ready
for an IOException and are actually less like to be ready for the NPE ..
-phil.
Martin
