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
does.
Andrew.
More information about the core-libs-dev
mailing list