hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Lipkis <...@pss.com>
Subject Re: [HttpConn][HttpClient] status update
Date Sun, 11 Feb 2007 00:27:25 GMT

> 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,


To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org

View raw message