Re: [Java-gnome-developer] Re: your mail

[Paul G. <pau...@bi...>]

Oskar Liljeblad wrote:
> 
> [I am forwarding this email to the list. I hope you didn't mind. :)]

Not at all!  I personally am very glad to see some discussion between
the
two projects.

> On Monday, November 13, 2000 at 12:41, Morgan, Jeffrey wrote:
> ...
> > The purpose of my email is to establish communications and to see where
> > our two projects might collaborate.  Although we are trying to accomplish
> > different goals, some commonality might be beneficial to the Java and
> > GNOME community.  At a minimum, it might be nice if we could offer the
> > same APIs.
> ...
> I have provided a list of differencies between the two projects on the
> homepage of Gnome-GCJ. It is at
> http://gnome-gcj.sourceforge.net/java-gnome.html. Consider it a preliminary
> source of details to be discussed. The list may contain some deficiencies,
> so feel free to comment on it. (I think this list would be a good place, if
> you don't mind.)

Osk, i read your list, and i'd like to make a few comments from the
perspective of someone who's looking for the ideal balance between
development
& runtime environments for programming on Linux.  (Aren't we all?  :-)

> ...
> JG uses JNI - supports almost all java environments. (GG only gcj.) 

I've mentioned on this list before why i think it would be great if GG &
JG
could offer the same APIs: I can develop with a rapid development system
or
non-gcc compiler (i prefer Jikes because it's so blazingly fast), but
then
deliver with gcj and gain the speed increase afforded by compiled code.

> 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. 

Most of these are of little importance to application developers, as
long as the software works, is stable, and is available from a reliable
site.

> JG's latest version released in november, GG's latest in september. 

The less frequently, the better.  Free software is too hard to keep up
with
already.  :-)

> GG is probably harder to build because there is no stable libgcj/gcj
> release. 

I think you can take that 'probably' out.  I would say "GG is nearly
impossible to get working if you can't/don't want to build your own
gcc/gcj/libgcj."  I have tried a number of versions from my vendor (i
use Red
Hat 7.0), and i just can't get the thing to work.  Recompiling gcc, etc.
is
not an option, as i don't have the disk space, or the time to work out
what i
can free up on my hard drive.

> API differencies

FWIW, here are my comments on the API differences...

> 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.

I prefer GG's naming on all counts above.

> This causes problems with GdkPixmap vs GtkPixmap (vs
> GnomePixmap), which is solved by using names like those in JG (GdkPixmap
> etc). 

I think this approach by GG is OK, as long as the one that is most
likely to be frequently used is left unadorned (e.g. have GdkPixmap,
GtkPixmap, and gnu.gnome.Pixmap, or some other similar scheme).  One
other option is to call them all Pixmap, and make people select which
one they are referring to manually.

> 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.

I prefer the approach that provides better type safety, even if it adds
memory
or CPU overheads.

> JG uses long constant names: GdkEventMask.GDK_EXPOSURE_MASK.
> Compare to GG's Gdk.EXPOSURE_MASK (in future Event.EXPOSURE_MASK). 

Shorter names are preferable, as long as they are non-ambiguous and
there is no information loss in the name.  e.g. There is no need to have
GDK_ in a constant since there is a gdk in the package name.  However,
taking out the 'EventMask' in the current GG naming style does mean that
some meaning is lost.  The future GG one where the full name would be
something like gnu.gdk.Event.EXPOSURE_MASK sounds good to me.

> 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. 

Those are all nice features.

> Nearly all classes and methods are javadoc-documented in GG. (Although it
> only refers to the C API - no factual documentation is provided.) 

Not much point in providing the documentation if it only refers to the C
API -
just running javadoc on a class file would be good enough if that is the
case...

> GG's GTK and GDK API seems to be more complete? 
> JG's Gnome API seems to be more complete? 

While the union of these two sets would be really nice to have :-), with
respect to getting consistent application look & feel, Gnome APIs are a
little more important.

> GG doesn't strictly name Java methods after C functions. (gtk_button_pressed
> becomes firePressed, not pressed etc). 

The GG style, which is more Java-like (i.e. all methods are verbs), is
preferable to me.

> 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. 

A complete peer system would be most helpful if we need to provide
advanced
functionality or work around specific problems/limitations in the API.

Paul
---------
"He must become greater; i must become less." - John 3:30
http://www.bigfoot.com/~paulgear