RFR 9: 8165641 : Deprecate Object.finalize

[Roger Riggs]

Hi,

yes, the thread should use try...finally to cleanup its resources 
explicitly.

The method to cleanup and release resources should *not* be called finalize
and should be idempotent.  Finalization is needed as a last resort it 
should call
the cleanup method (and nothing else).  Not all resources are lexically 
scoped
but encapsulating the resource in a class, naming the method close and
implementing AutoCloseable are good conventions.

As you probably know, calling the finalize method *does not* trigger the 
finalization process
and so finalize could be called again.

$02, Roger


On 3/15/17 6:43 AM, Andrew Haley wrote:
> 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.