GNU/Andrew’s Blog

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…

Well, this year is trotting along quite nicely so far and there have already been some quite interesting developments. Plus it’ll soon be time for FOSDEM again! Probably the most major thing for me is the continued development of OpenJDK-related projects. After a discussion with Dalibor via IRC a couple of weeks ago, we launched a new project called BrandWeg. This is effectively the inverse of IcedTea; we take Classpath and try to patch its holes using OpenJDK as the plaster.

It’s notably different as a repository in that it contains no source code, only patches. Instead, the build downloads Classpath from CVS or a tarball, and then the requisite OpenJDK sources from either Mercurial or a tarball. At the moment, it just merges in the jaxws stack, as this is completely unimplemented in Classpath and separated in the OpenJDK. As such, it seems like it should be easy to add this in by merely putting the sources into external and linking it into the build system. Unfortunately, the code may be in different repositories but they are by no means orthogonal unfortunately. Trying to build with jaxws in there makes the build scream for mercy — among the errors, there are ones looking for a HTTP provider in com.sun (presumably tucked away in the main JDK sources) and some evil direct use of the com.sun.org.apache XML providers. So it’ll need a bit of patching before we have our first BrandWeg build.

I’ve also returned to a little work on IcePick, after doko has started trying to build native GCJ binaries from its output. Together, we found and patched a few bugs and I’ve finally implemented better wrappers for the tools. Notably, these don’t depend on the -Xbootclasspath option which I picked up from the Classpath tools but which doesn’t work with gcj, and they also handle the -J options. The wrapper is now a little bit of C code that is compiled with different defines depending on the required tool.

Feel free to check these and let me know what you think.

Finally, the last bit of news concerns OpenJDK again. Through the last year or so that we’ve been working with the new OpenJDK development, our main contact with Sun has been through Tom Marble. He’s proved to be a great guy to work with, always patient enough to listen to all our quibbles and our ongoing complaints and whines about the glacial progress of the OpenJDK community development. So, it’s with some sadness that we found out this week that he’ll be leaving Sun soon and heading off for pastures new. I hope he appreciates how much of an asset he has been to us GNU Classpath developers in our trips into the unknown world of the OpenJDK and I’d like to join with the rest of the Free Java community in thanking him for his tireless work and wishing him all the best in the future. Thanks Tom!

Well it’s now 2008 (unless you’re in the US of course) and traditionally a time to reflect upon the year just gone. Well, it’s certainly been one of movement and change in the GNU Classpath community, if also one of very little code hacking. Of course, the biggest event of the year was the release of the OpenJDK source code in May; about 95% of the JDK source code base was made available under the GPLv2, the rest both then and now being filled by binary blobs, which are slowly decreasing in number.

However, back in January 2007, we were still waiting for this to happen. As I recall, we’d just (gone through the generics merge, migrating the contents of the branch on to the main tree and over the Christmas period I added quite a lot of 1.6 code. Sun’s javac compiler was open-sourced however, as part of the November announcement, and we soon had support in GNU Classpath for building with it.

In February, GNU Classpath was again at FOSDEM and I finally attended after missing out on the last two years. It was good fun and notable for our collaboration both with the DevJam folks and the OpenJDK community (AKA Sun). Everything was very much still ifs and buts however, because I don’t think anyone knew what would really happen when the floodgates opened and the JDK was released. Of course, GNU Classpath will again be at FOSDEM this year, and apparently with even closer collaboration with OpenJDK — try and even spot a mention of GNU Classpath on those pages… Hopefully, I’ll be there again too.

The year only saw two Classpath releases, which is sort of representative of its ongoing decline I guess. 0.95 was released shortly after FOSDEM in April, a delayed and very necessary release which include the generics move and the other stuff I mention above. Getting a GNU Classpath release out the door has become more and more of a struggle over this year and, in a way, has become synonymous with a pregnant mother giving birth, as a team of developers stand round screaming ‘push’ until eventually the release emerges. Our release of 0.96 in October certainly felt like that to me anyway. On that note, congratulations to both Michael Koch and Roman Kennke who both (or should I say, their respective partners) had children this year.

May of course saw the release of the OpenJDK source code and the inevitable hordes jumping on and pulling it about took place with the same speed and haste we saw on the release of javac. This has eventually surfaced in the form of IcedTea from a number of GNU Classpath/RedHat folks, a build framework for the OpenJDK which, most importantly, serves it without the need for proprietary code (given that the current OpenJDK build has no real advantage over a proprietary JDK drop unless you want to tinker). This was produced by splicing in bits of GNU Classpath code. It’s a whole deal more easier to use than plain old OpenJDK but still not a walk in the park. This is especially true since Sun split up the build process and made parts of it depend on Ant…

It’s quite sad to say, but OpenJDK is still not what we all hope it will be. Thankfully, live Mercurial repositories are now available as of December, but there are still too many walls, as I mentioned before. It’s like the JDK was something that popped out of a little black box, but now someone has taken the lid off the box so you can see the little worker ants running around inside and making it all happen. But there’s not yet anyway to get inside the box ourselves. New ants need to be able to join in the fun. We’ve already seen one of the goals I mentioned in August realised (the open repositories), and hopefully more will change in 2008. Sun’s innovation awards are both a realisation of this problem (common to both OpenJDK and many of its other open source projects, which still have a predominantly Sun ethos) and hopefully its saviour.

It smells a little like Google’s Summer of Code and indeed Tom Marble was asking myself and Mario about this on IRC. This year of course saw me tackling JikesRVM for GSoC, trying to implement the VM-level management extensions. A lot of this work was done, and following GSoC, I was made a member of the JikesRVM team. However, the patches still haven’t gone in to the mainline, due to a combination of the release process (some of these are likely to be destablising) and finding time myself to test the stuff on the main branch. This hasn’t been helped by a re-emerging problem with building JikesRVM using Classpath; this same problem plagued my initial month or so on the project when I discovered it seemed to rely on proprietary software to work…

So altogether it’s been an interesting year. Not only have I worked on both the old (continuing with GNU Classpath and also pushing out a release of GJDoc) and the new (launching the IcePick project to build the OpenJDK tools separately) over the last year, but I’ve also sadly seen the community enter something of a demise as people start to move on to other things, especially IcedTea and OpenJDK. What will 2008 hold? Maybe I’ll find myself working on OpenJDK too…

One of the things I’m currently working on is getting Classpath to a state where the java.lang.management stuff I’ve worked on becomes useful i.e. where we can attach to a VM either locally or remotely and get pretty graphs of things like memory usage via JConsole.

I’m tracking this via a couple of meta bugs. PR34277 represents our final goal of being able to monitor Classpath VMs and use Classpath to monitor other VMs, while PR34078 is looking at simply getting JConsole up and running on GNU Classpath. I’ve had some progress with this today. I’ve closed three bugs (two of them Swing/AWT ones which I’m quite chuffed about) and finally got some visible progress:

So far so good. The menus don’t work though (PR34581) and there’s also a problem once you click Connect (PR34582). The latter looks easy enough to solve (we just need to be checking for null!) and the menu thing is more of an annoyance than a blocker (the keyboard shortcuts on the menu items do work). However, I feel there is still a lot more to do before it works.

You can now grab your own IcePick and give it a whirl:

The website is:

http://fuseyism.com/hg/

where you can also grab tarballs. If you have Mercurial, all you have to do is:

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

and let me know how you get on

Update

Thanks to Mark Wielaard, this has also been available on the IcedTea machine since last week:

hg clone http://icedtea.classpath.org/hg/icepick

There is also a wiki page:

http://icedtea.classpath.org/wiki/IcePick

Happy hacking!

This afternoon I experimented with getting my early build stuff for the Java language tools to work with the langtools subset that Sun has created for the recent OpenJDK builds. This can be checked out from the experimental Mercurial repositories:

hg clone http://hg.openjdk.java.net/jdk7/jdk7/langtools/

You then point this IcePick stuff at that directory:

./autogen.sh
./configure –prefix=$HOME/build/fake_jdk –with-glibj-zip=$HOME/build/fake_jdk/jre/lib/rt.jar –with-langtools-src-dir=$HOME/sources/langtools

(The bootclasspath stuff, –with-glibj-zip, can probably go).

checking for ecj… /home/andrew/bin/ecj
checking for javac… /etc/java-config-2/current-system-vm/bin/javac
checking langtools sources… /home/andrew/sources/langtools
checking whether to enable maintainer-specific portions of Makefiles… no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating tools/apt
config.status: creating tools/javac
config.status: creating tools/javah
config.status: creating tools/javadoc
config.status: executing apt commands
config.status: executing javac commands
config.status: executing javah commands
config.status: executing javadoc commands

A make (in this case using ecj) will build the code, and then make install:

make install-am
make[1]: Entering directory `/home/andrew/projects/icepick’
make[2]: Entering directory `/home/andrew/projects/icepick’
test -z “/home/andrew/build/fake_jdk/bin” || /bin/mkdir -p “/home/andrew/build/fake_jdk/bin”
test -z “/home/andrew/build/fake_jdk/bin” || /bin/mkdir -p “/home/andrew/build/fake_jdk/bin”
/usr/bin/install -c ‘tools/apt’ ‘/home/andrew/build/fake_jdk/bin/apt’
/usr/bin/install -c ‘tools/javac’ ‘/home/andrew/build/fake_jdk/bin/javac’
/usr/bin/install -c ‘tools/javah’ ‘/home/andrew/build/fake_jdk/bin/javah’
/usr/bin/install -c ‘tools/javadoc’ ‘/home/andrew/build/fake_jdk/bin/javadoc’
test -z “/home/andrew/build/fake_jdk/lib” || /bin/mkdir -p “/home/andrew/build/fake_jdk/lib”
/usr/bin/install -c -m 644 ‘tools.jar’ ‘/home/andrew/build/fake_jdk/lib/tools.jar’

will install the jar file and some wrapper scripts to run javac, javadoc, javah and apt (I think javap is in the sources, so I need to add that too).
There’s still a lot of work to do to clean up the rather messy hacked together build and I need to integrate aot compiling from Dalibor’s Google Summer of Code work, but it’s looking promising.
I’ll try and make this available somewhere later tonight if anyone wants to play with it.

With any luck, Classpath 0.96 will be out tomorrow evening. Please get your patches in by 9am UTC tomorrow. Any testing would be much appreciated!