[java-gnome-hackers] handle->GObject mapping needed

[Tom B. <Tom...@Su...>]

In adding support for container events, I found we need to be able to
map a GTK widget handle to its associated Java-GNOME Widget object,
something like:

    /**
     * Return the associated Java-GNOME object for a given handle.
     */
    public static GObject getGObject(int handle) { ... }

Briefly scanning through the code, it looks like this mapping is needed
elsewhere.  For example, there were many cases where a new Widget was
created in an event callback, so that there were then two Widget objects
which shared the same GTK handle.  This duplication was okay back when
all widget state was stored within GTK, but now that we have Java-based
event listener lists and the like, it's important that the 1-to-1
mapping between widgets and Widgets be preserved.

There are two ways to implement a "back-pointer" from a native handle to
its associated GObject:

1.  Store an JNI object reference in the native gobject.  GTK has the
ability to add named properties using g_object_set, so this is
workable.  The AWT uses this method.

2.  Maintain a hashtable to map handles to GObjects, and use a factory
method instead of constructors to look up or create GObjects from
handles.

The advantage of (1) is that GTK manages the memory, so there's no worry
of object leaks.  I'd implement it by making GObject.handle private and
add a protected setter which would call a native method to set the named
property.  The disadvantage is that this mapping isn't as obvious as
(2).

The advantage of (2) is that it easy to understand and therefore
maintain.  The main problem is that all GObject constructors get
hidden/deprecated, and a factory method used instead (like
Widget.makeWidget).  This factory method would check the hashtable
before creating new GObjects with a given handle.  Josh Bloch recommends
this technique in Effective Java, but not everyone is used to it.

My vote is for (1), but I'm comfortable implementing either solution.

Tom