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

[Alan Bateman]

On 27/03/2018 00:09, David Lloyd wrote:
> :
> I think they may have use in some cases e.g. reading a dictionary from
> a file, and generally in code which prefers byte buffers over arrays
> (completely outside of the direct/heap buffer question), and they were
> easy enough to implement.  But I'm okay dropping these methods if that
> is what is desired.
I'm in two minds on the setDictionary methods. No objection to including 
them for consistency reasons, I'm just not sure if they will really be used.


> :
>> I also wonder if the parameter should be renamed to "input" or "source".
> 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.


> :
> 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.

>
>> 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.

-Alan