Why is finalize wrong?

[Jaroslav Tulach]

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?
-jt



--------
[1] 
https://bugs.openjdk.java.net/browse/JDK-8051843?focusedCommentId=13531670&p