You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stefan Bodewig <bo...@apache.org> on 2015/02/01 07:04:10 UTC
[compress] (Internal)LZWInputStream
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?
* (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.
Any opinions?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] (Internal)LZWInputStream
Posted by Gary Gregory <ga...@gmail.com>.
All I care about is binary compatibility in a minor release for most cases
(not 80% of the cases, but more like 99.9%). I do not want to be in jar
hell.
Gary
On Sun, Feb 1, 2015 at 1:04 AM, Stefan Bodewig <bo...@apache.org> wrote:
> 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?
>
> * (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.
>
> Any opinions?
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [compress] (Internal)LZWInputStream
Posted by Stefan Bodewig <bo...@apache.org>.
On 2015-02-02, Damjan Jovanovic wrote:
> 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.
Thank you for chiming in, Damjan. Could you please take a look at
Sebb's patch in COMPRESS-300 to see whether it takes away features you
actually need for Imaging?
If we expose LZWInputStream we should do so in a way that it remains
useful outside of Compress as well. I don't think protected fields are
necessary to achieve this, but being able to modify the fields freely
may be.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] (Internal)LZWInputStream
Posted by Damjan Jovanovic <da...@apache.org>.
Hi
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.
Damjan
On Sun, Feb 1, 2015 at 4:17 PM, Benedikt Ritter <be...@gmail.com> wrote:
>
>
> Send from my mobile device
>
>> Am 01.02.2015 um 07:04 schrieb Stefan Bodewig <bo...@apache.org>:
>>
>> 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: 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] (Internal)LZWInputStream
Posted by Benedikt Ritter <be...@gmail.com>.
Send from my mobile device
> Am 01.02.2015 um 07:04 schrieb Stefan Bodewig <bo...@apache.org>:
>
> 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: 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
Re: [compress] (Internal)LZWInputStream
Posted by sebb <se...@gmail.com>.
On 1 February 2015 at 18:33, Jochen Wiedmann <jo...@gmail.com> wrote:
> On Sun, Feb 1, 2015 at 7:04 AM, Stefan Bodewig <bo...@apache.org> wrote:
>
>> * (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.
>
> Make them private and be prepared to reverse the decision by pushing
> out another release, if required.
I like that solution.
I have created COMPRESS-300 with a suggested patch.
Note that it does not use generic setters, as some of the fields were
only ever set to a single value externally.
> Jochen
>
>
>
> --
> Our time is just a point along a line that runs forever with no end.
> (Al Stewart, Lord Grenville)
>
> ---------------------------------------------------------------------
> 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
Re: [compress] (Internal)LZWInputStream
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Sun, Feb 1, 2015 at 7:04 AM, Stefan Bodewig <bo...@apache.org> wrote:
> * (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.
Make them private and be prepared to reverse the decision by pushing
out another release, if required.
Jochen
--
Our time is just a point along a line that runs forever with no end.
(Al Stewart, Lord Grenville)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org