GNU/Andrew’s Blog

So I went to the rms talk last Thursday and throughly enjoyed it. This was the second time I’d seen him speak, and can certainly recommend it to others. As others have remarked, he is quite entertaining to listen to and the way he upholds and adheres to his values is worthy of admiration. The last time I saw him speak (maybe three or four years ago in Sheffield), it was on the subject of software patents. This time round, I was treated to a more general FOSS talk, which touched on well-known topics such as the history of GNU, the whole GNU/Linux debacle and truly Free distros along with DRM. rms also made specific mention of commercial Free Software (a common point of confusion for many) and of Free Software in education.

The latter I feel is very important and, as I currently work in a University, it’s a topic close to my heart. Access to source code is an invaluable learning aid. The few pieces of source code our students see, that they haven’t developed with their own hands, are throughly mothballed pieces of code which barely hang together by a string, having being developed by one academic long ago and then passed on like some hand-me-down. They certainly aren’t examples of good coding, but you won’t always find this in Free Software either. What you will find is code that has been used by hundreds if not thousands of users. Code which has been built on numerous platforms and maintained by GNU/Linux distributions. Code which has stood the test of time and experience, even if it still comes out dirty at the end. By contrast, the examples most students see are reused year after year with little to no change to the code. One of our lecturers is currently only distributing the code the students need as binary simply because the code itself is so ugly and hairy he doesn’t want them to use it as an example. The advent of the OpenJDK project will help, because it should mean that the software on the desktops of Free Software users more and more utilises Java. Why is this important? Because the majority of students are taught Java first and foremost. Most of our students never use C throughout their undergraduate life. So examples of big bodies of Java code are what’s needed and the OpenJDK is a great contribution in this respect, as is GNU Classpath — they both provide samples of the good, the bad and the ugly.

The other important point about Free Software in Education is the ‘get them while they’re young’ theory, which rms likened to addicting children to drugs. He seems to like harsh metaphors, but this one I feel is not too overboard. Certainly, proprietary software vendors provide school and university students with cut-down or gratis copies of their wares. The students get used to this software and start to use it. In many cases, they are effectively forced to, as part of their studies. When they then step out into the big wide world, this is all they know. And our teachers and lecturers, far from promoting sharing and education as they should, are helping this addiction process, even if it’s simply by distributing a Word document to students or using that as the format for a handin. I’ve had to repeatedly mail back our university admin staff of late to obtain the minutes to meetings in a format other than the Word document they keep dropping in my inbox. One would hope they would start to take the hint…

For the finale of the talk, we were lucky enough to be visited by St. IGNUcius of the Church of Emacs. rms then took questions from the audience for well over an hour. He has a very admirable way of doing this; he clearly takes in every word being said, and you can hear the response before it comes when someone mentions ‘open source’ rather than ‘free software’ or some other faux pax, which they really should have known better than to utter, given the preceding two hours talk. I’m really surprised rms didn’t get more exsasperated than he did at some of them. I guess he must be used to it by now. He certainly seems to have a clear well-thought out answer for everything.

For those who couldn’t make the talk, I recorded it in full (with questions) and, with the help of Tim Dobson from the Manchester Free Software group, have made this available on-line. Where possible, we’d prefer you obtain the video from the torrent to reduce bandwidth load on those kind enough to host this. You can find the appropriate links on my website. If anyone would like to provide a further HTTP mirror of this, please get in touch. You can also help the Free Software community by helping to seed this via BitTorrent — this will help others get a copy

For those who haven’t yet heard, Richard Stallman will be doing a rare UK talk tomorrow in Manchester.

‘Free Software in Ethics and Practice’ - speaker: Richard Stallman

Thursday 1st May, 2008 - Talk starts at 6:45pm (ends approx. 8:30pm) with refreshments from 6:15pm.

Venue: Room D1, Renold Building, University of Manchester, Sackville Street, Manchester M1 3BB

http://manchester.fsuk.org/blog/

I’ll be there, fingers cross, and hopefully I’ll also be able to record the event.

It seems a lot of projects and distributions are seeing new releases either now or in the very near future. This week, we had a very quiet minor release of GJDoc, the GNU Classpath equivalent to javadoc. 0.7.9 includes a few changes that were previously only available in CVS, but the main one is a small fix that allows Classpath 0.97.1 documentation to be built. Our minor .1 release for 0.97 fixed a bug where the JSR166 code was not being included in the documentation build. With this fixed, it turns out gjdoc would no longer build the documentation as java.util.concurrent.TimeUnit is a rather complicated enumeration that our hacks can’t bypass. Michael Koch, in packaging GJDoc for Debian, was kind enough to point out that having the current release of GJDoc not being able to build documentation for the current release of Classpath was a bad thing. A quick release fixed this by pushing out the fix I made for this issue back in March. Of course, you can now use javadoc for IcedTea/OpenJDK to build the documentation instead; with another Free JDK about, there’s no need to just rely on GJDoc.

I do wonder what the long term future for GJDoc should be. It only works with GNU Classpath at present through a nasty bunch of hacks which cause the parser to skip chunks of the input. It really needs a major cleanup and to be made to work properly with 1.5 code. Thomas Fitzsimmons suggested we should merge it into the GNU Classpath codebase which seems a good idea, as it means we don’t run into this same revision hole we just did. However, it is worth maintaining GJDoc at all? For me, the main features it has over the OpenJDK javadoc are in speed and the look of the output. A key feature is also that it it plays nicer with Free Software i.e. it includes an option to include the source code with syntax highlighting. You can see the output for Classpath 0.97 online.

JikesRVM is also stepping up for a new release, 2.9.3, and this will be the first to showcase the new Classpath support for a non-copying unsynchronised StringBuilder. This is designed for local method usage where the builder will be converted to an immutable String object rather than leaving the method. As a result, I’ve been rushing to get it in a releasable state, as I know there’s a nasty bug lurking in the older patches JikesRVM has been using recently. I managed to do this today after we fixed a build issue. It seems the javah in OpenJDK6 outputs differently named header files to those JikesRVM implicitly depends on. We fixed this by making this dependency explicit as it should be, but perhaps this also uncovered an OpenJDK6 bug. I’m not sure where we should be filing these yet, so I just posted to jdk6-dev.

It’s also nice to hear that Ubuntu has just shipped with IcedTea6 included. Fedora 9 will also ship early next month (May 13th) with similar support and an OpenSUSE build is in the works. It’s nice to see Java support making it into the mainstream, thanks to Sun’s recent moves to make their JDK Free Software. On the less positive side, it seems that Gentoo won’t see support for IcedTea6 anytime soon. The Java Gentoo developers seem to be on a strange mission to support only the proprietary Java solutions (pretty much an inverse of what Fedora, Ubuntu and Debian do). In porting my IcedTea6 ebuild from the Libre Java overlay to their own overlays, they seem to have decided to drop support for GCJ… I’m not even going to go into how dumb this action is, as I could be here a while. Suffice to say, I don’t see how IcedTea6 can be bootstrapped without GCJ, let alone how they expect to then build it on architectures like PPC, PPC64 and ARM, as we’ve seen happen on the OpenJDK distro mailing list. It seems a very odd move for a distribution supposedly built on compiling things from source…

Over the last week, I’ve been getting Gentoo and Free Java up and running on my new x86_64 box, a process which has culminated in the creation of my own overlay:

http://fuseyism.com/hg/libre_java_overlay

For those unfamiliar with Gentoo, an overlay is an additional set of packages (known in Gentoo as ebuilds, as for a source-based distribution the packages are essentially build scripts) which can be placed over the top of the main system tree to provide newer/better versions of existing builds and completely new ones too.

The Libre Java overlay includes a build for GCJ 4.3 (adapted from the one for an alpha snapshot in the java-gcj-overlay) and one for IcedTea6. Unfortunately, Gentoo’s Java support seems incredibly broken — the main stable and experimental (~) distributions don’t include OpenJDK or IcedTea, and the stable versions of GNU Classpath and VMs like CACAO and JamVM are ancient. GNU Classpath is still on 0.90, which is older than the one in Debian stable. It also tries to pull in the proprietary JDK by default; I recommend Free Java Gentoo users add:

dev-java/sun-jdk
dev-java/ibm-jdk
dev-java/jrockit
dev-java/diablo
dev-java/sun-jre-bin
dev-java/blackdown-jdk

to package.mask to avoid accidentally installing proprietary software on their machines. Unfortunately, stable versions of portage have yet to honour any license scheming, although it is in the unstable version. If you use Gentoo, feel free to try out the ebuilds from my overlay and give feedback. To use it, just get Mercurial (emerge mercurial), clone the repository:

hg clone http://fuseyism.com/hg/libre_java_overlay

and then add the following to /etc/make.conf:

PORTDIR_OVERLAY=<location you downloaded libre_java_overlay to>

The build process for IcedTea6 is fully documented on the IcedTea wiki.

Having just read Andrew Cowie’s recent blog, I wanted to comment but couldn’t find an option to do so there. So here it comes here on my blog instead…

Simply put, OpenJDK is so named because it’s a FOSS version of Sun’s JDK the implementation, not Java, which is the specification. Just because OpenJDK is the reference implementation doesn’t mean it is the specification as well. The equivalent would be calling Tomcat OpenServlet (it being the reference servlet implementation). This also reflects on the comments about the HTTP server being in com.sun. This is because it is part of Sun’s implementation and not part of the Java specification. To become part of the specification requires a JSR and interaction with the JCP which are distinct and separate from OpenJDK. That’s the process that would result in java.net.httpserver (or, more likely, javax.net.httpserver because it’s not an essential part of the core).

I hope that clears things up. I’m really happy OpenJDK has found an interesting alternate use that clearly demonstrates the benefits of the FOSS implementation over the proprietary one, and thanks for blogging on this. Now you should go build IcedTea…

I read Mario and Roman’s posts this morning and they inspired me to post too, after realising that there was a lot of stuff that’s been going on that I also hadn’t blogged about. Firstly, Google Summer of Code closed its doors to student applications on Monday (well Tuesday really, here in Europe) and we were rather disappointed to find only two applications for GNU Classpath, both for java.util.Scanner. This is a real pity, as I think we had some really good ideas on the list (and even more interesting ones were left to one side after AICAS didn’t get in as a mentoring organisation).

I think students picked Scanner because it’s used on many undergraduate courses these days (something of which I was blissfully unaware, as it’s years since I did any introductory Java course or read an introductory book). Unfortunately, the future of such an idea is really dubious, as I explained to our first applicant online, as there is already an implementation (no idea how good or complete) by a student of Christian Thalinger (twisti) which we hope to get into the codebase, once the legalities are sorted out. Equally, we are looking at using BrandWeg to get the OpenJDK version; this has only really ground to a halt because I found we’d need to either update our regex implementation or also bring in the OpenJDK one and I simply haven’t had time. Again, BrandWeg was on the ideas list, but no takers

Personally, I’ve mainly been looking at IcedTea recently, in preparation for the OpenJDK challenge work. I haven’t really blogged on the details of this yet, but my first port of call will be to take an OpenJDK/IcedTea build and attempt to get the class library from that to work with one of our Free GNU Classpath VMs. Rather than trying to build the Sun interface into that VM, I want to use that process to figure out the best way to create a more well-documented VM interface including support for VMs that don’t want to go the native route for the VM interface. I intend this to be an interactive process so I’ll be posting results and hoping for feedback as we go along. As the OpenJDK challenge infrastructure gets sorted, I expect this will take place under the auspices of an OpenJDK project. I’ll be tagging appropriate blogs with the ‘VM interface’ category so feel free to track them.

One question that does spring to mind is whether the challenge projects are intended to work with OpenJDK or OpenJDK6. IcedTea work has pretty much shifted to OpenJDK6 (in the form of IcedTea6) with good reason; distros want to ship a stable Free equivalent to JDK6, not an early alpha of JDK7 (which doesn’t yet even have a JSR attached to it). Ideally, I think we should maintain both, as the IcedTea porting process seemed to suggest the differences weren’t too major. But feedback here would be welcomed. I’d also like to make the new VM work easy for others to test, so hopefully some integration with IcedTea will be possible there too. I’m very impressed with IcedTea so far, especially Gary’s zero port (as my previous blogs hopefully illustrate). There are some niggles, but lots of eyes and people testing it in different environments will fix these. It’s great to have OpenJDK on PPC64 for one thing!

To close, I notice that people are moving around in the Free Java world (as my reference to Mario’s title in mine hopefully indicates). First, Tom Marble left Sun earlier this year, and now we find that Dalibor has successfully stepped into his (hopefully clean) shoes. To me, there doesn’t seem to be a more appropriate replacement, though it does make his governance board position interesting… Mario has also now moved to AICAS, so it seems like most people are getting new jobs and different roles in the new Free Java world brought about by OpenJDK. Things will change for me as well soon, as I’m due to finish my PhD here in October (well the funding runs out at least, which means I need some alternate source of cash at any rate). So it will be interesting to see where I am in a year from now too…

Some good news on Wednesday:

IcedTea is served: openjdk/control/build/linux-i586

$ java -version
java version “1.6.0″
IcedTea Runtime Environment (build 1.6.0-b08)
OpenJDK Client VM (build 1.6.0-b08, mixed mode)

IcedTea is served: openjdk/control/build/linux-ppc64

$ java -version
java version “1.6.0″
IcedTea Runtime Environment (build 1.6.0-b08)
OpenJDK 64-Bit Core VM (build 1.6.0-b08, interpreted mode)

As an addendum to my previous blog, Debian Etch needs a backported Freetype to be able to build IcedTea. I’ve finally made my x86 backport available.

As those who’ve had the unfortunate luck of being in our IRC channel over the past few days will know, I’ve been trying to build IcedTea6 on our Debian etch server again. The good news is it looks like I may have succeeded this time, with some help from Christian Thalinger (twisti) and Gary Benson (gbenson).

Basically most of the tools that come with etch will be useless in your task. The versions of Kaffe, GCJ and GNU Classpath+JamVM that come with it don’t support the 1.5 language extensions. To add insult to injury, because the gcj backport used by Fedora is ‘4.1′, IcedTea won’t scream at you for a default ./configure; make. Instead, the OpenJDK sanity check will tell you that you don’t have a 1.6 VM to bootstrap with (although you only actually need a 1.5 one…). This is because IcedTea will symlink bootstrap/jdk1.6.0/bin/java to the gij that is part of etch, which reports itself as 1.4. Similarly, the jar file it picks up is a pre-generics version of Classpath that can’t be used even with a VM that claims to be 1.5.

So you need to build your own Classpath Java stack before proceeding with trying out IcedTea6. This machine is used to do my regression testing for Classpath so I already had an install of 0.97.1, but it’s simple enough to get a copy of GNU Classpath and a compatible VM if you don’t. You CAN use what is installed with etch to build this. The simplest way to do that is to install the java-gcj-compat-dev package which should give you a native version of ecj.

Using this, you can download Classpath 0.97 or any prior version up to 0.95 (the first to include the code merged from the generics branch). ./configure; make; make install should work, but you probably want to use --prefix to install it in a local directory rather than /usr/local/classpath. --disable-plugin is something I also usually add to avoid having to had the Mozilla headers.

Once installed, you need to add a 1.5 VM that works with this. CACAO (from the Mercurial repository), JamVM or the new Kaffe release should work. I used CACAO. You can then configure IcedTea6 by pointing it at the new install. Assuming $CLASSPATH is where you installed everything:


./configure --with-java=$CLASSPATH/bin/java --with-libgcj-jar=$CLASSPATH/share/classpath/glibj.zip --with-jar=$CLASSPATH/bin/gjar --with-rmic=$CLASSPATH/bin/grmic --with-javah=$CLASSPATH/bin/gjavah


Before building, you also need to patch glibc (thanks to twisti for this tip). Don’t worry! It’s not too scary, just a simple change to a shell script, to make it the same as in more recent versions. On x86, the change is in /usr/lib/libc.so. The last line should read:


GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED (/lib/ld-linux.so.2 ) )


If you’re on x86_64 or ppc64 (or any 64-bit platform i guess), you need to patch /usr/lib64/libc.so:


GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld64.so.1 )


That done, you should be able to run make and hopefully reach the message that IcedTea is served. YMMV of course, so let me know how you get on. This was quite a bit easier than when I last remember trying, so hats off to the IcedTea folks for all their hard work. Next stop, Solaris…

It’s that time of year again! This time, I’ll hopefully be mentoring some students instead, especially after my OpenJDK Challenge proposal was accepted.

If you’re a prospective student for SoC 2008 and would like to work on Free Java, then please come and join us on either:

• GNU Classpath (listed under the GNU Project mentoring organisation)
• JikesRVM

Want to find out more? Then mail classpath@gnu.org or hop into #classpath on FreeNode IRC (same network as #gsoc this year).

It was FOSDEM this weekend, and once again the Free Java hackers (now including many Sun employees) met up in Brussels to discuss the past, the present and the future. We had an extremely good turnout, better than last year (the only other year I’ve attended so far) and with nearly all the Free Java people there (notably MIA were Tom Tromey and Michael Koch). Tom Marble did a great job of encouraging everyone to give a talk, so, unlike last year, I think we heard from everyone working in the Free Java space. It certainly left me with plenty to think about.

Just before leaving for FOSDEM, I got 0.97 out of the door (or tried to — there were problems doing the upload again, but this should be sorted now for next time). In hindsight, this was a bad idea as I was then very tired for most of the trip and, in conjunction with having a bit of a cold, this meant I didn’t enjoy the weekend as much as I’d have liked. Anyway, the main point about the release was that it was supposed to represent that GNU Classpath was still around, even if not going strong, and not merely a dead carcass for people to pick the bones of. However, FOSDEM made me realise that we may be seeing the end of GNU Classpath sooner than I thought. With the planned BrandWeg hacking session on the Friday, that was initially going to be my main focus of the weekend, but from the talks it seems most people are further along the road to OpenJDK than I thought. Maybe the BrandWeg idea is coming about six months too late and we should have gone there around the same as IcedTea. As is, CACAO, JNode and IKVM.net are already using OpenJDK, and JamVM, Kaffe and JikesRVM all have their sights on going there too. There was unfortunately no real discussion of GCJ, so it may just be that, with RedHat’s focus on IcedTea, there will be no further development there at all, which is a shame. Overall, FOSDEM gave me the impression that our Free Java community now want OpenJDK and have grown out of their ‘toy’, GNU Classpath. I’d be interested to know if others think this is true too.

The most interesting talks for me, however, were those at the end where the TCK and the JCP was discussed. As Dalibor has mentioned in the past, I couldn’t help thinking we might have targeted the wrong opponent. While it’s nice to have the more stable, mature codebase of OpenJDK out in the open, when all is said and done, it’s just another implementation (and in some ways a competitor for Classpath, at least in terms of the attention of developers). The fundamental problem is the JCP, which still largely turns out proprietary TCKs and RIs (Doug Lea’s JSR166 being the notable exception to the norm). In the long term, a truly Free Java platform is not just about implementations but about the specification and an open process surrounding that. This is perhaps what has been the barrier to people getting involved in OpenJDK; because OpenJDK is largely an amalgam of reference implementations of JSRs, all FOSS hackers can do outside these JSRs is bugfixes which, while necessary, don’t set their hearts on fire. A true Free Java community can only really work with participation in open discussions that determine its future and with a Free Software TCK. I think Andrew Haley explained the benefits of the latter very eloquently in his talk, where he demonstrated how a number of annoying bugs in our code could have been spotted much earlier and easier had the TCK been available. Can we not separate the test suite from the certification process in some way, such that the tests can be developed in the open (and can thus be more readily trusted) and used by more than just licensees? Anyone want to join the JCP and make an impact?

In more technical news, not only is Classpath 0.97 out, but I successfully compiled it on Nevada (via a SunRay connection) this afternoon…