commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: [compress] A few comments
Date Wed, 18 Jun 2008 09:19:54 GMT

On Jun 18, 2008, at 10:32, Emmanuel Bourg wrote:

> Torsten Curdt a écrit :
>>> - the exceptions could extend IOException
>> Could - but why restrict it that way? (composition over inheritance)
> I don't see this as a restriction.

Well, it means all ArchiveException necessarily need to be  
IOExceptions. That's restricts their type.
I don't see the benefit.

> An issue during a compression or archive operation is an IO  
> exception to me. The TrueZIP developers made the same assumption:

I don't realy see that being an argument :) ...they^^^^he did other  
very weird design decisions, too. :)

>>> - IOUtils.copy(in, out) could call copy(in, out, size)
>> Where is that?
> In the org.apache.commons.compress.utils.IOUtils class from Chris  
> archive.


>>> - the header in ArArchive*Stream could be factorized (ArConstants?  
>>> along with the sizes of the entry fields)
>> Hm ...IMO only useful if used somewhere else. Otherwise it's just  
>> work. Or where do you see the benefit?
> Just to have a cleaner code. PMD or Checkstyle will complain about  
> "magic numbers" otherwise.

Cleaner code is debatable :) ...but if someone wants to do it. *shrug*

>>> - Ant has a JarMarker class that extends ZipExtraField, is there  
>>> an equivalent ?
>> Could you elaborate?
> I don't know what it is, but it seems the Ant source is more recent  
> than the code in compress, it might be good to resync the code with  
> Ant.


>> Hm ...indeed. But IMO the changeset stuff is where it actually gets  
>> interesting :)
> It's also the most debatable topic, and it will delay the release.  
> The other stuff is ready for a release.

In what sense debatable?
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message