On Mon, Nov 23, 2009 at 8:40 AM, Jesse Wilson <jessewil...@google.com>wrote:
> Rolled back as r883400. I'll investigate the Pack200 test problems and push > this back in after code freeze. > FYI: The root problem is a bug in our ZIP decoding. It fails to cope with Z_SYNC_FLUSH blocks and crashes. I've submitted a failing testcase that demonstrates the problem: http://svn.apache.org/viewvc?view=revision&revision=883478 This test case passes on the RI. There's an unfortunate consequence of adding flush() support to deflate/zip/gzip; one I probably should have forseen before checkin. When a Deflater/Zip/GzipOutputStream is wrapped by a FilterOutputStream (such as BufferedOutputStream), the compressed datastream will be *different* if we support flush; even if the user doesn't call flush() directly. Here's why... BufferedOutputStream.close() always calls this.flush(), which in turn calls delegate.flush(), DeflaterOutputStream.flush() emits a Z_SYNC_FLUSH block if we support flushing. If we don't support flushing, that block isn't emitted. As far as I'm concerned, supporting flush is the right thing to do. It's essential for any kind of compressed interactive network channel, such as XEP-0138 <http://xmpp.org/extensions/xep-0138.html> for compressed instant messaging streams. I'll investigate fixing the Jar bug...
