Hi all
I'm trying to bring a discussion from COMPRESS-357 over to the list.
The bzip2 output stream has a finish method that is used to ensure all
data has been written to the stream and a separate close method that
invokes finish. And it overrides finalize to invoke finish in case
people have forgotten to close the stream - this behavior has been
present in the very first release of [compress].
The discussion in COMPRESS-357 shows that we'd need to synchronize - or
make volatile - quite a bit of code inside of
BZip2CompressorOutputStream for finalize to work properly. The
alternative is to simply no longer invoke finish from finalize (but log
an error if an unclosed stream is detected). This is a change that
breaks backwards compatibility but most likely only for people who are
doing something wrong. It may be OK to change it if the change is
advertized properly as it shouldn't affect too many people anyway.
There is one other instance of finalize doing the same - ZipFile. Here I
remember why it is the case, Ant uses its version of ZipFile inside of
its classloader and keeps the ZipFile instances open until the
classloader is disposed of - it might be possible to invoke close on the
ZipFile instances in the classloader's finalize but back then it looked
easier that way.
In the case of ZipFile I'd argue the only field that needs to be
published safely apart fromt the volatile closed flag is "archive" which
is final, so we should be safe.
Cheers
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
