Older blog entries for kuzman (starting at number 10)

10 May 2005 (updated 10 May 2005 at 20:15 UTC) »
The Java Debate

It has been quite interesting to see that passions that have been ignited since the Apache Harmony announcement. The majority of postings I have read jump to the conclusion that this effort will try to create a new JVM and class library to compete against or replace gcj, Kaffe, and GNU Classpath. It is easy to see how somebody could have this opinion since the announcement was unclear on the implementation (approach). I feel fairly confident that this is not the case. Since the announcement (and prior to the announcement) Classpath and Apache developers have had irc discussion on how to move forward (together) on this effort. Mark Wielaard (project leader for GNU Classpath) created a page that captures his thoughts on Harmony. This page has links to other documents relevant to this discussion. You can find it here.

Free Java?

The progress made by free java developers is nothing short of amazing. If you are interested in developing free java applications you will find that there are stable and robust compilers, runtimes, class libraries, application servers and development environments. The entire software stack runs on free software. A lot of hard work has gone to get us to this point. I must say that free java is alive and well.

Java in GNOME

The larger question to be answered is what place does Java have in GNOME. I personally find the entire debate of Java vs. Mono misguided at best. Developers should have the freedom to choose the language of their choice when they write applications targeting GNOME. That is why we have C#, Java, Python, Perl, C++ and other language bindings. It is possible to do this because the majority of the platform libraries are written in C. If we allow core platform libraries to be written in C# or Java or (pick another high-level language) we immediately limit the ability of language bindings to provide this core capability to their users. My argument for not including Mono or Java in the platform has nothing to do with a possible threat from Microsoft or Sun. It has to do with freedom and choice.

I think Java, Mono, Python, C++, and other language bindings have an important role to play in the application space. They all contribute to the rich GNOME environment we love so much.

Java-GNOME on Windows

With today's release gtk-java and glade-java build and run on Windows. To find out more you can visit our Windows Compilation page on the Java-GNOME site.

Java-GNOME Con 1

After a lot of coaxing and a promise that the weather will be nice (I'm not sure I believe that one but can it really be any worse than Cleveland?) some people have talked me out of my cave to attend a gathering in Toronto. April 2nd will be the first Java-GNOME hackers meeting. We will be getting started at about 10:00 am EST and I will be giving an overview of the bindings at 11:00 am. The primary focus of the event will be learning how Java-GNOME works, writing code, and having fun. If you can attend in person please let us know on the java-gnome-developer list. Otherwise I hope to see you on #java-gnome irc.


It has been nearly a month since the Java-GNOME team announced our intention to provide cairo bindings. Here is a brief update on where we currently stand.

As of this morning we have nearly complete coverage of all core APIs. We have also implemented PDF, PS, PNG, and in memory image buffer surfaces. To verify our implementation we have implemented 19 of the snippets from cairo-demo as well as the kapow example.

On our TODO list is adding the remaining surfaces and integrating with our gdk, gtk, and pango bindings.

Java-GNOME update

It has been a while since I posted an update and a lot has happend receintly so here goes...

Today libgtk-java 2.6.0 was released (just in time for FOSDEM). I am quite excited about the progress we have made since 2.4. We have completely rewritten the way we store pointers in order to support 64-bit platforms. We have also enhanced our gdk bindings and added complete support for gdk-pixbuf. There are too many improvements to list them all here so I'll stop now.

Today we also made our first gtkmozembed-java, gtkhtml-java, and vte-java releases. The gtkmozembed-java bindings are a keeper but I hope to not make another gtkhtml-java and vte-java release. These bindings were created by developers that joined the project with great excitement, produced a little code, and then vanished into the haze. The code has been sitting around for months (years?) so what was I to do?

We now have cairo bindings in freedesktop cvs. I took a look at the existing CairoJava bindings. They required SWT and used ant for the build system. There were some issues with the way they were handing memory and storing pointers. I talked with the original maintainer and worked out that the Java-GNOME team would create a cairo-java bindings that didn't rely on a specific toolkit (GTK or SWT) and then he could build his SWT layer over it. So I spent the past week or so learning cairo and working on these bindings. I am pretty excited about the start that is in cvs now.

Bad weather halted my flight to Belgium for FOSDEM yesterday. I spent the night in a Hotel in New Jersey that didn't have Internet access. I started hacking on our gnomevfs-java bindings. These are really starting to take shape. We currently have about 50% API coverage. Perhaps I should update our Roadmap to included these bindings in our 2.12 development cycle. What do you think?

Java-GNOME Roadmap

Yesterday we had a Java-GNOME planning session on irc and several decisions were made that will effect the structure and direction of the project. Here is what we decided.

Roadmap - We have agreed on our plan for 2.12 development. You can view this plan on our Roadmap Document. The summary is as follows:

  • We will make a release of our vte-java and gtkhtml-java bindings and then stop development on these bindings.
  • We will deliver cairo bindings
  • We will deliver dbus bindings
  • We will deliver gtkmozembed bindings to replace our old gtkhtml bindings

Release Schedule - Currently all Java-GNOME packages are released at the same time which is based upon a release schedule published by the GNOME project. GTK+ doesn't follow this schedule. Since we are adding new bindings that also do not follow this GNOME schedule we decided that each binding will follow the release schedule of the upstream libraries.

cvs - Currently all Java-GNOME bindings are under the same cvs project. We will be splitting them out so each binding has its own cvs project. Also, the new dbus and cairo bindings should reside on the freedesktop cvs.

Making Java-GNOME Successful

The Java-GNOME project is doing quite well. We will be delivering a new stable release on February 4, the second beta of 2.10 on February 7, and our official 2.10 release on March 7. The 2.10 release will be our most robust release yet and we are quite proud of the results.

Now is a good time to reflect on the Java-GNOME project and its future. The Java-GNOME project started out with a goal of making it easier to write GNOME applications and make it possible to write the code in Java. At this time I must ask myself "Have I accomplished this goal?". The answer is 'yes' and 'no'. I'll try to explain later but first let me set the context by looking at a couple of related efforts.

I must say that I am totally blown away by the progress made by the classpath, gcj, and kaffe teams (despite what you may have heard, kaffe is not dead). Free Java is moving forward at an amazing pace. Java is quickly becoming a viable Free development platform. This is an essential element for Java-GNOME's future success.

The Mono project and all of the related bindings they have provided is nothing short of amazing. In a short amount of time they have produced a robust development platform. They have great industry support and many developers contributing to their effort. I see a bright future here and wish them a lot of success.

So now it is time for a question. Would I use Java-GNOME to build a GNOME application? The answer is maybe. While Java-GNOME provides solid bindings for several of the core libraries there is still much that is missing. Unlike the Mono bindings, we do not currently have support for dbus, cairo, gstreamer, etc. GNOME is a vast environment and we have only begun to provide developers access to its capabilities. If you want to build a large GNOME application then Java-GNOME is probably not the right choice at this time.

What does Java-GNOME need in order to be a viable option for GNOME development? Java-GNOME needs nearly complete coverage of all critical APIs available in GNOME. We are not even close today and it will take a considerable amount of time to get there based on the size of the effort and the current pace of development.

What can be done to shorten the timeline for Java-GNOME to be a complete GNOME development platform? To be very direct I would say that our greatest need is for more hackers. This project has fluctuated between one to two major contributors during its entire lifetime. There are currently two major contributors that work on the project in our spare time. It is nearly impossible to move the project forward at a reasonable pace without more help.

The Mono project has Novell as a corporate sponsor. This has allowed the project to acquire some very talented developers that have been able to focus on delivering a quality product in a reasonable amount of time. A similar sponsorship would be a huge boost for the Java-GNOME project. Such a sponsorship would allow Java-GNOME to move forward at a much faster pace and deliver an alternative to using Mono for GNOME desktop development.

What will it take to make Java-GNOME successful? It will take you. If you are a Java developer that would like to see choices for GNOME development then you are needed on this project. If you are a large Linux distributor with lots of money in the bank and would like to see choices for GNOME development then my home phone number is .....

Java-GNOME 2.10 beta 1 is out. I have been working on a complete rewrite of the build system (with the help of Thomas Fitzsimons). The new build is fully automake/libtool enabled and is a major simplification over the old approach. 2.10 is really shaping up to be our best release ever.

We are already looking forward to our next development cycle. I am hoping to get our gnomevfs bindings included in the officail GNOME Bindings Release. I also want to start dbus and cairo bindings. It sounds like a lot but I am really motivated now!!

Andrew Overholt put together a great flash presentation demonstrating native eclipse, glade, and java-gnome. You can view it here.

Java-GNOME 2.9.4 was released last Monday. There were major enhancements for bindings including full support for gdk-pixbuf, support for GObject properties set/get/notify, and the addition of missing gdk, atk, and pango APIs. This release also marked our API freeze for the 2.9 development period. Our focus has now shifted to fixing any remaining bugs, updating documentation and examples, and I am currently working on getting libgtk-java to build on the Windows platform. Should be fun.

Will I have 64-bit support for libgtk-java, libgnome-java and libgconf-java. Nick complete 64-bit support for libglade-java. I guess I am making good progress.

1 older entry...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!