Hi, Tom,
I support the "auto-close". But I still think all programmers should
still close their streams, anyway, even if the stream supports
"auto-close". This is why we don't tell anyone!
If a person doesn't finish reading all the data, then the auto-close
won't happen. But good programmers still close their stream in the
finally block. So it doesn't matter.
If the person is relatively new to java / or incompetent, the stream
gets garbage-collected. This person wasn't going to call
releaseConnection() anyway! As long as the AutoCloseInputStream
includes a finalize() method that closes itself for this worst case -
partial data read with no close() - we're okay:
protected void finalize() throws IOException {
close();
}
I know "finalize()" is to be avoided in 99.99999% of situations. This
is the one exception. Take a look to java.io.FileInputStream's source
code. It does the same. Implementing finalize() introduces a big
performance hit for garbage collection, but how many streams a second
are we going to be garbage collecting, anyway?
I think ditching "releaseConnection()" in favour of
InputStream.close() is very important. Automatically releasing when
EOF is read is more in spirit with a garbage-collecting language like
Java. It's a safety net for those days when we forget which bag in
the fridge is holding the real coffee, and accidentally grab the bag
holding the decaf.
--
yours,
Julius Davies
416-652-0183
http://juliusdavies.ca/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
