ThreadPoolExecutor and finalization
stuart.marks at oracle.com
Tue Oct 31 20:37:42 UTC 2017
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!)
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?
More information about the core-libs-dev