Exposing LZ77 sliding window size in the java.util.zip.[Inflator|Defaltor] API

Stanimir Simeonoff stanimir at riflexo.com
Tue Aug 26 11:07:07 UTC 2014


If there would be any changes to Deflater/Inflater I'd strongly suggest
enabling them to operate with direct buffers.  Working with byte[] forces a
copy in the native code which is suboptimal.
Probably there should be a concern on memLevel for Deflate as well, iirc it
uses the 8 by default (max being 9). memLevel is different than the sliding
window but still allocates 2^(7+memLevel+1) bytes.

Several years ago I found out a java implementation of Deflate
out-performed the provided native code. So I abandoned the built-in
library. Plus it's possible to implement Z_SYNC_FLUSH naturally instead of
changing the compression level back and forth to achieve similar effect.
Also reusing a java pooled Deflater doesn't need free the allocated memory
unlike calling end() of the zlib one. The only downside probably is the
increased heap usage which could be an issue for huge heaps (although it's
mostly primitive arrays).


On Tue, Aug 26, 2014 at 11:45 AM, Mark Thomas <markt at apache.org> wrote:

> Hi,
> I'm currently working on the implementation of the WebSocket
> permessage-deflate extension for Apache Tomcat. I am using the JRE
> provided classes java.util.zip.[Inflator|Defaltor] to do the compression
> and decompression.
> I have a working implementation but there is one feature I can't
> implement because the necessary API isn't available.
> The WebSocket permessage-deflate specification [1] allows both the
> client and server to specify a number between 8 to 15 inclusive
> indicating the base-2 logarithm of the LZ77 sliding window size. The
> purpose of this feature is to enable both the client and the server to
> limit the size of the buffer they need to maintain to reduce their
> memory footprint per connection.
> Would it be possible for the java.util.zip.Inflator and
> java.util.zip.Defaltor API to be extended to expose the LZ77 window
> size? My suggestion would be an additional constructor for each class
> that took and additional int parameter for window size but I'd be happy
> with any API that provided control of the window size.
> Cheers,
> Mark
> [1] http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-18

More information about the core-libs-dev mailing list