ThreadPoolExecutor and finalization
stuart.marks at oracle.com
Wed Nov 1 19:07:17 UTC 2017
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?
More information about the core-libs-dev