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

java-gnome-4.0.9-release, posted by Andrew Cowie in /andrew/software/java-gnome at 11:49, 13 Oct 2008.

HTTP response code nuttiness

The technique of using a 404 error handler to actually render a web page from some underlying source or data is widely used. We use it on the java-gnome website to render prettily marked-up versions of our text meta documents (NEWS, README, HACKING, etc). The document you’re asking for (“README.html”) doesn’t exist, but a text source (“README”) does and so it reads that file in, runs the markup processor, and then serves the result. Yawn.

If you’re already in an error handler, then the default status code as far as the web server is concerned is, of course, HTTP 404. So you need to change that. In PHP, that’s as simple as:

<?
    header("HTTP/1.1 200 OK");
?>

which is actually treated a bit magically to tweak the response code. Too easy. This worked fine on our test site and on the production site for, well, years.

We ran into a weird problem that at some point over the last few weeks that suddenly I was seeing garbage appearing at the beginning and end of documents being so rendered on our SourceForge website. Huh?

I still have no idea what is wrong, and won’t detail all the diagnostics it took to track down the problem, but I ended up isolating it to the header() call. If I skipped that, then the document would render and serve correctly. But that’s no good, because then you are serving documents with an HTTP 404 error code, which will inhibit search indexing and caching even if it doesn’t screw with your browser.

The workaround ended up being this:

<?
    header("HTTP/1.0 200 OK");
?>

I have no idea why, but with whatever SourceForge has done to their webservers lately, this made it work fine. Go figure.

The real inanity, though, is that using wget to fetch the document while showing HTTP headers the result is this:

$ wget -x -S http://java-gnome.sourceforge.net/4.0/README.html
--2008-10-13 14:11:28--  http://java-gnome.sourceforge.net/4.0/README.html
Resolving java-gnome.sourceforge.net... 216.34.181.96
Connecting to java-gnome.sourceforge.net|216.34.181.96|:80... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Server: nginx/0.6.31
  Date: Mon, 13 Oct 2008 03:11:29 GMT
  Content-Type: text/html; charset=UTF-8
  Connection: close
  X-Powered-By: PHP/5.2.6
  Last-Modified: Sun, 12 Oct 2008 14:02:37 GMT
Length: unspecified [text/html]
Saving to: `java-gnome.sourceforge.net/4.0/README.html'

    [    <=>                                ] 16,052      22.3K/s   in 0.7s    

2008-10-13 14:11:30 (22.3 KB/s) - `java-gnome.sourceforge.net/4.0/README.html' saved [16052]
$

Their web server sent an HTTP/1.1 response anyway! Talk about adding insult to injury. What a waste of time.

I’m sure this is just one of those transient conditions that’ll be gone by this time next week, but it sure as hell frustrated me. If you’re seeing something weird going on with PHP pages on one of your SourceForge sites, perhaps have a look and see if this workaround helps.

{shrug}

AfC

something-weird-with-sourceforge, posted by Andrew Cowie in /andrew/software/java-gnome at 03:24, 13 Oct 2008.

Sun, 05 Oct 2008

Congratulations Manly!

There really is nothing better than being in your home town at a pub surrounded by several hundred screaming fans when the home side is playing in the Grand Final of its league and then watching them trounce the opposition 40 to 0.

Photo by Brendan Esposito, as presented on the League HQ website

Congratulations to the Manly Sea Eagles for winning the 2008 Rugby League premiership!

AfC

manly-sea-eagles-rugby-league-2008, posted by Andrew Cowie in /andrew/personal/compliments at 12:58, 05 Oct 2008.

---

Category Specific Feeds. Use these links for an RSS or ATOM feed limited to this category and its descendants. Technorati Profile

---