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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org