[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GNU Classpath GUI projects (AWT/Swing)

From: Mark Wielaard
Subject: GNU Classpath GUI projects (AWT/Swing)
Date: Mon, 02 Aug 2004 00:55:53 +0200

Hi all,

After all the GUI (AWT/Swing) work going on in CVS it is probably a good
idea to give a little overview of the process.

Thomas Fitzsimmons gave a very inspiring talk on "GCJ and the Desktop"
at the Desktop Developers' Conference describing our AWT, Swing and
java-gnome support.
Slides and screenshots at
A report by Christopher Blizzard can be found at

MERGING. We decided that it was very important to share these advances
to our AWT and Swing code faster with the other projects so this last
week we made sure that the libgcj gui branch and GNU Classpath CVS have
been (almost) completely merged. Kaffe has merged the AWT and Swing code
again from GNU Classpath into Kaffe CVS and jamvm (1.1.4) and kissme
(CVS) can be made to work out of the box with the new GNU Classpath CVS
gui code.

Starting immediately we are going to start merging between the libgcj
gui branch and GNU Classpath CVS directly and more frequently. Any
future work in [gnu]/java[x]/(awt/swing)/ and native/jni/gtk-peer
directories should go directly to the libgcj gui branch or GNU Classpath
CVS, *not* gcc trunk, since this will ease integration and reduce the
risk of a merge clobbering changes.

We used to do merges like:
  kaffe/[other-projects] <=> classpath <=> libgcj <=> gui-branch
Since most changes for java/awt, javax/swing and native/jni/gtk-peers
take place on the gui branch we will now do it like:
   kaffe/[other-projects] <=> classpath <=> gui-branch <=> libgcj
at least for those (sub)dirs.

(Note that doesn't mean you cannot develop gui stuff directly on GNU
Classpath CVS, but if you do either check it also in on the gui-branch,
or ask someone to do that for you.)

I used to be a bit skeptical about splitting off the gui work on a
separate branch. But these days more and more people seem to have no
problem just working with the branch directly. Thomas his jhbuild setup
even makes it fun and easy to do:
And I noticed that being able to just use gdb with native gcj/C/JNI code
is invaluable for debugging at least the gtk-peers.

Tom Tromey setup a comparison script to show the things not completely
merged yet between GNU Classpath and libgcj. For the non-gui parts
(libgcj head) see:
For the GUI parts (against libgcj gui-branch) see:

Jim Pick has offered us some shared resources for the GNU Classpath, gcj
and kaffe projects so we will setup a similar comparison script against
kaffe soon. (And we will then also be able to setup a environment to make it easier to do testing,
autobuilding, scripting and generating dynamic webpages.)

Of course we hope to get both gcj and kaffe working out of the box with
GNU Classpath (CVS). This is a slow process though. Hopefully for gcj
the BC-ABI work will make this easier. And Guilhem has recently switched
kaffe to use the GNU Classpath VMObject and VMThread platform interfaces
to be able to share more low level code.

EXAMPLES. To make it easier to show off all the nice new GUI work we now
have a new examples directory.  The idea is that we will distribute a
small collection of example code to show what can be done with the GNU
Classpath library. The first examples included are the old TestAWT and
Test code merged into a AWTDemo and the activityboard and testswing code
merged into a SwingDemo.

This is how it currently looks (actually it looks a bit better now
against GNU Classpath CVS from today, the screenshots are already old!):

When you do a make && make install a precompiled and all
the source code will be installed in ${prefix}/share/classpath/examples
to play with. See the examples/README for more information.

This is not just for GUI code though. It should be easy to add new
examples (IODemo, NetDemo, BeanDemo, CollectionsDemo, RegexDemo,
RMIDemo, NIODemo, TextDemo, SQLDemo, MathDemo, GeomDemo, ...) by just
adding a new directory under gnu/classpath/examples/ in the examples dir
and to add a (and possibily some helper classes). Also when
gcj 3.5 is out we want to include examples of how to create native
binaries directly.

BUGS. Red Hat had an internal bug database with AWT and Swing related
issues for libgcj. These have all been exported to the public bugzilla
on (both old and resolved bugs and new still open bugs). I
made sure that all AWT and SWING related issues in the savannah tracker
are now also mirrored there. The bugzilla maintainer setup a
special AWT and SWING component for us to keep track of both bugs and
new features people want to work on. Please coordinate and list missing
issues at:
For everything else please keep using the savannah bug tracker:
(Bugzilla support for Savannah will hopefully come in the future.)

NOT MERGED YET. The main gui things not merged yet between libgcj and
GNU Classpath are the build infrastructure to get the Cairo Graphics2D
backend working (all code is already in the tree). And libgcj has a xlib
AWT peers backend which has not yet been merged into GNU Classpath (it
seemed wiser to concentrate on the GTK+ AWT peers and get them 100%
perfect first). As always, volunteers to help with this are welcome!

Happy hacking!


Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]