commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Rosenvold <>
Subject Re: [compress] Importance of retaining exact compatibility for ZipArchiveOutputStream ?
Date Wed, 31 Dec 2014 14:32:50 GMT
2014-12-31 11:50 GMT+01:00 Stefan Bodewig <>:
> 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 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message