JDK-8190324 : ThreadPoolExecutor should not specify a dependency on finalization
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Affected Version: 10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-10-29
  • Updated: 2018-03-28
  • Resolved: 2018-02-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11
11 b01Fixed
Related Reports
CSR :  
Relates :  
Sub Tasks
JDK-8196867 :  
ThreadPoolExecutor specifies the use of finalization to cleanup unreferenced Exectors.  With the deprecation of Object.finalize another mechanism should be implemented.

A first step is to remove the dependency on Object.finalize from the specification of ThreadPoolExecutor.finalize.
An interium step can be to move the finalize to an implementation specific class.
Usually, it has been the practice to deprecate ( the finalize method) before removal to provide advance notice to developers about the change. If there are reasons to skip that step for this change, please include them. The alternative is to back out the inadvertent change and deprecate as the first step toward removal.

We've discussed Executors.newSingleThreadExecutor and the similar case of j.u.Timer.threadReaper. We have not come up with any better alternative than keeping both but adding reachabilityFence calls.

The change to ThreadPoolExecutor is fine. Should anything be done to simplify Executors.newSingleThreadExecutor and FinalizableDelegatedSExecutorService that also has a finalize method?

Roger, could you please review the already committed changes to ThreadPoolExecutor.java and the CSR ?

yes, a CSR would and review would clear this up.

Martin: there needs to be a retroactive CSR request for the specification change.

Roger, sorry but changes to ThreadPoolExecutor to remove finalize were inadvertently committed in: http://hg.openjdk.java.net/jdk/jdk/rev/946e34c2dec9 Please take a look. I'm not sure what the best process is, but at least this bug needs to get resolved somehow.

Comments suggested removing the finalize method and tweaking the documentation: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050187.html