On 2015-01-31, sebb wrote:
Given that the protected fields were in a class marked as internal, it
seems arguable that users should not have referred to any of the items
in it.
Therefore we could potentially make all the mutable protected fields
private (and add protected getters).
Even if
On 31 January 2015 at 09:03, Stefan Bodewig bode...@apache.org wrote:
On 2015-01-31, sebb wrote:
Given that the protected fields were in a class marked as internal, it
seems arguable that users should not have referred to any of the items
in it.
Therefore we could potentially make all the
On 2015-01-31, sebb wrote:
On 31 January 2015 at 09:03, Stefan Bodewig bode...@apache.org wrote:
On 2015-01-31, sebb wrote:
Given that the protected fields were in a class marked as internal, it
seems arguable that users should not have referred to any of the items
in it.
Therefore we
On 31 January 2015 at 11:41, Stefan Bodewig bode...@apache.org wrote:
On 2015-01-31, sebb wrote:
On 31 January 2015 at 09:03, Stefan Bodewig bode...@apache.org wrote:
On 2015-01-31, sebb wrote:
Given that the protected fields were in a class marked as internal, it
seems arguable that users
On 30 January 2015 at 15:41, sebb seb...@gmail.com wrote:
I've just had a look at the new class ZCompressorInputStream.
Sorry, I meant LZWInputStream
This has lots of mutable protected fields.
For example,
protected int clearCode = -1;
protected int codeSize = 9;
clearCode has a
I've just had a look at the new class ZCompressorInputStream.
This has lots of mutable protected fields.
For example,
protected int clearCode = -1;
protected int codeSize = 9;
clearCode has a protected setter, but no getter.
What's the point of that?
As far as I can tell, these are
OK, next attempt.
Compress 1.10 RC2 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/
(svn revision 7884)
Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-1081/org/apache/commons/commons-compress/1.10/
