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

[Peter Levart]

On 10/15/2015 03:21 PM, Roger Riggs wrote:
> Peter, Chris,
>
> Plausible but getting complicated as Chris observed.
>
> We can be on the lookout for specific cases in the JDK like that. I 
> expect most
> can be resolved by specific cooperation between the super/subclasses.

How? Such "cooperation" can not use the tracked object's instance 
methods as the instance is gone when cleanup happens, so no overriding 
is possible. Can you rewrite this example:

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 ...});
     }
}


...using just current simple Cleaner API?

I think that if we design an API to replace finalize(), then it should 
support use cases that are possible with finalize(). Not just use cases 
in the JDK itself, but also elsewhere on the planet.

> The cleanup of each class should *only* be doing cleanup for their own 
> class.
> Because it is invoked after finalization, there can be *no* access to 
> the instance
> being cleaned.  Any shared state will be duplicated between the two 
> cleanable behaviors.
> If the subclass shares state with the superclass (protected fields or 
> references)
> then the cleanup needs to be co-designed.

Even if state needed for clean-up is duplicated (it can just be doubly 
referenced, for example: superclass establishes state and exposes it to 
subclass that just references it), registering separate Cleanup 
instances per super/subclass means that you can not control the order of 
them fire-ing. If for example, the subclass cleanup logic needs the 
superclass still be fully functional, it can do that now by:

@Override protected void finalize() {
         ... subclass cleanup ... // flushing something - needs 
superclass functionality
         super.finalize();
}

With separate Cleanable(s) for super/subclass, the order is not guaranteed.

>
> Canceling cleanup is easier, because the object has not been finalized.
> If such a function is needed, it should be part of the API of the 
> superclass
> and part of the contract.

Ideally such methods would be in superclass only and be final and just 
delegate to Cleanable.clear() or Cleanable.clean(). The Cleanable should 
be the only place where the cleanup logic is encapsulated.

>
> Also, I've seen a few calls to super.finalize() where there were no 
> finalizers
> in any of the superclasses.  It would be considered good design to 
> always include it.
> I don't know if the optimization for empty finalize methods includes the
> case where it only calls super.finalize().

Ah, I forgot that empty finalize() is optimized away (the Object is not 
even registered for finalization).

Regards, Peter

>
> Roger
>
> On 10/15/15 7:43 AM, Chris Hegarty wrote:
>> 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
>