Thanks Mandy! I removed the ln#657-#663, and updated the @apiNote in deflter, inflater and zipfile accordingly, mainly combined your comment and the approach for the fis/fo. they are "simpler" and straightforward now, at least for me. https://bugs.openjdk.java.net/browse/JDK-8187485 http://cr.openjdk.java.net/~sherman/8185582/webrev -Sherman On 9/27/17, 3:08 PM, mandy chung wrote:
Comment on the CSR:
On 9/26/17 11:35 PM, Xueming Shen wrote:
I think the @apiNote can be simpler.
Deflater (similar comment for Inflater) | * @apiNote * In earlier versions, the {@link Object#finalize} method was overridden * to call the {@link #end} method when a {@code Deflater} object * becomes unreachable. * The {@link #finalize} method is no longer defined. If a subclass * overrides||the {@code end} method, the overridden {@code end} method * is no longer invoked. *<p> * It is strongly recommended to explicitly call {@code end} to || * discard any unprocessed input promptly to free up resources | * when|||the compressor|is no longer in use.|
|ZipFile
* @apiNote | * In earlier versions, the {@link Object#finalize} method was overridden * to call the {@link #close} method when a {@code ZipFile} object * becomes unreachable.| | * The {@link #finalize} method is no longer defined. If a subclass * overrides||the {@code close} method, the overridden {@code close} method * is no longer invoked.| *<p> | * The recommended cleanup for|||{@code ZipFile}| is to explicitly call {@code close} * or use try-with-resources.|
657 *<p> 658 * Since the time when the resources held by this object will be released 659 * is undetermined, if this method is not invoked explicitly, it is strongly 660 * recommended that applications invoke this method as soon they have 661 * finished accessing this {@code ZipFile}. This will prevent holding up 662 * system resources for an undetermined length of time. 663 *<p>
I would suggest to drop this paragraph. @apiNote and @implNote in class spec cover that.
Mandy ||