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

[David Lloyd]

On Tue, Mar 27, 2018 at 10:10 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 27/03/2018 00:09, David Lloyd wrote:
>> I was going for some kind of consistency with the array variants (that
>> is, name the parameter what it is), though they simply use "b" for
>> their parameter name so that interpretation might be a stretch.
>> Should I update them all?
>
> I think this would be good, if you don't mind doing it.

OK.

>> I'm not 100% familiar with the new JavaDoc categories (ok I'm 0%
>> familiar), but the JEP for these says "This category consists of
>> commentary, rationale, or examples pertaining to the API.".  But this
>> feels more like specification to me since it is "specifications that
>> apply to all valid implementations, including preconditions,
>> postconditions, etc.".  Which is to say, if you don't provide enough
>> remaining space in the output buffer, you will have incorrect
>> operation as a result.  WDYT?
>
> The current wording (which pre-dates your changes of course) reads more like
> API advice. I think it's a bit confusing too as it doesn't define what a
> "flush marker" is. I think we will need to re-word that sentence to make it
> clearer.

OK.  I am at a loss for a better way to explain it though; any suggestions?

>>> I don't have cycles just now to go through all the implementation but I
>>> think Sherman is doing that. It will need careful review to avoid being
>>> abused to attack memory outside of the buffer. I did check the use of
>>> position() and limit() to calculate the remaining and these need correct.
>>
>> I hope this was a typo of "these seem correct" and not a typo of
>> "these need correcting"?
>
> Oops, this was indeed a typo in my mail.

OK great.

-- 
- DML