Why is finalize wrong?

[David M. Lloyd]

On 08/04/2014 08:46 AM, Jaroslav Tulach wrote:
> Hi.
> Last week we touched topic of finalization and what is wrong with it. I proposed three
> reasons why Object.finalize is bad. Is it correct and extensive list or would you change
> it or expand it? Thanks as ...
>
>>> # 1 - Because of automatic JDK management thread?
>>> # 2 - Or because once finalize() is called, one still has reference to the
>>> "gone" object and can re-activate it?
>>> #3 - Or because the finalizer thread is shared between completely
>>> unrelated
>>> objects and misbehavior of one can cause problems for others?
>
> ...I consider #2 the worst idea:
>
>>> My personal top three starts with #2. That is logically invalid. #3 can be
>>> a problem, but so can be any other misbehaving thread in an application.
>>> #1 is completely OK, from my perspective
>
> and I think I got some support...
>
>> Weak references and reference queues were introduced to address some of
>> the short comings of finalization as well as providing other
>> capabilities within a GC'd environment.
>
> ...I just have to say that the Reference&ReferenceQueue as of JDK8 is not enough. As
> the case of activeReferenceQueue shows, the fact that each instance of
> ReferenceQueue where one uses remove() needs one dedicated thread is a big flaw.
> Fixing the flaw in an external library is not easy (see the summary from last week:
> https://bugs.openjdk.java.net/browse/JDK-8051843?focusedCommentId=13531670&p
> [1]age=com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel#comment-13531670).
>
> Moreover David Holmes finds introductions of new system level threads uneasy:
>
>> The threading aspect is somewhat tangential. Any time you choose to
>> introduce a new thread to perform a task you have to be concerned about
>> the lifetime of the task and thus the thread.
>
> But when thinking about it, we can have functionality of activeReferenceQueue in JDK
> without introducing any new thread! We can reuse the existing finalizer one!
>
> I plan to propose a patch which will look at the activeReferenceQueue problem from a
> completely new perspective and offer "lightweight finalize" solution that will have
> above discussed properties #1 and #3, but will not suffer from #2 (the biggest
> problem with Object.finalize).
>
> I just wanted to ask before I start: Is somebody aware of other problems with
> Object.finalize than #1, #2 and #3?

Yup.  Did you know that an object can be finalized while there are still 
instance methods of that object executing?  We've actually seen it 
happen.  Just take a few minutes to think about what that means!  Almost 
every remaining use case for finalize is made unsafe and/or useless by 
this fact.

If you still think that finalize is a good idea, given that it's 
basically defective *and* there is almost always a better solution, then 
I will be quite astounded I think.

-- 
- DML