Java-Gnome is another set of Java wrappers for GTK/Gnome. The Java-Gnome project was launched in 1999, but has been inactive until recently (November 2000) when work on it resumed.

I have upon request (and interest) compiled a list of differencies between the two projects. The list, which can be found below, is far from complete. It should however illustrate the most important differencies.

In the list below, JG means Java-Gnome and GG Gnome-GCJ. E-mail me at osk@hem.passagen.se if you have any comments or would like to complete the list.

General differences

• JG uses JNI - supports almost all java environments. (GG only gcj.)
• GG uses automake/autoconf/libtool, JG only autoconf.
• GG's generator programs are more extensive and powerful (IMHO).
• JG's generator programs seem to be better documented.
• The input for the generator programs are not the same in JG and GG. JG uses a format similar to the Gtk/Gdk .defs files, while GG uses a custom format.
• JG appears to have more active authors than GG.
• JG uses CVS on SourceForge, GG doesn't.
• JG's latest version released in november, GG's latest in september.
• GG is probably harder to build because there is no stable libgcj/gcj release.

API differencies

• GG uses gnu.{gdk,gtk,gnome} as package, JG just {gdk,gtk,gnome}.
• GG strictly follows Sun's naming standards for classes and methods (not packages). JG does most of the time, but not always (signal_connect vs signalConnect).
• JG uses class names like GtkButton, GtkWindow. GG uses Button, Window. This causes problems with GdkPixmap vs GtkPixmap (vs GnomePixmap), which is solved by using names like those in JG (GdkPixmap etc).
• JG uses separate classes for all enum/flag-set in Gtk I.e. GtkAttachOptions, GdkCursorType, GdkEventType, GdkEventMask.
• JG uses objects to represent contants.
  This leads to a massive number of classes, and probably slower overall execution because of more objects in memory. Some might reason that this makes programming painful, but it adds safety.
• JG uses long constant names: GdkEventMask.GDK_EXPOSURE_MASK.
  Compare to GG's Gdk.EXPOSURE_MASK (in future Event.EXPOSURE_MASK).
• JG supports some API simplification by method shadowing. GG doesn't yet.
• JG allows generic callbacks (like ActionListener in AWT).
  I.e.

    b.signalConnect("clicked", new Callback() {
      public void action(Object source, Object data) { .. }
    }
  

• JG also allows direct connection to methods, i.e. b.signal_connect("clicked", "buttonClickedMethod", this);
• GG generates specific listener classes for all known signals. This allows additional arguments to the signals (such as GdkButtonEvent to the "button_event" signal) to be passed to Java. JG discards them. GG will change entirely to support all of these with GLIB 2.0.
• Nearly all classes and methods are javadoc-documented in GG. (Although it only refers to the C API - no factual documentation is provided.)
• GG's GTK and GDK API seems to be more complete?
• JG's Gnome API seems to be more complete?
• GG doesn't strictly name Java methods after C functions. (gtk_button_pressed becomes firePressed, not pressed etc).
• JG doesn't seem to completely support association of Java objects with native objects (the peers concept). Without this, methods that return Java objects are impossible. A great deal of time has been spent on GG to make the peer system as smooth and safe as possible.