ThreadPoolExecutor and finalization

[David Holmes]

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