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

Xueming Shen xueming.shen at oracle.com
Mon Oct 30 23:32:49 UTC 2017

On 10/30/2017 01:34 PM, Peter Levart wrote:
> The Inflater and Deflater now look fine (except you don't have to check for cleanable != null any more in Inflater.end()).
> But what shall we do with ZipFile?


The fundamental issue here is the gap between the resource allocation
and the cleaner registration, as far as these two are not an atomic
operation, it's hard to handle it in the normal use scenario. You might be
able to workaround it by registering the cleaner first and then send the
resource reference into the cleaner, as we are going to do for the deflater/
inflater. But it appears to be a more general issue and in some circumstance
even the "register-first-allocate-assign-in-later" approach might fail.
For example, you have N resource to allocate, something goes wrong
between the first and the Nth resource allocation completed/or simply say
before you can reach the "register()". The question then I would like to ask
again is if this is really something we want to support/cover with the Cleaner
mechanism. It doesn't appear to be supported under the finalize() mechanism.
For example, if someone throws out an exception inside the constructor, in
normal use scenario, regardless you catch or not catch that exception
(outside the constructor), the finalize() method is probably not going to
be called by the finalizer for this partially/incompletely constructed object,
if you don't purposely do something special to publish the object. Sure
arguably It appears to be out of the scope of Cleaner API and the only thing
needs to be addressed here is whether or not register(..) operation fails and
throws an Error. But it might be helpful to see if there is any different opinion
before going further?


More information about the core-libs-dev mailing list