fitzsim recently got jhbuild working with gcj and java-gnome. I tried it out today, and created jhbuild support for rhug packages. Then I wrote my first gnome app in javascript:

#!/home/green/install/jhbuild-inst/bin/js
 
/* The java-gnome libraries need to be linked differently.
   Let's force lib-org-gnu-glib into memory first until this is fixed. */
java.lang.Class.forName ("org.gnu.glib.GObject");
 
/* Initialize the UI.  */
args = java.lang.reflect.Array.newInstance (java.lang.String, 0);
Packages.org.gnu.gnome.Program.initGnomeUI("First", "0.1", args);
 
/* Create our application, and enter the main loop.  */
app = new Packages.org.gnu.gnome.App("First", "First App");
app.show ();
Packages.org.gnu.gtk.Gtk.main();

Lots of neat things are happening here. I'm running the mozilla rhino JavaScript implementation, which supports LiveConnect for easy access to the gcj runtime. When my program refers to java-gnome classes, the system class loader knows to dynamically load java-gnome code in shared libraries with magic names (lib-org-gnu-gnome.so, etc).

This brings me to my first of several annoyances with java-gnome. They currently use .so names like libgnomejar2.7.so. This works fine if you're building executables and don't mind linking directly to those libraries. However, if you want to support dynamic discovery and loading of these classes you'll want to use the special naming conventions described in the gcj manual. I worked around this problem with a few symlinks.

There were a few more annoyances with java-gnome, but they are all minor and easily fixable. I'll follow up with those guys soon.

All this software was built with my tweaked jhbuild. I sent my changes to fitzsim, who is also trying to push his changes upstream.