Hi, after the 1.2 release is out I've merged back the ZIP64 branch, which means compress' trunk now requires Java5.
Before I merged the branch I created a new one from trunk in case we ever want to create a Java 1.4 compatible 1.2.1 release. The current status of ZIP64 support is: * ZipArchiveInputStream seems to work - I'll hope to find some time on a Windows box for some interop tests with Windows' Compressed Folders today. * ZipArchiveOutputStream works except for one case, which is a common one, unfortunately: compressing data to a non-seekable output without knowing the original size of the data. I'll likely need some advice and will raise that on a separate thread once I've read up on how InfoZIP handles this. As an aside, it turns out that Deflater#getBytesRead is broken and doesn't return the number of bytes read but rather "number of bytes read modulo 2^32", at least on Oracle's Java6, so I had to count the bytes myself and the main reason for the switch to Java5 has become moot. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
