2014-12-31 11:50 GMT+01:00 Stefan Bodewig <bode...@apache.org>: > On 2014-12-30, Kristian Rosenvold wrote: >> 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.
Tell me about it. I get serious itches related to such classes :) But not right now. Must n-o-t shave more yak. > > 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 am really not sure big breaks in compatibility are ever worth it. So that means we just have to be even more clever :) On a related note, I just added the *last* substantial change I intend to do. I will do a tweak or two, and I'm sure that last class will trigger a truckload of comments, even just the name of the class:) The remaining stuff in https://github.com/krosenvold/commons-compress/tree/trunk will now go to plexus. Take a look at "ConcurrentJarCreator" in my git repo for a full-scale sample of how to make a zip file. Things on my todolist for c-compress: A) Make a way to remove tempfiles written by ScatterGatherBackingStore. I suspect this will involve renaming existing "close" method to something like "reverse" and making close actually "close" (and delete) everything. B) Optimize LFH generation. I want this in the concurrent scatter part. The problem with this is that to do this I will need to make a thread-safe ZipArchiveEntry implementation. Which I have been trying to avoid. But there's no way around that. Kristian --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
