commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damjan Jovanovic <>
Subject Re: [compress] (Internal)LZWInputStream
Date Mon, 02 Feb 2015 07:42:38 GMT

I have a patch waiting to be committed to commons-imaging which uses
the LZW stuff in commons-compress (brief mention of it by me on
IMAGING-126), so it could break with these changes. My hope was to
wait for the next release of compress before committing, so I could
use that version of compress as a dependency.

Also, LZW is a very loose algorithm with many important differences
between implementations in ZIP, Z, TIFF, GIF, etc. It is difficult to
generalize. I was even somewhat against the idea of making a general
LZWInputStream, as opposed to a customized LZW decompressor in every
place where it's needed. Just changing things in the class because of
how it seems to be used in compress, will definitely make more general
use difficult/impossible. IIRC, some code in imaging already did need
to set variables which no code in compress does.


On Sun, Feb 1, 2015 at 4:17 PM, Benedikt Ritter <> wrote:
> Send from my mobile device
>> Am 01.02.2015 um 07:04 schrieb Stefan Bodewig <>:
>> Hi
>> I'm trying to bring together two separate discussions from two different
>> [VOTE]-threads.  It seems as if I should cancel the RC2 vote and before
>> I rush another RC maybe we can get consensus on what to do.
>> * my experiments show that moving the LZWInputStream class hasn't got as
>>  big an impact on subclasses of ZCompressorInputStream as I and others
>>  would have expected.  This likely means we can relax the warning of
>>  the release notes and site again.  Right?  Is anybody going to perform
>>  more experiments?
> I think we're safe to asume that the change will not break clients.
>> * (Internal)LZWInputStream has a bunch of protected fields that slipped
>>  through a few releases ago.  We should add getter/setter pairs and
>>  deprecate using the fields.  Sebb would like to even make the fields
>>  private assuming the chance of people actually subclassing
>>  ZCompressorInputStream and using said fields is very small.
> Even creating getters and setters and deprecating the fields is the way to go here, IMHO.
>> Any opinions?
>> Stefan
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message