Some observations on developing with gcj

[Mark Wielaard]

Hi,

The last few weeks I have been working on a little project to learn
more about the BitTorrent protocol and how usable gcj is for creating
end user programs. See The Hunting of the Snark Project at
<http://www.klomp.org/snark/>

I thought it would be nice to mention what went well and what can
still use some more work. The project isn't finished yet, the current
version is 0.5. So some of the remarks are more requests for feedback
how people would handle certain things. All in all I was pleasantly
surprised how well it all worked and everything I used is already
included in Debian (unstable).

Sharing/Publishing something with the BitTorrent protocol works by
connecting to lots of other machines that exchange pieces of the file
with each other. That means that each client has lots of connections
(20-40) open. The current version was made using separate threads for
each incoming and outgoing connection. I had thought that would not
scale very well but it seems that creating threads with gcj is really
light weight. But using multiple threads does make designing the
program a bit more tricky. Earlier versions had some really nasty
deadlocks since I hadn't designed my locking strategy very
cleanly. Using a non-blocking select like mechanism would have
prevented most of these mistakes. Hopefully we can finish the work
that Michael Koch has been doing on java.nio for 3.4.

BTW there is already a free library providing nonblocking I/O - NBIO -
http://www.cs.berkeley.edu/~mdw/proj/java-nbio/ which is also packaged
for Debian, but I haven't tried it yet. We do have a bug report for it
though: http://gcc.gnu.org/PR9077

Integrity checking in BitTorrent is done by calculating SHA-1 digests of
exchanged pieces. GNU Crypto has a much faster SHA-1 digest
implementation so installing it and adding the provider to
libgcj.security as 'security.provider.1=gnu.crypto.jce.GnuCrypto' really
speeds up applications that use SHA much.
GNU Crypto isn't yet included in Debian but Morgon Kanter is working on
a package. We should really recommend that people install GNU Crypto
when using gcj and maybe we should replace our current SHA
implementation with the one from GNU Crypto

When closing the program down I wanted to use shutdown hooks. But they
only really work when the program terminates cleanly. It would be nice
if shutdown hooks were also triggered when the program receives a
fatal signal (such as the user pressing Control-C).

Snark uses java-gnome as UI just because it is available (in Debian)
now.  Didn't look at gnome-gcj yet (which isn't packaged for
Debian). Hopefully in the future snark will use our own AWT
implementation, but that wouldn't create such a well integrated
application with the rest of the Gnome desktop. I didn't consider
using SWT since it has the disadvantage that it also isn't currently
packaged for Debian and distributed under the CPL which is not GPL
compatible.

java-gnome <http://java-gnome.sourceforge.net/> was surprisingly
usable. The main drawback is that it currently is only available as
jar files with jni libraries in Debian which means that you will have
to use gij at the moment. It is also not very friendly when used
slightly wrong (accessing a widget that has been destroyed or calling
some methods in the wrong order crashes your application hard. But
when used correctly you can create a simple UI without to much work.
I did post a bigger evaluation to the java-gnome mailinglist.

When debugging your native program it is really unhelpful that
NullPointerExceptions don't point at where the actual exception
occured but at the calling method. When using the interpreter Kaffe is
nicer since it gives line numbers. And using gdb with gij gives not
that nice backtraces since you can only see the interpreter frames.

Since only Debian (unstable) currently distributes the gcj 3.3 version
I also provide a static linked version of the program. This does work
mostly but not always. The two main problems that users have are PAM
and iconv (libraryy) loading which crashes the binary. The PAM problem
was analysed by Adam Megacz, but there is no real workaround besides
recompiling libgcj, see http://gcc.gnu.org/ml/java/2002-11/msg00390.html
the iconv problems can be worked around by declaring LANG=C LC_CTYPE=C.

One thing that I didn't really tackle yet is creating a clean GNU
configure/make install with all the nice standard make targets. I
found automake a bit confusing and it didn't seem to handle the simple
application case and seems to insist on creating. I haven't looked yet
how rhug handles this, but the Makefile.am used there didn't seem very
simple or small. But Nic Ferrier did send me his automakejar which I
still have to try out (sorry Nic). At the moment I just use a simple
hand made Makefile.  A simple example how to create a native binary
and jar file with manifest from a collection of classes would be nice
to have.

Something that I learned from working on this project is that it is
really nice to have a irc channel to directly discuss some issues with
interested people. We should really consider setting up a gnu-java
channel on freenode. Are people interested in this?

Cheers,

Mark