RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

Xueming Shen xueming.shen at oracle.com
Fri Sep 29 21:14:49 UTC 2017


On 9/29/17, 1:58 PM, mandy chung wrote:
>
>
> On 9/27/17 4:41 PM, Xueming Shen wrote:
>> 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
>> ||
>
>    76  * specified to call the {@code end} method to close the {@code deflater} and
>
> s/deflater/Deflater
>    80  * The recommended cleanup for compressor is to explicitly call {@code end}
>    81  * method when it is no longer in use. Existing subclasses of {@code Deflater}
>    82  * that override {@code end} and require {@code end} to be invoked when the
>    83  * instance is unreachable should explicitly override {@link Object#finalize}
>    84  * and call {@code end}.
> I suggest not to recommend "explicitly override Object.finalize" (in 
> fact, we should discourage it) and the overridden end method should be 
> called explicitly.  This was what I suggested in the previous mail:

"calling end() directly/explicitly to release the resource" is being 
recommended at
the first sentence. The second sentence here is meant to provide a 
possible alternative
if any existing subclass is implemented the way that it has the 
dependency on the
old mechanism that its own "end()" being called, for situation that the 
Cleaner is
not possible, or difficult to implement. No value at all?

-Sherman


> ||
> |  * 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.|
>
> ||Same comment applies to Inflater.
>
> 75  * specified to call the {@code end} method to close the {@code inflater} and
> |
>



More information about the core-libs-dev mailing list