RFR 9: 8165641 : Deprecate Object.finalize

Andrew Haley aph at redhat.com
Wed Mar 15 10:43:20 UTC 2017

On 15/03/17 10:21, Timo Kinnunen wrote:

> If we are to come up with a good alternative to finalization, having
> to compare disparate things seems unavoidable. Comparing threads and
> Threads, suppose there’s a subclass of Thread which holds a native
> resource that’s not reachable from any other Thread and it has a
> finalize method. Let’s say this Thread’s resource is a handle to its
> own native thread and the finalize method calls CloseHandle on the
> handle and ExitThread to signal an A-OK exit code. The thread will
> not be removed from the system while the handle remains open. Could
> this Thread’s thread invoke its own finalize method once it’s done
> or would it have to wait for the Finalizer to call it instead, and
> if so, why?

Isn't this a classic example of Finalizer abuse?  A Thread's run()
method could be enclosed in a try ... finally region which closes the
handle.  If, for some odd reason, that doesn't happen, then the
Thread's finalizer is a last resort, but it shouldn't normally be
needed.  Whether it's safe for a native thread to invoke its Thread's
finalize method depends on the OS-specific details of what CloseHandle


More information about the core-libs-dev mailing list