re:but AFAIK zip and jar share the same compression algorithm anyway.
The algorithms are similar but not the same. re:...and then add a methods for bzip2, compress and gzip, too? See where I am heading? Better let's have a CompressUtils in compress. Compress doesn't work with files while IO does. On the other hand IO doesn't work with compression while Compress does ;-) I think it would be good idea to add compress to IO :-) IMHO My codes fits better IO (I took the idea from IO source code). But if the community won't reject I'll post a patch to IO. Regards, Vitaliy S On 6/18/06, Torsten Curdt <[EMAIL PROTECTED]> wrote:
> re: http://jakarta.apache.org/commons/sandbox/compress/ > Thanks for a link, but my code couldn't be applied to compress. Compress > does nothing with jar. Doesn't mean that could not be changed ;-) ...but AFAIK zip and jar share the same compression algorithm anyway. So why the two methods? (Did I miss something?) > re:IMO compression is beyond the scope of IO. > Consider this example from > http://weblogs.java.net/blog/kgh/archive/2005/11/my_favorite_dea.html <snip/> > To me apache commons is a set of projects that provide short cuts for common > things. > Of course we all like clean disgin, but I like "clean design" unless it > doesn't make me to write 20 lines of code to simply zip or jar the folder > (same goes for file reading). I agree. All I am saying is that it should probably better go into the compress component. > IO Commons provides means to read file into byte array, why not to add a > method to read a file or dir as compressed byte array too? ...and then add a methods for bzip2, compress and gzip, too? See where I am heading? Better let's have a CompressUtils in compress. WDYT? cheers -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Regards, Vitaliy S
