Julius, > java.io.FileInputStream ... finalize()
IMHO, this was also a mistake. The finalize() method allows programs that don't close streams to (appear to) work under light load, because the GC runs often enough to close some streams before running out of file descriptors. Under heavy load, that program will encounter transient file opening failures. Without the finalize(), this would be caught during testing, because a program that doesn't close its streams will quickly run out of FDs. The finalize() makes it more likely that this class of bugs will go undetected in development and cause problems in the field. This is the "should frameworks compensate for programmer errors" debate (which I'm happy to go on with, but if so we should probably move it off-list). auto-close also falls into this category, but additionally has a more practical problem: it changes the semantics of the stream in a way that causes it to not interoperate properly with, e.g, BufferedInputStream. If the implementation of auto-close (actually, auto-release) were changed to make it transparent, I'd have no problem with it (except philosophically). Seems easier to make it optional, though. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
