On 2/11/2017 5:07 AM, Stuart Marks wrote:
On 10/31/17 6:58 PM, David Holmes wrote:
I'm not sure why you say this isn't helpful. It's clearly not helpful
to *clients* of TPE; but since finalize() is protected, the warning
is clearly directed at subclasses, and it provides information about
migrating away from finalization. Should say something different?
It isn't helpful to people subclassing TPE (or any class that defines
finalize()) because the general strategies described in
Object.finalize() can't be applied by the subclass independent of the
class (TPE here) it is subclassing. Unless TPE provides an alternate
mechanism, the subclass is stuck with finalize().
I don't understand why the subclass has to rely on the mechanism
provided by its superclass (TPE here). I'm thinking of a case like the
following.
Suppose a subclass has some independent native resource that it needs to
clean up. Prior to the introduction of java.lang.ref, the only thing
available was finalization. The subclass would have to override
finalize(), do its own cleanup, and then make sure to call
super.finalize().
With Cleaner in JDK 9, the subclass can refactor its native resources
into a Cleanable, register it with a Cleaner, and then clean up its
native resources when the Cleanable's clean() method is called.
Can't this be done independently of TPE and finalization?
Of course it can. The independent part of the subclass can use whatever
mechanism it likes - it's independent. The point is that if the subclass
needs to coordinate it's additional cleanup with the shutdown done by
finalize() then it needs a means to do so.
David
s'marks
