Hello, Stefan,
thank you, I understand the circumstances and agree – Ant’s zip should stay
simple whereas there is a “superstructure”… I think that I should explore the
commons compress project. It’s possible that it would fit my needs better.
Thanks again… :-)
Roman
----- Pôvodná správa -----
Od: "Stefan Bodewig" <bode...@apache.org>
Komu: user@ant.apache.org
Odoslané: Pondelok, 22. Jún 2020 10:41:12
Predmet: Re: Knowledge sharing related to Apache Ant, mainly ZipFile class…
Hello Roman
many thanks for your comments and your interest in Ant's zip support.
Ant's zip package has been the inspiration and nucleus for the zip
package in Apache Commons Compress and the code has become more evolved
and more versatile over there:
https://commons.apache.org/proper/commons-compress/
Every now and then we've backported bugfixes from Commons Compress but
not additional features. The goal has been to keep the zip package
inside of Ant focussed on what is actually used by Ant's tasks. That the
classes go beyond that scope is mostly due to backwards
compatibility. Therefore I wouldn't want to add comment support to
ZipFile in Ant (as nobody would use it) but could see it being added in
Commons Compress.
In order to make backporting easier we try to not change the code
structure here without changing it on Commons Compress as well - so that
applying patches later becomes easier.
On 2020-06-16, Roman Horváth wrote:
> The first sentence within the file comments sounds:
> Replacement for java.util.ZipFile.
> But in fact, it should sound:
> Replacement for java.util.zip.ZipFile.
> (Similarly, a few lines later.)
True.
> In the constructor ZipFile(final File f, final String encoding, final boolean
> useUnicodeExtraFields) a tiny performance improvement may be made.
Here and in the case of ZipOutputStream#setLevel I'd assume the JIT is
going to eat up the performance gain quickly. Given the constructor (and
setLevel) are likely to be called at most once it will be dwarfed by the
time spent on (de)compression anyway. In this case I'd go for readablity
over performance. This doesn't mean
> closed = !success;
> if (!success) {
was more or less readable then
> closed = !success;
> if (closed) {
in general. But "do the if part if opening the archive has not been
successful" conveys the intent of the code better than "do the if part
if we've set the closed flag".
> I noticed that the ZipFile class got a new method – getName(). This method
> does not have a description. It may be (e.g.) simply (I guessed the version –
> this was the version when I noticed it):
Well, that somehow slipped under the radar. I don't think it is used by
anybody right now. But yes, the docs should be updated.
> I suggest adding a new feature to this class – the overall archive comment.
> (Because the class ZipOutputStream has the method setComment.)
See above. I agree the feature would be useful in Commons Conpress. In
Ant not so much.
Thanks
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
For additional commands, e-mail: user-h...@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
For additional commands, e-mail: user-h...@ant.apache.org
