[compress] Preparing for 1.12

[Stefan Bodewig <bo...@apache.org>]

Hi all

we've got a nice set of fixes and new features added since 1.11 and I
plan to cut the next release soonish. The only thing I want to do prior
to the release is adding a few words of documentation about the IWA
support in Snappy.

Based on prior experience I'd like to give folks a chance to look at the
current site build at
<http://stefan.samaflost.de/staging/COMPRESS-1.12/index.html>, in
particular at the reports.

You'll see that findbugs is unhappy about inconsistent synchronization
introduced when I made the finish method of BZip2CompressorOutputStream
synchronized due to COMPRESS-357

Yes, blockSorter is accessed unsynchronized in different places, but we
don't need to care as the class isn't thread safe anyway and all we
wanted to do is to avoid a race condition with GC. I'd prefer to
suppress the warning over synchronizing more of the class.

Any feedback more than welcome.

Stefan

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

Re: [compress] Preparing for 1.12

[Stefan Bodewig <bo...@apache.org>]

On 2016-06-10, Stefan Bodewig wrote:

> We have it in two cases, ZipFile and BZip2CompressorOutputStream -
> ZipFile uses a volatile flag rather than synchronization and
> null-assignment, maybe that's the better option anyway.

I've changed the code and findbugs is happy again, updated site build at

http://stefan.samaflost.de/staging/COMPRESS-1.12/

Stefan

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

Re: [compress] Preparing for 1.12

[Stefan Bodewig <bo...@apache.org>]

On 2016-06-10, Torsten Curdt wrote:

>> You'll see that findbugs is unhappy about inconsistent synchronization
>> introduced when I made the finish method of BZip2CompressorOutputStream
>> synchronized due to COMPRESS-357

> My feedback: I'd rather recommend to get rid of the finalize over adding
> synchronization. Using finalize is rarely a good idea. I wasn't aware we
> have that in the code base.

We have it in two cases, ZipFile and BZip2CompressorOutputStream -
ZipFile uses a volatile flag rather than synchronization and
null-assignment, maybe that's the better option anyway.

Even if we agree that having finalize in BZip2CompressorOutputStream we
can't easily change the behavior without breaking code that relies on
not being forced to finish the stream.

Stefan

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

Re: [compress] Preparing for 1.12

[Torsten Curdt <tc...@vafer.org>]

>
>
> You'll see that findbugs is unhappy about inconsistent synchronization
> introduced when I made the finish method of BZip2CompressorOutputStream
> synchronized due to COMPRESS-357
>
> Yes, blockSorter is accessed unsynchronized in different places, but we
> don't need to care as the class isn't thread safe anyway and all we
> wanted to do is to avoid a race condition with GC. I'd prefer to
> suppress the warning over synchronizing more of the class.
>
> Any feedback more than welcome.
>

My feedback: I'd rather recommend to get rid of the finalize over adding
synchronization. Using finalize is rarely a good idea. I wasn't aware we
have that in the code base.