Older blog entries for mjw (starting at number 32)

Advogato

When advogato was down a couple of months ago I moved my diary to my own site. Which also hosts Planet Classpath. I should probably try to cross post my dairy on advogato since it is a nice community.

gcj

Saw that rbultje had some trouble with GNU gcj. It is always painful to see someones first steps with one of your projects be so hard. Especially since he hit a long standing usability bug. The solution to your problem was to do:

cd ..
gcj -o myapp application/*.java --main=application.Application

But that probably only makes sense if you know a little bit more about how gcj (and java in general) puts modules (packages) in directories, but uses dot (.) in source files or when indicating classes in a package on the command line.

Not being able to find the GTK+ AWT libraries is strange though. If you installed gcc yourself then you need to configure with --enable-java-awt=gtk, --enable-java-awt=xlib for the pure xlib version or, if you want both, --enable-java-awt=gtk,xlib. Normally distributions do already ship packages like this. If you are using Debian unstable then please note that the current libgcj5-awt package is broken in testing/sarge. This should be solved by the package in unstable that hopefully enters testing before the freeze.

Please send an email to the mailinglist if you have trouble with gcj. Or drop by on #gcj on irc.oftc.net. There are always people there that might be able to help and get you through your first steps in a couple of minutes. You don't have to spend hours struggling on your own.

Kaffe, can you say AWT?

robilad is a human merging machine :) He actually integrated the work of jserv and saugart which means that Kaffe OpenVM now has three AWT backends (QT, X and GTK+). This should also make Kaffe useable for hacking on GNU Classpath's AWT and Swing implementations.

And just to add to the free AWT/Swing UI fun graydon prepared the "monthly merge":

• AWT lists use GTK treeviews
• proper AWT focus management has been implemented
• swing menus and scrollpanes are beginning to work
• swing splitpanes, dialogs and internal frames were added
• swing repainting / double buffering was redone
• a lot of AWT imaging and event bugs have been picked out

Sweet!

GNU Classpath, JamVM and Eclipse

When Robert released the latest JamVM 1.1.4 his release notes just said:

• JNI enhancements introduced in Java 1.2 implemented.
• Updated to use GNU Classpath 0.09.
• [...Some build infrastructure improvements...]
• Minor bug-fixes and speed optimisations.
• Eclipse now starts up.

Note that last little point. Eclipse is a huge complex application (suite) that tests most of the runtime and library facilities. When a java-like runtime is able to provide the execution environment for such a large project it is a sign that the project has matured and can be used for some serious work. I am really excited about this "little" break-through. Of course GNU gcj, Kaffe OpenVM, Jikes RVM and ikvm.net already could be used as alternative execution environments for Eclipse. But JamVM is the first "pure GNU Classpath runtime" that does it which is also really easy to install. All the other runtimes have larger or smaller hacks (mainly to some of the native or vm specific code) and/or are not that easy to install (need another VM or .net environment to be bootstrapped for example). JamVM does it without any JamVM specific GNU Classpath hacks and only depends on GNU Classpath and a simple C compiler. So this also proofs that GNU Classpath itself is pretty mature and usable out of the box.

We are not completely there yet though. Playing a bit with it shows some obvious bugs in our code. There seems to be some nasty with the serialization code that I cannot pinpoint. Runtime.exec() seems to have some strange issues passing some environment variables (like PATH), VMProcess had a bug that Process.wait() wouldn't work reliable (fixed in CVS) and ResourceBundle doesn't always seem to be working with the correct classloader. So still lots of stuff to hack on. But now that we are able to run this huge test suite (some call it an IDE) out of the box it will be easy to finally fix those issues once and for all. And hopefully in a generic way that can be used for all runtimes based on GNU Classpath.

If you want to play with it just install GNU Classpath 0.09, JamVM 1.1.4 and Eclipse 2.1 (gtk+). And do:

PATH=.:$PATH ./eclipse -vm /usr/local/jamvm/bin/jamvm -verbose -consoleLog -vmargs -mx256M -ms256M
killall eclipse (or CTRL-C if you don't have your prompt back after 20 seconds)
rm workspace/.metadata/.registry
PATH=.:$PATH ./eclipse -vm /usr/local/jamvm/bin/jamvm -verbose -consoleLog -vmargs -mx256M -ms256M

[Update: If debugging GNU Classpath itself isn't your main goal but you just want a working free eclipse I would recommend native eclipse (eclipse compiled with gcj to a collection of native libraries). It works out of the box on Red Hat systems and when using alien to convert the rpms you can get it working on Debian systems also. You can even use it for hacking the GNU Classpath sources]

Lucene, gcj and python

Deep in a thread about using gcj as a portable way to write programs on different architectures someone mentioned PyLucene, a python integration of Lucene (a full-featured text search engine library written in java), using gcj and SWIG. Which is a really nice showcase for what is possible with GNU gcj. It is used and developed by the OSAF for Chandler which is mostly written in Python.

When submitting the integration to the Lucene project Andi Vajda said:

Yes, I took a look at Lupy [python port of Lucene]. It claims to be 10 times slower than the java version. There is also a C++ port of Lucene, which would have been simpler to integrate, but it comes with its own set of bugs. And of course, each port is behind.

Which is why the fact that GNU gcj could be used to combine java source with Python (through Swig) is so nice. It (partly) solves having to rewrite something in another programming language just to integrate it into a larger project that has a different language preference.

GTK+ AWT peers now on Kaffe

Thanks to the hard work of saugart and jserv (and of course the GNU gcj hackers who worked so hard on the actual AWT peers) Kaffe can now also use the GNU Classpath GTK+ AWT peer implementation (see the announcement, including sweet screenshots).

This is really nice since it brings GNU Classpath and Kaffe OpenVM closer together. And as always when a new set of people start using a piece of free code in new and unexpected ways we found (and fixed!) some bugs (just minutes after the integration). This will really be a boost for the project because it exposes much more people and programs to the code. And it will be the start of the Free Swing integration into Kaffe.

Hacking on KDE with gcj for fun

Helped Boudewijn Rempt recently with getting kde/qtjava working with GNU gcj. It was really fun. And all it took was about three minutes. One to get us a traditional byte code interpreted version with gij. One to get us a complete monolitic native program. And finally another one to split it up in a reusable native shared library ready for linking with other programs. He made a little Creating `native' Qt applications with Java tutorial out of it. What was really nice was that his SUSE 9.1 box came with everything ready to hack in standard packages. Richard Dale made some additional observations which are also nice to read.

The only thing I need to clarify is this comment that Boudewijn made: "Mark Wielaard tells me that for every JNI call, gij is called to generate some bytecode, which is then executed. Things could be faster, he tells me." Which is not correct. JNI is not as fast as CNI, which we prefer to use with gcj specific code, but it is fast enough for this use. It doesn't need to generate extra byte code that needs to be interpreted. What I had wanted to say was that the KDE java bindings use a lot of java.lang.reflect.Proxys. These are currently implemented by creating on the fly byte code that then needs to go through the byte code interpreter. The framework for replacing this with direct native code is there, we just need an interested hacker to write it and wire it up to the rest of the gcj runtime. It is a nice little challenge for someone that want to dive into the gcj runtime.

GNU Classpath

We did it! GNU Classpath 0.09 was released. Just 7 weeks after 0.08 but the amount of improvements is huge. And not only nice new packages and features (javax.print, javax.imageio, service provider support), but also lots of "boring" cleanup work (like making sure all C code is -ansi -pedantic clean, API documentation is clean XHTML) and important architecture improvements (like optimizing nio buffers, implementing java.io through the new java.nio support and cleaning up the runtime interfaces). We also did a lot of work to get even better/clearer Mauve testsuite results. It is amazing what a dedicated group of hackers can do.

And in the end we had a lot of fun finalizing the release. Which was nice because I got a bit burned out earlier in the release cycle from handling some new people wanting to contribute in a way that didn't mix well with the other hackers. It is always nice to have more people on a project, but sometimes there are people that need so much attention that it is hard to make real progress on the technical front. Clearly the project is both a technical and social challenge. It was interesting to see how the group handles growth. Luckily irc does help a lot for communicating (hop on #classpath at irc.gnu.org if you like).

We have to figure out a way to help more people join the project though. One strange thing that seems to be happening is people offering help, looking at what still has to be done and then seeing that GNU Classpath is already very complete or that all interesting tasks already seem to have people dedicated to them (some of which are actually paid to work on it). This seems to put people off. We do have a big Hacking Guide and a (admittedly small) Task List. But we need to try to improve the situation even more for people wanting to join. I am not sure how though.

Free java meeting/GCC Summit

Nothing helps a group so much as meeting in person. A group of GNU Classpath and gcj hackers will meet next month during the GCC Summit. I have never been to Canada and I am really looking forward to it. Hopefully I can also meet some people that won't go to the Summit itself.

Sun, IBM, Free Software and java

Read a very good article by Tom Tromey on Planet Classpath about these companies and their struggle with the Free Software community. What amazes me the most is how Sun representatives make it sound like Free Software, the GPL and Open Source are not clearly defined concepts. They talk about making things "mostly like Open Source, but with us in control" or about releasing things under "something like the GPL, but without all those freedoms". Can these people please make up their minds.

Vacation

Having spend so much time working on-line it will be nice to have a little off-line vacation.

Code cleanup, regression testing and benchmarks

This week was mostly doing boring cleanup work. Tried to get the GNU Classpath native C code base -ansi -pedantic clean and turned on -Wall. Hopefully we can even add -Werror soon. Made sure that everything works well with gcc-2.95, gcc296 (yuck) and gcc 3.x, with and without -O2. Seems we are in decent shape now.

People really need to take more care about the Mauve regression testsuite. There were some nasty regressions which came with all the new code contributions. Faster development is good, but it shouldn't cause regression test failures. We are lucky that Mauve is so big now that it catches most problems early. One of the problems it seems is that everybody is using a different runtime environment to test GNU Classpath against mauve and that we don't have a list of canonical good test results.

Stephen Crawley fixed the Unicode tests in Mauve. This made for a fun little micro-benchmark. natively compiling programs with GNU gcj is very, very fast. But Kaffe OpenVM doesn't do bad using JIT v3, but is still about two times slower. IKVM.NET+mono was number three, but surprizingly slower then kaffe (again about two times). Benchmarks that I did last year showed it being only a bit slower then kaffe then. Probably this particular micro-benchmark was not ideal for ikvm/mono. And I still have to try out the ahead of time compile support which will at least reduce the overhead a lot. Interesting enough Jikes RVM was almost as fast as IKVM+Mono and I only had a prototype build. Now that jrvm can be build completely with free tools (it needs kaffe for bootstrapping) I really need to get that development build going again. Only thing stopping me is the two and a half hour bootstrap process. (BTW, please don't take this benchmark to serious, it is a micro-benchmark for one very specialized, small and repetitive task, so don't take the numbers to serious. And see the GNU Classpath mailinglist for responses from the various free runtime hackers. It is great to see so much competition in this area!)

All in all I feel good about the progress we are making and the rapid growth of GNU Classpath and the projects around it. But on the other hand there is so much going on that nobody seems to have time to respond to all the email on the list and take care of new people wanting to help. Sorry, if I haven't responded to email about the project yet. Feel free to send me a reminder email.

Growing pains

It seems that we get more and more people wanting to help out with GNU Classpath. Which is very, very nice. But that also means explaining our hacking customs again and again. So, I finally went through the email archive of the last couple of months and added sections on needed tools and libraries, code conventions, hacking on the code, writing ChangeLog, working with other people/mailinglists, CVS, etc to the GNU Classpath Hacker's Guide. Hope that helps new people fit in faster with the old-hackers who sometimes have known each other for years.

One email that probably deserves to be turned into a guide of its own is GNU Classpath - How to use it. It describes how to get the last 0.08 release working out of the box. And with the latest release of JamVM (1.1.2) you don't need any patches any more to get it working even with GNU Classpath from CVS. Currently investigating how well other VMs work out of the box. I tested that Kissme from CVS works out of the box with GNU Classpath from CVS. Next up is Jikes RVM.

Feeling sick

I hate being sick. Soar throat and a headache. Cannot concentrate. And there are so many exciting things going on. So what I do is I look at the pretty pictures from Grzegorz Prokopski showing Free Swing on SableVM and from Jim Huang showing JSDL on Kaffe. And read about the most amazing news from Steven Augart: Jikes RVM is now fully free software! And there are so many interesting discussions on the GNU Classpath mailinglist and on Planet Classpath...

Please, I want to be better again, and play outside with the new and shiny code...

GNU Classpath

Been very happy with the latest release. Many additions (java.util.regexp/gnu.regexp, java.net.URI, javax.swing.undo, java.awt.geom.CubicCurve2D/QuadCurve2D cubic and quadratic equation solving, javax.print.attribute.standard), i/o speed improvements (BufferedReader and ObjectInputStream). Lots of java.awt and gtk+ peer improvements. Start of embedded window support (browsers). Some Swing work. And the normal list of enhancements and bug fixes.

Also wrote a GNU Classpath 0.08 - How to use it overview. Hopefully it explains the interaction between GNU Classpath, gcj, kaffe, compilers, editors, runtime environments, extension libraries and other building blocks. It should get people quickly and easily up to speed with GNU Classpath hacking.

Patrik Reali made a nice FOSDEM'04 page which describes the last GNU Classpath hacker meeting. It includes reports and presentations given at FOSDEM on the current status and future plans.

Lost in translation

Put Japan on the list of places to visit. The loneliness of people in a foreign country was nicely captured. But the interaction between the two main characters didn't really move me.