Swing, AWT, et al.

[Troy Wu <troy at cinema35 dot yi dot org>]

Is this the right place to begin a discussion on the implementation of
Swing in the GCJ project, along with comments on GCJ's direction?

			*	*	*

I'm suggesting a path for the Swing implementation. To this end, I'm
willing to work on my own propsal outlined below, but didn't want to
clash with the current AWT effort...Please read on.

A short while back, I spent some time porting Swing to C++.  This
wasn't too hard, since Swing bootstraps its own infrastructure.  I
used Xlib to create windows, and I could just call the Xlib drawing
routines to draw inside those windows.  I bootstrapped the event
handling; i.e., I listened for raw X events (Expose, ConfigureNotify,
MotionNotify, etc), and if needed be, created the appropriate
Swing/AWT event and passed it on to the receiving components.

	Underneath, it's striking how much the AWT looks like X,
	particularly in things like the Graphics interface (just an X
	GraphicsContext ripoff).

The point is, (which I'm sure everyone is wondering about), is that I
didn't implement most of the AWT.  I just implemented things that were
necessary (Color, Font, Rectangle, etc.) while keeping the code that
required Xlib calls (Graphics, FontMetrics, Frame, etc.) mostly
confined to a few places.  Since Swing draws its components itself, it
doesn't need many native peers (except to be able to create abstracts,
like Frame-, Window- & Graphics-derived objects).

I'd like to think that the AWT is out-moded (I'm really hoping not to
receive flames on this comment).  People writing interfaces are really
interesting in Swing, because of its better looks (IMHO), higher
portability (there are no behavior differences in components on
different host OSes, PLaF capabilities (although I never use them) and
excellent programming design pattern (MVC--truly wonderful).

The C++ port I did showed performance gains of 5x to 10x faster when
drawing components inside a window whose contents were being visibly
resized while I pulled on a window corner (courtesy KDE).  The GCJ
Swing could be just as fast--duh.  =)  I've had several people tell me
that if the GCJ project had Swing, they would entirely abandon C++ in
favor of the garbage collection, consistent reference & pointer (or
lack thereof) semantics, and general language ooh-aahs that Java
offers (like the nicer linking/loading conventions via the ClassLoader
paradigm and metaclasses).

			*	*	*

A little personal philosophy: the open source movement has a lot of
horizontal growth--i.e., there are a lot of new projects, but very
little vertical growth--i.e., there are few projects as a whole which
are steadily built upon to create a closed system.

Vertical growth is predicated on having stable APIs.  POSIX is a
reasonably stable API; that's why GNU can be so successful.  It builds
utilities for Unix (or not-so) systems, which are in turn POSIX based
at the core.  Working with Java, and particularly Swing, I believe
that it, too, can be a stable--but *much* more user-oriented--API.  
Then, if developers would coalesce around the JFC, we could have a lot
of application growth which would be inherently integrated (e.g., the
Swing MVC pattern can nicely replace toolkits like QT & GTK).

A serious core of Swing-based apps written with GCJ as the
compiler--like a mail client, browser, event planner, multimedia tools
(CD & MP3 players), and office productivity apps (along with their
winblows counterpart running in VMware) would really make any Unix(TM)
system a nice end-user (i.e., non-developer) system.

Then, getting system admin tools written in Swing (have any of you
seen linuxconf?--fugly =) would be a really nice feature for those of
us, e.g., who hate manually updating firewall rules by editing
rc.firewall shell-scripts.  Also, a Swing-based syntax-highlighted
Java source editor (which can emulate both emacs and vi--of course)
which has an interface to the compiler (this would be sweet, and I'm
not talking about the Xemacs JDE package) I could use to develop *even
more* GCJ apps would round out my needs as a developer *and* end-user.

	Okay--enough fascination over vaporware.

All this, I think, is the real potential for GCJ.

	--troy