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
