| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
This section:
Blog postings by Andrew Cowie about Open Source and Software Development
The syndication links at top left will give you a feed for the blog as a whole.
If you'd like a feed specific to this sub-category, see bottom of page.
blogs > andrew > software > java-gnome > java-gnome-4.0.9-release
Mon, 13 Oct 2008
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
Category Specific Feeds.
Use these links for an RSS or ATOM feed limited to this category and its descendants.
Technorati Profile
