ThreadPoolExecutor and finalization
david.holmes at oracle.com
Thu Nov 2 02:30:10 UTC 2017
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
> 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
> 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.
More information about the core-libs-dev