Lightweight finalization for the JDK without any drawbacks was: Why is finalize wrong?

[Jaroslav Tulach]

OK,
time to show the code. I've added an alternative patch to JDK-8051843:
https://bugs.openjdk.java.net/secure/attachment/21640/ActiveQueueFinalizer.diff
I suggest to start reading it from bottom - e.g. the test, the documentation 
and then the implementation. 

Now there is time for some discussion: First of all I should mention that the 
patch is sufficient to solve all the problems NetBeans and people reusing 
NetBeans libraries in dynamic classloader systems (e.g. containers) have. This 
is a pro.

Next thing to check is whether the change can cause some harm. Here are the 
areas of concern we have identified so far:

> > > # 1 - Because of automatic JDK management thread?

The patch introduces no new thread. It reuses already existing one. No 
allocation of new system resources. Status quo is kept.

On the other hand, this is a pro over own ReferenceQueue.remove calls. One 
saves a thread per instance of such queue.

> > > # 2 - Or because once finalize() is called, one still has reference to
> > > the
> > > "gone" object and can re-activate it?

This problem does not exist with activeQueue(). When the run() method on a 
Reference is called, this.get() already returns null. I believe this addresses 
also David M. LLoyd's concern:

> 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

Sure, but that cannot happen with activeQueue() as the referent is really gone 
before appropriate Reference.run() is executed.

Certainly a pro over Object.finalize. Status quo with respect to ReferenceQueue 
as that behaves the same.

> > > #3 - Or because the finalizer thread is shared between completely
> > > unrelated
> > > objects and misbehavior of one can cause problems for others?

No regression in this aspect either. finalizer thread already has this problem, 
and we are not making it worse. Status quo is kept. Well written application 
actually benefit from this behavior, as they save system threads (compared to 
own ReferenceQueue.remove implementations).

> If you still think that finalize is a good idea, given that it's
> basically defective *and* there is almost always a better solution, 

I believe activeQueue() in core libraries is good idea. Because it fills the 
gap between (dangerous, unusable) Object.finalize and (ineffective) attempts to 
code the same logic in libraries (via own Thread+ReferenceQueue.remove)

I see at least one pro and no cons. Are there other points of view?
-jt