ThreadPoolExecutor and finalization

[Roger Riggs]

Hi David,

On 11/1/2017 10:30 PM, David Holmes wrote:
> 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.
Given the use cases and the context in which an unreferenced resource 
needs to be
released, I don't think a fully general purpose mechanism is appropriate.
If there are dependencies in the cleanup those can be references between 
the dependent
objects.  Those dependencies will ensure that cleanup of each occurs 
when it is unreferenced.
It is more robust if each resource handles its own cleanup.  Peter 
already suggested
that if coordination was required, the mechanism should be explicitly 
provided by the
owning/coordinating object.

Roger


>
> David
>
>> s'marks