"GNU hackers flatten Sun's professionals with they java.util.BitSet" - sounds not so bad. Some simple comparisons show that our BitSet runs roughly 24 % times faster than Sun's 1.6.0 implementation. Sun takes back on HashSet, however - this one is slower in GNU Classpath, more or less by the same percent. See the posted Advogato article for details.

I am not sure why our BitSet is faster. Deciding from OpenJDK, both implementation use the array of long's to keep the data. From the other side, the overall code is so different that it is difficult to say, who makes the benefit. The history of GNU BitSet spans over seven years (1998 - 2005) and have seen many contributions. The main authors of this class seem Jochen Hoenicke, Tom Tromey and Eric Blake.

I have checked near all java.util classes but the remaining differences seem for me too small to be considered seriously. I am, however, happy to discover that GNU Classpath is very far indeed from being universally worse than OpenJDK at any single line of code. The detailed 'class versus class' check may discover more interesting differences.

Today I started to do something that I am sure it was needed long time ago already. I took the latest GNU Classpath distribution and started to rip some selected interesting package, java.util, apart. One time I will check properly if it is worse or maybe same or maybe better the one we have got from Sun.

GNU Classpath has been written over long time by numerous developers. In addition, it usually runs with the different java virtual machine than the Sun's code. In that way, no honest comparison is possible between any units that are smaller than all jre + all rtl together.

So, that I have done so far I moved the chosen set of GNU Classpath java.util classes into some transient package where they do not conflict with java.util from Sun. Some code editing was needed to build everything but in general it was trivial to build it that way. Now I have the two java.util's on the same virtual machine! It is time to try some performance comparison. We will just write some simple tests for that. Stay tuned.

FOSDEM 2008
Unlike two years ago, this time I have been a "completely different person" in FOSDEM: arrived by plane, used hotel and also brought two young developers I supervise - to demonstrate them how the FOSS looks like from the closer distance. Even a very simple things are impressive for some people: that the conference was organized by the university, that it was really large, that the level of the projects is indeed very high and that nobody does not even think to talk about things like cracking iPhones. It is important to resist various FUD in time. This goal seems reached and I am satisfied with the result.
Apart java talks, one of the most interesting things I have seen might be OpenSolaris. While I needed to stuff an extra hard drive into my box just to install it properly, I did - runs fine, scaring the older staff from the oil industry like a resurected ghost: Solaris??? Its dead! It is over! Well, there are many other interesting things - the summarized report was 16 pages long. Really a nice weekend.

... this is to ask a few minutes of your time to help my research group...

Today I haver received one more questionnaire related to the "FOSS research". It is already a second one this month, and as much as I remember already a fifth I have completed. Some wave of "fundamental scientific analysis" on FOSS seems spreading around the world. Why are you programming this? Are the companies involved? Do you feel the owner of your project under GPL? Would you program if you know it would be illegal? How the important development decisions are made inside your project?

Somewhat it was considerably less attention even a year ago. While FOSS developers likely have never be treated as a bunch of hackers about that there is "nothing interesting to know", it seems an achievement that more people accept FOSS development as a kind of process which needs detailed study and understanding. Something similar to the mountain formation.

Hope they will not fish out any weak places in our movement with these surveys. If they potentially could, it is likely time to think about the shared policies how to answer...

libgcj in C-based parallel clusters?

Today I was setting the MPI cluster. A tcl-based expect script is required to arrange the MPI connections. Expect was not present on my SuSe machines by default, but I found it between optional packages. Still, all that this default installation was doing is it was silently hanging with MPI setup script. Hence our team needed to build the more recent expect distribution from the source, remembering all fun of --configure--with (the default ./configure does not find the tcl configuration script on 64 bit platforms).

We had problems with firewalls, also. MPI uses same approach as the old CORBA implementations did: just opens multiple random ports wherever they like. However our 'cluster' is not just for distributed computing - people use them heavily for various purposes, connecting via ssh -X. Finally we decided to use combined mac + ip address filtering with iptables.

Ok, the MPI cluster is now running with full Fortran and C++ support. Likely we will enjoy it, but how to build a bridge back to java? Some of our java programs already have complex GUIs, others are heavily JSP-based - the prospect to rewrite this stuff in C - even parallel C - does not seem attractive. I is now nice to have a java runtime library that connects with C easily, without the need to load and start all java virtual machine as a separate process. All we need is java-style serialization, RMI and maybe RMI-IIOP. It is far less than GNU Classpath is capable to do. Likely it makes a lot of sense to try our old staying-alive libgcj here ...