You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Jesse Glick <ty...@gmail.com> on 2013/03/31 13:49:58 UTC
Re: svn commit: r1462931 - in /ant/core/trunk: WHATSNEW manual/Tasks/ear.html
manual/Tasks/jar.html manual/Tasks/war.html manual/Tasks/zip.html
On 03/31/2013 07:24 AM, bodewig@apache.org wrote:
> +<p>When Ant writes compressed entries into the archive it creates it
> + doesn't know the compressed size of an entry before it has been
> + written. Unfortunately the decision whether a Zip64 extra field
> + will be written has to be made before writing the entry's
> + content.</p>
Seems like there should be some way around this, by compressing to a temporary buffer perhaps?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: svn commit: r1462931 - in /ant/core/trunk: WHATSNEW manual/Tasks/ear.html manual/Tasks/jar.html manual/Tasks/war.html manual/Tasks/zip.html
Posted by Stefan Bodewig <bo...@apache.org>.
On 2013-03-31, Jesse Glick wrote:
> On 03/31/2013 02:20 PM, Stefan Bodewig wrote:
>>> compressing to a temporary buffer perhaps?
>> We do so for STORED entries and risk OutOfMemoryExceptions (we could
>> throw away the buffer and just count). The performance impact would be
>> non-trivial for big files, which is what Zip64 really is about.
> Do you know when you start the entry how big it is _uncompressed_?
Not in general - input could be a resource of unknown size - but in most
cases.
> If so, you could say that for anything largish, just compress to a
> temporary file, and then write the entry from that.
Sure, but the performance impact would remain. Reading 4 GB or more
takes time, writing even more so, and you don't want to do that twice.
> Not sure if such hacks are worth the effort just to support Java 5,
> which is long past EOL anyway.
Agreed. With the new attribute you have the choice of not supporting
Java5. What's more, if you really needed Zip64 Java5 (or 6) wouldn't be
able to read the file anyway - Java6 doesn't reject files with Zip64
extensions, it just ignores them. That's why I've chosen to turn them
off by default in <jar> but left them enabled in <zip>.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: svn commit: r1462931 - in /ant/core/trunk: WHATSNEW manual/Tasks/ear.html
manual/Tasks/jar.html manual/Tasks/war.html manual/Tasks/zip.html
Posted by Jesse Glick <jg...@cloudbees.com>.
On 03/31/2013 02:20 PM, Stefan Bodewig wrote:
>> compressing to a temporary buffer perhaps?
>
> We do so for STORED entries and risk OutOfMemoryExceptions (we could
> throw away the buffer and just count). The performance impact would be
> non-trivial for big files, which is what Zip64 really is about.
Do you know when you start the entry how big it is _uncompressed_? If so, you could say that for anything largish, just compress to a temporary file, and then write the
entry from that.
Not sure if such hacks are worth the effort just to support Java 5, which is long past EOL anyway.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: svn commit: r1462931 - in /ant/core/trunk: WHATSNEW manual/Tasks/ear.html manual/Tasks/jar.html manual/Tasks/war.html manual/Tasks/zip.html
Posted by Stefan Bodewig <bo...@apache.org>.
On 2013-03-31, Jesse Glick wrote:
> On 03/31/2013 07:24 AM, bodewig@apache.org wrote:
>>> <p>When Ant writes compressed entries into the archive it creates it
>>> doesn't know the compressed size of an entry before it has been
>>> written. Unfortunately the decision whether a Zip64 extra field
>>> will be written has to be made before writing the entry's
>>> content.</p>
> Seems like there should be some way around this, by compressing to a
> temporary buffer perhaps?
We do so for STORED entries and risk OutOfMemoryExceptions (we could
throw away the buffer and just count). The performance impact would be
non-trivial for big files, which is what Zip64 really is about.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org