ThreadPoolExecutor and finalization

[Stuart Marks]

On 10/30/17 10:21 AM, Martin Buchholz wrote:
>> The initiative is to identify and remediate existing uses of finalization
>> in the JDK.
> 
> I've been skeptical about this initiative as stated.  I would not have
> deprecated finalize(). We will never remove finalize() from the JDK, and I
> don't see how switching TPE from finalize to some other mechanism such as
> Cleaner has real benefits for users.  There aren't enough instances of TPE
> created for finalization to be a real user performance problem.

Interesting that you say "we will never remove finalize()" ... it is exactly the 
goal of this initiative to remove finalize() eventually. Or at least to remove 
the finalization mechanism. It's been a thorn in the side of GC implementors 
since forever. As Roger stated, the early part of this effort is to remove uses 
from within the JDK, and to warn external users to start migrating to other 
facilities. Hence, we've deprecated it and are having this discussion.

I don't know what the later parts of the transition will look like. Perhaps at 
some point we deprecate Object.finalize() for removal; perhaps at some point the 
VM stops calling Object.finalize() even though the method is declared; perhaps 
at some point we actually remove the Object.finalize() method. All of this will 
require further discussion, and it will be based on our experience working 
through these early remediation steps.

> TPE's spec currently has a finalize deprecation warning, but this is not
> helpful for users.
> (a documentation readability regression!)
> https://docs.oracle.com/javase/9/docs/api/java/util/concurrent/ThreadPoolExecutor.html#finalize--

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?

s'marks