[compress] LZWInputStream again

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

Hi all

LZWInputStream's protected members have caused my last attempt to cut a
1.10 release of COMPRESS to fail.  It seemed to be consensus that having
those protected members was unacceptable but there is no real consensus
on what to do instead.

There are the two extremes:

(a) leave everything as it is so subclasses outside of compress are
    still possible.

(b) restrict things as much as possible - i.e. in a way that allows the
    existing LZWInputStream subclasses in compress to work but hide as
    much as possible.

The rationale for (a) hints at the various LZW dialects in existence
that go far beyond what COMPRESS currently supports and for which
subclasses will need free access to the internals.  Image formats using
LZW (TIFF and GIF, likely) are cited.  The position (b) manifests itself
including a patch in COMPRESS-300.

After some thorough research on LZW dialects (i.e. reading the Wikipedia
entry[1] ;-) I can follow the rationale of (a).  Things like the "stop
code" or "early change" look as if they'd need more access to the
internal machinery than a version of LZWInputStream with COMPRESS-300
applied would allow it to have.

There might be some middle ground (let's call it (c)) that adds getters
and setters and only makes the fields private - which should allow
subclasses to be introduced in IMAGING or some PDF processing lib.  I'm
leaning towards implementing this and not go to the extreme of
COMPRESS-300 but would hate to do so if we still couldn't get the
release out.

A fourth alternative (d) is to revert LZWInputStream to its old
unsupported version of 1.9 (including protected fields as they have been
before) and release 1.10 - which is more than overdue by now.

My real goal is to release Compress 1.10 and if reverting the patch is
the only way out I prefer to do that rather than keep being stuck.

Stefan

[1] https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Welch

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