On 2014-12-30, Kristian Rosenvold wrote: > I fixed all comments and reinstated the protected Deflater.
Thanks, looks good. > The whole ZipArchiveOutputStream class reminds me of a few of the > 3000+ LOC java classes I refactored in maven core; sometimes the only > acceptable solution is to extract *all* the logic into other classes > and just make the "old" class keep instantiate all the fields and pass > them on to the underlying "new" classes with cleaner > responsibilities. I'm not really saying this should be done, but the > class has that "distinct" feeling :) Well, when I started it more than thirteen years ago (had to look that up :-) it was only ~600 lines and then it grew from that. I'm not trying to defend anything, the class has outgrown its initial scope by far and backwards compatibility constraints have made it more or less impossible to refactor it properly. This is one reason why I started the compress antlib as the same was true for Ant's <zip> task family. Some day I'll find time to revive the currently dormant compress 2.0 effort ... > I took Gary's "cheap" solution to the StreamCompressor "subclass" > issue; I just made the whole streamcompressor package private and not > a part of any public api. Given that it's not really meant to be an > extension point I think this is adequate. +1 Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
