RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

[Chris Hegarty]

Peter,

On 15 Oct 2015, at 09:12, Peter Levart <peter.levart at gmail.com> wrote:

> On 10/14/2015 07:43 PM, Roger Riggs wrote:
>> Hi Alan, Mandy,
>> 
>> I looked at a few of the many uses of finalize and the likely changes.
>> The zip Inflater and Deflater are relatively simple cases.
>> Some finalizers are not used and can be removed.
>> The sun.net.www.MeteredStream example subclasses PhantomCleanable to add the state and cleanup
>> behavior.
>> 
>> http://cr.openjdk.java.net/~rriggs/webrev-cleaning-finalizers/
>> 
>> Some of the harder cases will take more time to disentangle the cleanup code.
>> For example, ZipFile, and FileIn/OutputStream (Peter has prototyped this).
>> 
>> Roger
> 
> Hi Roger,
> 
> It's good to see some actual uses of the API and how it is supposed to be used in migration from finalize() methods. I think empty protected finalize() method is almost always safe to remove. If the class is not subclassed, it serves no purpose (unless some other same-package class or itself is calling it, which can be checked and those calls removed). If subclass overrides finalize() and calls super.finalize(), its ok (it will call Object.finalize then when empty finalize() is removed). The same holds if a subclass calls finalize() as a virtual method regardless of whether it also overrides it or not.
> 
> One thing to watch for is in case a subclass overrides finalize() like this:
> 
> class Subclass extends Superclass {
> ...
> @Override protected finalize() {
>    .... pre-actions ...
>    super.finalize();
>    ... post-actions...
> }
> 
> ... where the order of cleanup actions has to be orchestrated between super and subclass. Having a PhantomCleanable replace the finalize() in a superclass has a similar effect as the following re-ordering in subclass:
> 
> @Override protected finalize() {
>    .... pre-actions ...
>    ... post-actions...
>    super.finalize();
> }
> 
> ...since finalization is performed before PhantomReference is enqueued. This re-ordering is luckily often safe as post-actions usually can't use superclass resources any more and usually don't depend on the state of superclass. In addition, when superclass actions do happen, they can't invoke any instance methods if they are refactored to use Cleaner.
> 
> This brings up an interesting question. finalize() method allows subclasses to override it and augment cleanup logic to include any state changes or resources used by subclass.

Or for a subclass to effectively cancel any clean up, by
providing an empty finalize() method. Which I think is
also supported by your proposal, or at least a side-effect
of having the Cleanup as a protected field ( you can call
clear on it, right? ).

Having the Cleanup as a protected field looks a little odd,
but no more so than the public/protected finalize method.

This is now getting even more complicated. There are
potentially multiple object references being tracked as 
part of the cleanup of a single “significant” object ?

-Chris.

> How about Cleanup API? Subclass can register it's own Cleanable for own resources, but order of execution of superclass and subclass Cleanable(s) is arbitrary then. Cleanables will often be established in constructors and super/subclass constructors have a defined order of execution. So what about the following:
> 
> public class Cleaner {
> 
> public Cleanup phantomCleanup(Object referent);
> 
> public interface Cleanable {
>    void clean();
>    void clear();
> }
> 
> public interface Cleanup extends Cleanable {
>    Cleanable append(Runnable action);
>    Cleanable prepend(Runnable action);
> }
> 
> public static abstract class PhantomCleanable extends PhantomReference implements Cleanable { ... }
> 
> private static final class PhantomCleanup extends PhantomCleanable implements Cleanup { ... }
> 
> ...use...
> 
> class SuperClass {
>    protected final Cleanup cleanup = XXX.getCleaner().phantomCleanup(this);
> 
>    SuperClass() {
>        cleanup.append(() -> {... super class cleanup ...});
>    }
> }
> 
> class SubClass extends SuperClass {
>    SubClass() {
>        super();
>        cleanup.prepend(() -> {... pre-actions ...})
>                    .append(() -> {... post-actions ...});
>    }
> }
> 
> 
> Regards, Peter
> 
>> 
>> 
>> 
>> On 10/14/2015 10:23 AM, Alan Bateman wrote:
>>> 
>>> On 14/10/2015 15:03, Roger Riggs wrote:
>>>> Hi Alan,
>>>> 
>>>> So any user of the Cleaner can take advantage of the mechanism, for example in a different package or module.
>>>> For example, Netbeans.
>>> Cleaner + Cleanable need to be public of course so maybe we should wait for the examples that extend WeakCleanableRef or cast the Cleanable to a WeakCleanableRef before seeing if this is the right thing or not.
>>> 
>>> -Alan
>> 
>