commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: [compress] Need API Feedback/Advice for ZipArchiveOutputStream ans ZIP64
Date Mon, 08 Aug 2011 07:57:41 GMT
On 2011-08-08, Phil Steitz wrote:

> On 8/6/11 9:30 PM, Stefan Bodewig wrote:
>> On 2011-08-06, Phil Steitz wrote:

>>> On 8/5/11 9:40 PM, Stefan Bodewig wrote:

>>>> InfoZIP's ZIP has decided to make it an option for the whole archive
>>>> (the command line doesn't offer much flexibility here) and make it
>>>> default to ZIP64.
>>>> My current thinking is that is a likely candidate for the
>>>> receiving end of ZIPs we create, so it may be better to turn ZIP64 off
>>>> by default, but I'm not sure.
>>>> I'm leaning towards adding a setUseZip64(boolean) method at the level of
>>>> ZipArchiveOutputStream and make it default to false.  This method could
>>>> be called in between putArchiveEntry calls to make it apply selectively
>>>> to indiviual entries.
>>> Sounds reasonable.
>>>> The name is totally open for debate since as it stands it sounds as if
>>>> you could turn off all Zip64 features which I wouldn't want to do for
>>>> the cases that can be dealt with transparently.  Then again it could use
>>>> a Boolean argument with "null" meaning "do the best you can" and false
>>>> "don't even use Zip64 if you think it is safe".
>>> I don't get what you mean by "do the best you can."  Does that mean
>>> turn it on when needed if somehow you know it is needed, per entry,
>>> I assume?
>> Actually I was thinking about what the method would mean for the other
>> combinations as well.  A "null" value doesn't make sense for the
>> specific case I'm asking about - here we need to decide what the default
>> should be: Zip64 or not.  For the other cases "null" could mean "use
>> Zip64 if you think you need it" i.e. what is omplemented right now,
>> "true" could mean "always use it" and "false" could mean "never use it,
>> throw an exception if you recognize it would be required".

> I guess an alternative would be an enum with values "allowed,"
> "always," and "never," which would work for the "other" cases; but
> maybe be a little unnatural for the simple case above, where I guess
> you would have to either throw on the "allowed" setting or view it
> as synonymous with "always".

I'm still not used to the fact that Compress is at Java5 now, so I
didn't think of enums.  It feels better than the null Boolean to me.
"asNeeded" could be an alternative to "allowed".

> As a test of whether or not it will work, I would recommend writing
> the javadoc and test cases first (which of course we all do any way ;)

Absolutely ...


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

View raw message