Are there any further comments on this? If not, would it be possible to get a sponsor for this change?
Sorry again for the detached email threads; I've learned my GMail lesson well... Thanks. On Fri, Mar 16, 2018 at 8:25 AM, David Lloyd <david.ll...@redhat.com> wrote: > Sorry, that was an error on my part, caused by too much context > switching. I've posted an update at > https://github.com/dmlloyd/openjdk/commit/zlib-bytebuffer-v13 which is > also attached. > > On Wed, Mar 14, 2018 at 8:53 PM, Xueming Shen <xueming.s...@oracle.com> wrote: >> Hi David, >> >> https://github.com/dmlloyd/openjdk/commit/zlib-bytebuffer-v12 >> >> Should we start to review the changes included in above link, or we should >> wait ? It appears >> the API is being updated but some implementation have not been updated to >> follow the spec >> yet, especially the piece that deals with the output buffer/byteWritten when >> DataFormatException >> is raised, for example >> >> (1) the "outputConsumedID" is defined but never used to update the >> corresponding java field >> in Inflater.c and >> >> (2) the "outputConsumed" is used to update the output ByteBuffer when DFE >> raised (in Java), but >> the corresponding "byteWritten" is not being updated before the >> exception is thrown. >> >> -Sherman >> >> >> >> >> On 3/13/18, 10:46 AM, David Lloyd wrote: >>> >>> Sorry all, it looks like GMail doesn't know how to keep replies with >>> the thread when you change the subject line. The follow-up to this >>> thread is >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/051960.html >>> with only a few small changes as discussed above. >>> >>> On Fri, Mar 2, 2018 at 2:36 PM, David Lloyd<david.ll...@redhat.com> >>> wrote: >>>> >>>> On Fri, Mar 2, 2018 at 2:34 PM, David Lloyd<david.ll...@redhat.com> >>>> wrote: >>>>> >>>>> On Fri, Mar 2, 2018 at 12:49 PM, Xueming Shen<xueming.s...@oracle.com> >>>>> wrote: >>>>>> >>>>>> 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? >>>>> >>>>> You're right, I missed that one. I've incorporated this fix locally: >>>> >>>> Oops, this should have been: >>>> >>>> --- 8< --- cut here --- 8< --- >>>> >>>> diff --git a/src/java.base/share/classes/java/util/zip/Deflater.java >>>> b/src/java.base/share/classes/java/util/zip/Deflater.java >>>> index 524125787a8..40f0d9736e2 100644 >>>> --- a/src/java.base/share/classes/java/util/zip/Deflater.java >>>> +++ b/src/java.base/share/classes/java/util/zip/Deflater.java >>>> @@ -481,9 +481,9 @@ public class Deflater { >>>> * in order to determine if more input data is required. >>>> * >>>> *<p>This method uses {@link #NO_FLUSH} as its compression flush >>>> mode. >>>> - * An invocation of this method of the form {@code >>>> deflater.deflate(b)} >>>> + * An invocation of this method of the form {@code >>>> deflater.deflate(output)} >>>> * yields the same result as the invocation of >>>> - * {@code deflater.deflate(b, 0, b.length, Deflater.NO_FLUSH)}. >>>> + * {@code deflater.deflate(output, Deflater.NO_FLUSH)}. >>>> * >>>> * @param output the buffer for the compressed data >>>> * @return the actual number of bytes of compressed data written to >>>> the >>>> >>>> --- 8< --- cut here --- 8< --- >>>> >>>> -- >>>> - DML >>> >>> >>> >> > > > > -- > - DML -- - DML
