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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
