java-gnome 4.0.9 released!

This blog post is an extract of the release note from the NEWS file which you can read online … or in the sources, of course!

java-gnome 4.0.9 (13 Oct 2008)

The pen is mightier than the sword

New coverage

This is the first release with coverage of GTK’s powerful TextView/TextBuffer multi-line text display and editing Widget. This has been the result of several months of careful effort to present a clean and self-consistent API while remaining faithful to the underlying implementation. This bulk of this work was done by Stefan Prelle and Andrew Cowie, with contributions from Kenneth Prugh and testing by many people in the #java-gnome community.

The snapshot at right is from ExampleInstantMessenger, included with the sources. It is a somewhat detailed example showing the use of TextView, TextBuffer, and related classes.

Other improvements

Continuous improvement to various classes, especially in our documentation. Incremental changes have occurred in a number of places. In the TreeView/TreeModel APIs, some useful methods for translating TreeIters from one model to another have been added.

Also thanks to the persistent work of Stefan Prelle, we now have nice coverage of GTK’s Assistant (aka druid, wizard, etc), along with better support for doing popup context menus, including some bug fixes. Thanks to Srichand Pendyala for taking care of this and to Owen Taylor for having explained out some of the underlying implementation details.

As usual, incremental improvements to core classes continue. Virtually every class has been touched in one way or another; many changes are cosmetic but they add up to a nice delta overall.

Reducing memory pressure

Internally, java-gnome maintains a lookup table so that pointers coming from the C side can be converted into proxy objects for the case where a proxy has already been created. In any library there a great number of transient and temporary objects and structures allocated, and in wrapping native GNOME libraries we are no different. It turned out that registering these temporary objects was putting pressure on the lookup table. While these objects were properly weak referenced and being garbage collected (and thence freed), there were nevertheless an enormous number of temporary objects being inserted and removed from the lookup table — and that sort of thing causes hash tables to grow overly large.

To do something about this we have split the former hierarchy root into two classes. Only structures which have a persistent identity (which, in practise, means only GObjects and certain Cairo entities) are registered so they can be looked up by address later as necessary. The rest of the Java side proxies aren’t registered, essentially eliminating the transient pressure on the lookup table.

Thanks to Vreixo Formoso for doing the bulk of the leg-work on this one.

Making it easier to run java-gnome programs

Because java-gnome is directly binds to underlying system libraries, it has a native shared library component. This led to the usual development hassle of having to specify where this library is to be found if it were anywhere other than /usr and of course the nightmare of ensuring a VM used the right library in the event you were developing against or hacking on a newer version of java-gnome; in Java this meant:

$ java -classpath /opt/local/share/java/gtk-4.0.jar:. -Djava.library.path=/opt/local/lib com.example.Program

No longer!

The native shared library part of java-gnome is now located deterministically and loaded automatically. You don’t need to faff about with java.library.path on the command line or in your IDE any more!

$ java -classpath /opt/local/share/java/gtk-4.0.jar:. com.example.Program

Our native component is completely coupled to the specific release you are using, so sufficient version information is embedded in the .so name to ensure that the right library (and only the right library) is loaded.

There are no changes if you are simply working against an “in-place” development build of java-gnome, be it from command line, or in an IDE like Eclipse. Things will Just Work™. Again, no -Djava.library.path.

This whole issue turned out to be a real stumbling block for new developers attempting to use the bindings; it’s not something that many Java programmers have had to deal with, so engineering around this problem to make the native library loading transparent is a big win for us.

Build system improvements

Serkan Kaba has contributed a number of internal improvements allowing the top level ./configure script to be precise about the versions of various GNOME dependencies we require.

Thanks to some hard work from Serkan Kaba and new contributor George McLachlan, java-gnome correctly builds against GTK 2.14 without any problems due to deprecations.

Note that java-gnome releases do not set GTK_DISABLE_DEPRECATED (this is a change from 4.0.8); thanks to Mart Raudsepp of the Gentoo Linux desktop team for pointing out why this would be better. These macros are still enabled for builds checked out from version control so hackers working on the bindings so will be able to keep up with ensuring we react to future deprecations (it’s always awesome when downstream is a part of the upstream community; Serkan and Kenneth are also Gentoo packagers, and take care of the java-gnome .ebuild for us).

Looking ahead

We’re pretty happy with the state of the java-gnome right now. Coverage of the most important parts of GTK are in place. Our treatment of the underlying drawing library, Cairo, still has a bit to go, but the basics are there and a firm foundation to build from. More interesting are the remaining areas; the more general GNOME utility libraries and other parts of the Free Desktop stack that might be needed by an end-user application. It’ll be interesting to see how these areas evolve in the coming months.

You can download java-gnome from ftp.gnome.org or easily checkout a branch from ‘mainline‘ using Bazaar:

$ bzr checkout bzr://research.operationaldynamics.com/bzr/java-gnome/mainline java-gnome

AfC

We make this service available to our staff in order to promote the discourse of ideas especially as relates to the development of Open Source worldwide. Blog entries on this site, however, are the musings of the authors as individuals and do not represent the views of Operational Dynamics. All times UTC.