Re: [java-gnome-hackers] Widget ref and unref

[Mark H. <mh...@ti...>]

On Thu, 2002-08-29 at 11:45, VEROK Istvan wrote:=20
>=20
> Hi!=20
>=20
> Sorry to butt in on a topic I know little about (Java-GNOME itself),
but I=20
> was browsing the java-gnome-hackers mailing list archives and your
mail=20
> about widget (un)referencing caught my eye.  You currently want to use
the=20
> finalize() method for cleanup once the Java GC loses sight of the
object=20
> reference, but it's not safe.  There's absolutely no guarantee that
the=20
> finalize() method ever gets called.=20
>=20
> A better solution is the java.lang.ref package, present since Java
1.2.=20
> You could use a soft reference to track whether an object instance is=20
> unreachable, or a phantom reference if you're totally paranoid about
the=20
> others.  It's a cleaner and more timely way.=20
>=20
> Regards,=20
> VEROK Istvan=20



On Sat, 2002-08-31 at 11:40, VEROK Istvan wrote:=20
> > I do not see how a java.lang.ref would help in this situation -
please=20
> > explain more.=20
>=20
> Okay, here's what I'm thinking: as now, call gtk_widget_ref (or
whatever=20
> the native method is named) in the widget's constructor, and also
create=20
> java.lang.ref.WeakReference that points to this widget, to be enqueued
> into some commonly known java.lang.ref.ReferenceQueue.=20
> (This basically means that you say=20
> new WeakReference(refedWidget, targetQueue); )=20
>=20
> Being a WeakReference means that the object pointed to (the widget, in
> this case) is no longer strongly reachable (along the usual Java=20
> references), nor is it softly reachable (along a chain of usual and=20
> java.lang.ref.SoftReference instances), but it is reachable weakly.=20
> When this happens, the GC enqueues the reference (simply adds it to
the=20
> targetQueue specified in the above constructor call).=20
>=20
> So the point is that you could have a daemon thread (or do this=20
> periodically among normal activities) to see if the ReferenceQueue now
> contains any enqueued references.  (A targetQueue.poll() call will
tell=20
> you without blocking, or a targetQueue.remove() will block until it
can=20
> return one.)  If yes:=20
> ((GtkWidget)targetQueue.remove().get()).gtk_widget_unref();=20
>=20
> So this is a point in time when there are definitely no more usual=20
> references to the widget (the weak reference being enqueued means just
> that), and we can call its native method to unreference its native=20
> resources.=20
>=20
> One more thing: why a weak reference and not a phantom reference,
since=20
> that is even more stringent (no more weak references)?  Because with=20
> phantom references you cannot get() the referred reference back -- it=20
> always returns null, to ensure you cannot "revive" your object in this
> way.=20
>=20
> If you abstract this unref-ing activity out to a Runnable, you might
want=20
> to register it with=20
> java.lang.Runtime.addShutdownHook(new Thread(theRunnable));=20
> too, since that runs it also when the JVM is about to be shut down.=20
>=20
> Just my $0.02 -- wish I could help more with Java-GNOME, but I don't
know=20
> GTK.  Any tentative release dates for 0.8.0?=20
>=20
> Regards,=20
> Istvan=20


The problem I see with this is specifying the location of the
targetQueue. I can't think of any robust way to do this without
modifying the constructor of every widget.

Does anyone on the list have any ideas?
--=20

+----------------------------------------------+
| Mark Howard               cam.ac.uk   mh344@ |
| http://www.tildemh.com    tildemh.com    mh@ |
+----------------------------------------------+