| 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 > gtk26-to-gtk28-part2
Fri, 02 Sep 2005
Testing the GTK 2.6 to 2.8 upgrade path - Part 2
I’ve been testing the upgrade path for java-gnome. Last week I verified that if the underlying GTK+ upgraded to 2.8, an older libgtk-java 2.6 would still work. Yeay. The next part to test is, of course, that existing apps still run cleanly when libgtk-java revs from 2.6 to 2.8. This has turned out to be trickier than I would have hoped.
During this cycle, a library called cairo-java was introduced. Since it depended on things in common with other java-gnome libraries, Jeff, Nick and Ismael spliced out the core GObject stuff and put it in a common base library. That means that now to build libgtk-java you’ll need this base library (I’m being vague about the name on purpose; more in a sec) and cairo-java. That’s not so bad (although it would have been nice if we’d had tarballs somewhere along the way) but it turns out that when Jeff moved Handle from libgtk-java he also moved it from java package org.gnu.glib.Handle to something called org.gnu.javagnome.Handle.
This is problematic because it means that just about any Java application that has been written so far and that imports org.gnu.glib.Handle will break and fail to compile if libgtk-java is upgraded. Java does not have C’s problems about stability - you can quite happily add a method or constructor and not break API or ABI compatibility - but this would be a serious ABI break and that’d be a shame without a really good reason. Even (especially) stable libglade-java no longer works because of this change.
Meanwhile, a number of us weren’t thrilled about the name that the base library is got called in CVS (“jg-common”) and so back in April we decided to rename it to a more sensible glib-java. Trouble is, no one actually got around to doing said rename, which started to seriously worry me - I do the downstream packaging for Gentoo and know how much of nightmare it is to change a package name once it’s been released out into the wilds. Better to get it right before the first release goes out.
Well, changing the library name pointed the way towards how to fix the ABI problem: put Handle back in org.gnu.glib where it came from (and, indeed an appropriate namespace for something that is in a library that will be called glib-java, after all). As it happens, Java is very good about multiple libraries jointly making contributions to the unified Java package namespace, so it won’t cause a problem with the other org.gnu.glib classes that have yet to migrate from libgtk-java.
I’ve got the library rename done and propagated up to cairo-java and libgtk-java. Reverting the class move will be a much bigger patch, but a couple of us are working on that now and Eclipse will take care of 90% of the work. Still, it means that libgtk-java 2.8.0 is probably going to be a couple of weeks yet.
For those that are interested, there has been considerable discussion of this topic on the java-gnome-hackers mailing list.
In the mean time, we’ve seen a bit of new blood (yeay!) and a number of long standing bugs have been nailed! We’re just about ready to pump out a bug fix release from the stable branch, 2.6.3. I’ve been hosting unofficial release candidate tarballs at my company’s R&D site.
AfC
Category Specific Feeds.
Use these links for an RSS or ATOM feed limited to this category and its descendants.
Technorati Profile
