Java support in GTK/Gnome

[Oskar Liljeblad <osk hem passagen se>]

Hi

I'm working on gnome-gcj (http://gnome-gcj.sourceforge.net) which is a set
of bindings for Gtk in Java/CNI. Currently, each Java objects contains a
pointer to the corresponding Gtk object, and the Gtk object has an
associated data containing the Java object reference. This causes problems
when Gtk objects are created from within Gtk, and not by the user from
Java. For example, the GtkDialog contains some default widgets - boxes
and buttons. These are allocated in GtkDialog and thus can't be accessed
from Java. (This can however be solved by automaticly creating a Java
object for Gtk objects without Java peers.)

But a better solution (IMHO) is described by Per Bothner in his
"A Design for Java Support in Gnome" document at
http://www.bothner.com/~per/gnome-java.html. The solution is to merge GTK's
object allocation with gcj's Java object allocation by modifying the
function gtk_type_new (GTK 1.2.x) or g_type_create_instance (GTK/Glib 1.3.x).
The GTK object is actually embedded in the Java object.

We need something like this in glib/gobject/gtype.c:

  typedef GTypeInstance *(*GTypeMemoryAllocator) (GType type);

  static GTypeMemoryAllocator mem_alloc_callback = NULL;

  void
  g_type_set_allocator(GTypeMemoryAllocator callback)
  {
      mem_alloc_callback = callback;
  }

  GTypeInstance*
  g_type_create_instance (GType type)
  {
     ...
     if (mem_alloc_callback == NULL) 
       instance = g_malloc0 (node->data->instance.instance_size);
     else
       instance = mem_alloc_callback (type);
     ...
  }

What the registered memory callback does is simply to allocate
memory for the instance. Obviously, this callback which Java registers
using  g_type_set_allocator needs to be able to figure out the name
(or some unique persistent identifier) and superclasses of a GtkType.
This information will be used to figure out what kind of Java object
that need to be allocated.

This is just code to outline the solution. Obviously it needs to be made
more solid, but the question right now is: Is this a reasonable thing to
implement? Are there any better solutions that you know of? Would a patch
implementing the above be accepted for GLib 1.3.x?

Oskar Liljeblad (osk@hem.passagen.se)