There are 2 advantages to Disposer:
- priority of disposal process
- the DisposerTarget mechanism
One problem with the finalize method is that they intentionally leave
some of the aspects of the process undocumented. One thing that is not
documented is the priority of the finalizer thread - which is actually
fairly low. Thus, finalization is not very prompt in the grand scheme
of things and the Java code cannot control that. We asked for
finalization to be increased in priority, but due to compatibility it
was decided to leave it with a low priority.
With Disposer, we can control the priority of the thread managing the queue.
The other problem with finalize() that others have mentioned is that the
object with the finalize() method needs to remain alive. Often, that is
a complicated object that has ancillary data that you don't want to keep
alive for another round of GC. Disposer provides the DisposerTarget
mechanism to deal with a similar problem and so you can use Disposer
without keeping the original object around during the disposal process.
Of course, that latter issue can be managed with finalize() methods as
well. It is common practice to put the finalize() method on the class
that manages the native resources, but one could just as easily have
created an instance of a tiny subclass that is stored as a reference
from the main object and put the finalize() method on the subclass so
the parent can go away and leave that tiny child around in the finalizer
queue. The main thing is that programmers don't often want to design
this way, and so they don't - but DisposerTarget makes this paradigm
more straightforward so it is easier and more likely that the right
thing will be done...
...jim
[EMAIL PROTECTED] wrote:
Why would it be cheaper to use WeakReferences to track disposable objects than
it would be to use finalizers? Don't both essentially delay garbage-collection
and don't both only get flagged as disposable at the GC's discretion? At least
with finalizers you're guaranteed that objects will get GC before
OutOfMemoryError is thrown, with the WeakReference approach don't you run the
risk that you'll run out of native resources and throw OutOfMemoryError when
you don't really have to?
Thanks,
Gili
But shortly, it uses ReferenceQueue and
WeakReferences.
It puts a weak reference to the tracked object
into a reference queue and when the object is gone
the reference is retrieved from the queue,
it disposes the resources associated with the
object (those resources are kept in a special
DisposerRecord object).
[Message sent by forum member 'cowwoc' (cowwoc)]
http://forums.java.net/jive/thread.jspa?messageID=239733
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
