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?
Peter, 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? Sherman
