java-gnome 4.1.3, released 4 May 2013
Overview, News
Tutorials, API, and Hacking
Binaries and Source
Mailing Lists, IRC, and Reporting Bugs


Re-engineering (2): Objective and Audience

Now that you’ve done your homework, we can talk about where we’re going and why.

As I’ve said elsewhere on many occasions, I have the utmost respect for the authors who have built the Java bindings up over the past 9 years. As someone with well over 38,400 lines of application code built on libgtk-java and friends, I continue to be astounded by the richness and power of GTK and the ease of use [relative to C, anyway] of the bindings.

Having been a developer with java-gnome, QA person for a distro’s packages, then author of that distro’s packages of the java-gnome libraries, meanwhile bug reporter to the bindings themselves, then code contributor, then committer, for now for the last year or so I have found myself the titular maintainer of the java-gnome project. Along the way as I’ve been confronted with bug reports, patches, and my own attempts to scratch out improvements, I’ve gained a fair familiarity with what’s inside the guts of the project and appreciate well the complexity and pain involved in deploying a set of libraries such as ours.

6 weeks ago I was sitting at GUADEC listening to the lecture about all the new features in GTK 2.10, and I started going into cardiac arrest wondering how the heck we were going to manually re-invent and wrap all the new APIs. Unfortunately, the existing foundation we have just isn’t scalable and requires far too much work to maintain, let alone grow.

So we’re off on a redesign, something we’ve been talking about for years. The primary motivation for this process is so that we can switch to a mostly generated bindings to allow us keep up with the underlying libraries with minimal further marginal effort, but along the way hopefully we can improve some of the things that have been less than ideal all these years.

That’s all nice and fine, but who are we as a project, and what are we trying to achieve?

I’d like to put the following suggestion of what our goals should be and who I think our audience is to you in this email; the following one will describe what I think the overall design constraints are, and then we can move on into the technical decisions we need to agree upon which we will use to govern the rest of our work together.


As I see it, our mission, as a bindings, is to achieve one quality above all else:


I define this to mean that we take every effort to make java-gnome as easy to learn as possible and as pleasant to develop with as possible.

Bog knows GTK itself is hard! The GTK APIs themselves are rich and powerful but with that richness comes complexity and detail that needs to be mastered.

In its native C, GTK programs are very nearly impenetrable, certainly exceedingly verbose, and brutally difficult to debug. All these factors are areas where Java in general and java-gnome in particular are a great improvement. In particular, we’ve already seen that the combination of a naturally object-oriented language like Java along with the code completion features of a rich IDE like Eclipse make for a really excellent development experience.

If we do our job with the bindings right, then newcomers who have chosen to write a GTK app from Java to quickly learn for themselves how to go about doing what they need to do.

This doesn’t mean we don’t do things differently! After all is said and done, technically, the primary goal is:


so we will do our best to come up with an excellent representation of GTK in Java, not to come up with some idealized watered-down middle-of-the-road please-everyone toolkit that looks like all the other toolkits just because that’s the way they look.

Rather, we’re trying to do as effective a language binding as we can possibly come up with, consistent with the discussion in the rest of this email and the ones that follow in topic (2).


We have a number of audiences to look towards. It’s just as important, however, to point out who I don’t think we should be worrying about, as much as who we are trying to support.

Java developers who want to write a “native” Linux app: YES!

There is an important segment which I think we can address effectively: the huge number of people with Java programming experience.

You might think this goes without saying, but specifically, our target audience are people who are Java programmers who happen to be using GNOME on Linux or Solaris and who just might like to write an application and want it to look good and therefore want to write it in GTK.

The existing pool of people with Java expertise is enormous and is a large audience whom free software have largely ignored over the years. More than anything, I’d like to ensure we give these people the power to write rich desktop programs and clients, and in the process bring a whole new crowd of people into the amazing world that is GNOME and Software Libre.

People who are already GTK hackers: NOT REALLY

On the other hand, existing GTK hackers are not a group that I think we should be trying to target as our primary audience.

They are, after all, already proficient with GTK! (presumably from C but perhaps from Python or whatever) and are quite the wizards to have been able to do so.

And so I feel no moral imperative to try and convert them to using Java or our bindings. I point this out explicitly to contrast to the Mono project, who treat their work like its some kind of religion that everyone must convert to.

Now: if an experienced GNOME developer wants to move on to using a mature and fast managed runtime, and if they want to avoid writing in Microsoft’s patent encumbered languages, and if they want to take advantage of the monumental power of Eclipse, then yes, absolutely, we’d love to have them working in GTK via java-gnome.

And that’s one of the reasons that as-complete-as-we-can-manage coverage and an algorithmic mapping of the APIs is important. But in the mean time, lets concentrate on approachability, ok?

Everyone else: NO

There are lots of GUI choices out there already.

We will differentiate ourselves by being a good binding of GTK.

If someone wants to go on and on about how SWING does that and SWT does that, well then my very simple answer is “sure, no problem. Go use it, then”. We’re not forcing anyone to do anything; Open Source is about choice, after all.

So we don’t have to try and be all things to all people, which frees us up nicely to concentrate on doing a good job of being a Java binding to GTK, Cairo, and the GNOME libraries.

Which leads us to the question of how we can best do that. Design constraints are the subject of the next document.


Originally written as an email to java-gnome-hackers by Andrew Cowie on 19 Aug 06; last modified 4 Dec 06.

Contents copyright © 2006-2011 Operational Dynamics Consulting Pty Ltd, and Others. See AUTHORS file and source code history for the various files comprising this site for full details. This page was generated from a text document! We use John Gruber's Markdown syntax as ported to PHP by Michel Fortin. See MARKUP for details