[JDK-6341887] RFR: Patch V3: java.util.zip: Add ByteBuffer methods to Inflater/Deflater

[Xueming Shen]

Hi David,

(1) Deflater.deflate(Bytebuffer)
      the api doc regarding "no_flush" appears to be the copy/paste of the byte[] version
      without being updated to the corresponding ByteBuffer?

(2) Inflater.inflate()
      a "inputConsumed" field is added to handle the "bytes-read" if a DFE is being thrown.

      While the API doc specifies that "if the setInput(bytebuffer) method was call ...."
      it appears the inputPos/bytesRead are being updated for the "setInput(byte[]) case
      as well. This might be a desirable change, but is an "incompatible" behavior change
      as well. I doubt if there is any existing app depending on this existing behavior though,
      it's really hard, if not impossible, to try to recover from this kind of error

      There might also bring in a little inconsistency, as we are updating the "input" in this
      case,  but why not the "output" buffer? It's true there is no way to do that with the
      inflate(byte[] ...), it's kinda doable for the inflate(ByteBuffer) and in fact there might
      be bytes that have been written into the output ByteBuffer in this case.

(3) there are usages like
      Math.max(buf.limit() - outputPos, 0);
      just wonder if there is any reason not using existing api method.
      Math.max(buf.remaining(), 0);

sherman

On 03/02/2018 08:07 AM, David Lloyd wrote:
> The third... and hopefully final... version of this patch is attached.
> It is the same as V2, however it also uses
> Reference.reachabilityFence() defensively on buffers.  This may be
> necessary because there are code paths which may allow such buffers to
> be GCed after their address is acquired but before the native code
> successfully is able to read it.
>
> The online version of this patch is visible at [1].
>
> [1] https://github.com/dmlloyd/openjdk/commit/zlib-bytebuffer-v8
>