One of the most fascinating aspects of KDE is the speed with which new developments
occur after each release. KDE 2.1 came out yesterday, and was celebrated in
the traditional manner by adding lots of new features to the KDE development tree
in CVS. For me, one of the most exciting things to arrive was a very large commit
to the kdebindings
module (used for bindings between KDE's C++ code and other programing languages)
which added bindings for the KDE and Qt libraries to the well known Java
language. The author of the code, Richard Dale, has kindly agreed to answer
some questions so that readers of the Dot can get up to speed with this new
addition to KDE.

1. What do QtJava and KDEJava actually do?

They wrap most of the classes in Qt and KDE so that they can be used to write
Java programs, which look and behave identically to a C++ version. The Qt date,
time, string and list classes are replaced with their Java equivalents.

2. What would you say are the best features of the binding?

It uses KDOC as the parser engine, so it has access to the documentation comments of
the KDE methods. It translates these comments into Javadoc format, and has a go
at translating the code snippets into 'cod java' - ie C++ with those funny symbols
like '&', '*', '::' (that you never quite mastered ;-) ) replaced with java
style '.'s.

3. What made you decide to write this, and how long did it take?

I wrote some code to patch KDevelop and KDOC 1.0 to use Objective-C for gnustep
development in late 1999. After I'd done that, someone posted a question to
comp.lang.objective-c asking about whether there were any Objective-C bindings
for Qt. I thought that if I could do some bindings, I'd have a really nice complete
Objective-C programming environment.

I started using Roberto Alsina's QtC for the C bindings and shell scripts for
the Objective-C side (you can't call C++ directly from Objective-C, so you have
to do two sets of bindings). I completed a prototype version good enough to
run Qt Scribble in Objective-C in about 3 months. But the work was very labour
intensive and I couldn't see how I could manage to get the whole Qt/KDE api
done.

I wrote a patch to add Objective-C support to kdoc 2.0, so I got familiar with
the Perl code. Mathieu Chouinard emailed me asking
about how work on the Objective-C bindings was going. I told him I'd started
to hack Roberto's Python scripts, but it was still taking a lot of work to get
anything wrapped. Then it occured to me that it would be easier to make KDOC
generate the same code as the python stuff, than it would be to make the Python
parse as well as KDOC. After two months (less time than the prototype took),
we had two KDOC-based converters, for C and Objective-C, for Qt 2.2 wrapped and
working, and I was about to start on KDE 2.0.

But once I realised I could the same thing for Java/JNI at the end of October
or so, I just downed tools on Objective-C and ran for it. Er.. 24 by 7. I haven't
still been programming when the birds start singing since late 1988 or so! I
got Qt 2.2 done before Christmas, then had six weeks off starting again in February.
So KDE 2.0 has taken a bit less than a month to get this far.

Probably about a man year of 40 hour weeks for C/Objective-C/Java in total.

4. Who do you think will find this code most useful?

One group might be those people who would like to write apps with full Qt or
KDE look and feel, but prefer to code in Java over C++ (because it's quicker).
Another group might be those taking existing Java code and wrapping it to get
a fully functional KDE app. A third group might use the Qt side to write apps
which will run cross-platform, both on standard Wintel PC's (a port to Windows
should be straightforward) and Linux, *BSD, etc.

5. How much of the Qt and KDE APIs have you covered?

280 Qt classes and over 400 KDE classes - pretty complete.

6. How hard do you think it will be to extend the binding to cover the new
features in KDE 2.1?

The manual edits applied to get the bindings working are in the form of a
patch. So the KDE 2.1 headers need to be put through the converter, then the
patch applied. Finally, the diffs added to the KDE CVS since the initial check-in
must be applied, and any essential new 2.1 classes added to the project.

If the underlying C++ instance of '_colormenu' has an 'activated(int)' signal,
the Java slot is connected to that. Otherwise, the runtime assumes that you
want to connect to a Java signal and it connects the slot to that instead.

Emitting a signal looks like this:

emit("colorChanged", darkGreen());

8. How does this compare with AWT and Swing?

A very interesting question! I've never done any AWT or Swing programming (my
background is Objective-C with NeXTSTEP). It doesn't appeal to me because the
subclassing and managment of event listeners looks clunky and doesn't make use
of Java's dynamic runtime. Swing code appears to need 5 times as many classes
and twice the bulk, yet offers less functionality, compared to Apple's
Cocoa or Trolltech's Qt.

9. How hard is it for developers to add Java support for their own Qt widgets?

The KDOC converter is included in the Koala KDE bindings project, so they can
run their widget headers through that and convert them. One day per widget or
so would be my estimate

10. Could this code be used to embed Java code in a C++ KDE application?

Yes, you can mix C++ and Java. The objects don't always have to be instantiated
from within the Java environment. If you allocate an object instance on the
C++ side, and then you refer to it from within Java, a Java version is created
automatically. However, when the Java version is subsequently garbage collected, the
C++ instance isn't freed by the Java runtime. It would still exist over in the
C++ environment.

However, if you instantiate an instance on the Java side with a 'new' command
then the C++ is freed on Java garbarge collection.

11. Where do you plan to go from here?

I plan to finish the Objective-C and C bindings for KDE, finish adding Objective-C and
Java support to KDevelop 2.0 and contribute bug fixes/enhancements to the code
just released.

12. Is there anything else you'd like to say?

I haven't given the KDOC author a namecheck - which I think he
deserves. So a big hand to Sirtaj Singh Kang from me
is deserved. Also I forgot to mention there is a patch to the Qt Designer
uic tool to generate Java from exactly the same .ui files as C++.

I'd like to thank Richard for creating this cool new binding,
and for finding the time to answer my questions. You can get the code
by checking out the
kdebindings module from the CVS; it's not included in the packages
for KDE 2.1 because it's so new. I have added some information to theJava language bindings
section of the developer site, including an example of using the
bindings for people to have a look at. People interested in using
Java with KDE might want to join thekde-java mailing list.

Comments

Sorry, what I was trying to get at was that the people pushing GNOME (users, loudmouths, etc.) seem to have this hatred of Java. Part of this is political (GNOME started because of a dispute over QT licensing; while the real reason was RMS's admirable goals of a GNU system require a fully GPL'd solution, preferably under FSF's copyright), part is technology (GNOME/GTK is based upon C, and part of it was complaints about C++ and Object Oriented programming in general, if you wanted to build OO Apps, you'd be using KDE/QT before GNOME/GTK.

The point I'm getting at is the anti-Java, anti-OO, pro-GNOME faction, which is a REALLY loud vocal minority, will never make Java for GNOME seem like a Kosher option. They'll be major bitching and whining about anything significant being Java based, and how C was the epitomy of computer knowledge.

I'm sure Qt already runs on Mac OS X (because it's *BSD), but only under X-Windows. So it would be nice to have native Quartz widgets for Qt, as well as Aqua look alikes (if Apple allows it) for X. With X seamlessly integrated and running under Quartz. I'm looking forward to finishing the Objective-C bindings + KDevelop 2.0 support anyway, it should a nice combo.

Oh absolutely. The QT under X-Windows is a nice option, as every Unix geek will buy a commercial X Server or use the XonX from the XFree port. However, in my ideal world, I'd like native Aqua widgets.

My reasoning is that having QT support on OS X through X Windows means that I can run my Unix apps on my GNU/MacOS box, but it doesn't fulfill the ideal. The ideal approach is that as a software developer, I can target both platforms with one application, which means that the combined KDE/MacOS X desktop market may be a reasonable market to target, even if the KDE, of MacOS markets aren't. If we could get GNOME to do the same (port GTK to MacOS X Aqua/Quartz), then MacOS becomes the peace-maker. An API that can target GNOME, KDE, and MacOS X results in a real market to target, and a growing one at that. Even if MacOS X doesn't bring Mac more marketshare, they will maintain their current 8%(?), which will be more than Unix/Unix-like desktops for 2-3 years minimum, and will be a significant market for at least 10...

Think another way, as a programmer, I can build Free Software available for download without any support (including pretty GUI installers, etc.) and even make it available on my web site. I can make a commercial package for MacOS (under GPL if I want) that I charge to download from my site. MacOS users are much more likely to buy the package, so I can build free software and still earn a living.

That's why a KDE/GNOME/MacOS-X alliance is key. It means revenue from Mac users can finance the development of good free software for KDE/GNOME/Unix geeks using MacOS-X.