RFR: 8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) [v4]

[Volker Simonis]

On Fri, 8 Apr 2022 13:21:06 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added API-refinement to GZIPInputStream::read()/ZipInputStream::read() and an Implementation note to ZipFile::getInputStream()
>
> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 173:
> 
>> 171:      * bytes are read and {@code 0} is returned.
>> 172:      * <p>
>> 173:      * If <i>n</i> denotes the returned number of inflated bytes then {@code b[off]}
> 
> I think this might need a slightly different wording since in this case of `ZipInputStream#read(...)`, the entry's  compression method decides whether or not an inflater will be used to return inflated bytes.
> 
> So maybe we should just remove the reference to "inflated bytes" and instead say:
> 
> * If <i>n</i> denotes the return value, then {@code b[off]} through {@code b[off+}<i>n</i>{@code -1]}
> * will contain the data that has been read. The elements {@code b[off+}<i>n</i>{@code ]} through 
> * {@code b[off+}<i>len</i>{@code -1]} are undefined and the implementation may update them during this read
> * operation. If the return value is -1 or an exception is thrown the whole content of {@code b} is undefined.

Thanks for spotting this. As the restriction only applies to compressed entries, I've simply prefixed the text with "*If the current entry is compressed and..*"

-------------

PR: https://git.openjdk.java.net/jdk/pull/7986