commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: [compress] release 1.1?
Date Thu, 22 Jul 2010 20:12:20 GMT
>> whenever one want to get to the properties of an ArchiveEntry one has
>> to figure out what actual implementation it is.
> I know what you mean
> <>

Exactly ...and look how similar calls are in the end.

> Between 1.0 and 1.1 I pushed getLastModifiedDate into ArchiveEntry to
> simplify a very common case.

Maybe we should add some more there.

>> If a particular ArchiveEntry doesn't support e.g. getGroup() it would
>> just return null ...but I am a little back and forth on this. Mostly
>> because of methods returning primitives
> I solved this by returning Interger.MIN_VALUE - the group id should
> never be < 0 anyway.

True. But this doesn't necessarily work for all primitives. I guess we
could return Objects.

>> ...and the bloat of the interface.
> That's been my main concern as well and that's why I stopped with the
> last modified date.

Right. What we could think of is to delegate the metadata by type.


and so encapsulate the specifics. If an ArchiveEntry cannot provide the
information it would return null. Still feels a little bit
over-engineered though.

> All four archive implementations of trunk support file permissions and
> use something like the Unix stat structure which means they are at least
> interchangeable (cpio actually returns a long but the value will never
> be outside the scope of an int).  At some point in time I thought about
> unifying it (and move the UnixStat helper from the ZIP package somewhere
> more accessible) but think I deferred it because I considered the 1.1
> release to be too close - and forgot about it later.

But I think we should look into this.


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

View raw message