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.
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.
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.
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().
Roger
On 10/15/15 7:43 AM, Chris Hegarty wrote:
Peter,
On 15 Oct 2015, at 09:12, Peter Levart <peter.lev...@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
