commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [compress] change behavior of bzip-output finalize?
Date Mon, 13 Jun 2016 09:59:36 GMT
On 13 June 2016 at 10:19, Stefan Bodewig <bodewig@apache.org> wrote:
> 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.

AIUI finalize() is not guaranteed to be called, so any code that
relies on it is liable to be disappointed from time to time.

IMO at best one can use finalize() - *if* indeed it gets called - to
warn users that they have not closed a resource.

> Cheers
>
>         Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

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


Mime
View raw message