My fiddling with OpenJDK

It might sound strange coming from someone who wrote a post titled The Java t..crap but I’m liking playing with OpenJDK.

Not like my Java skills (pretty much non-existant, I used it only a few times in my life) are improved, but I find myself comfortable when working with most build systems, after you get scons out of the way (note that I didn’t say I like it, but I can do it just fine), and I do have experience with adding support for external libraries, after all, and that is something that OpenJDK might need.

So, let’s start from the start. The first problem was getting to build OpenJDK on Linux. If you try to build it on AMD64 you’ll see it fails, the reason for this is that the list of files to compile on hotspot is too long for the maximum size of arguments available on Linux; this in turn is caused by the long default path for sources that Portage sets. Petteri was able to build it fine because on x86 the architecture name is i486, while on AMD64 is, well, amd64: the extra character there is enough to make it burn in flames. Kelly O’Hair from Sun is looking after the issue now, but he says it might take a few weeks to get the results out; not a problem, I suppose, in the mean time you might want to try changing PORTAGE_TMPDIR to use /tmp for openjdk (if you have space in the /tmp partition) or you might want to fool the ebuild by renaming the openjdk directory inside $WORKDIR to something shorter, like “ojdk”; actually, a single character less will work just fine.

After getting a working build of OpenJDK, and trying so that it worked fine on Konqueror (it does!), I had to start messing with it, or I wouldn’t have been myself 😉 The first thing was to get it to build with my flags correctly; I was able to get something that worked, but there are a few issues, and I’d like to be able to provide a less invasive patch. O’Hair also got me on the right track now, by telling that hotspot and j2se build systems are different, which might call for just using the same method on boths, by ignoring the default C (XX)FLAGS values coming from environment, and instead use the _OTHER variables. This should allow for just four lines changed, if I find where to put the CFLAGS/CXXFLAGS unset.

After this I started thinking of an useful hack to do to at least understand how the build system works; I could have looked at fixing a few warnings, but I thought it would have been more useful to actually start by looking at the build system, that is what I will need to understand to be able to get OpenJDK building on FreeBSD. I’ve seen zlib-1.1.3 sources in the tree, so I decided to find a way to build against external zlib. Easy, quick, interesting and useful.

Why useful? Well, first of all, it would use a more stable version of zlib, and would share its code with the rest of the system (almost every process has a zlib copy loaded one way or another), second of all that would make it non-vulnerable by possible attacks on the zlib code. Unfortunately adding the support for external zlib was not as easy as I thought, but it was mostly because I stupidly forgot FEATURES=keepwork on the environment (I wanted to get the object files output, as I want to see if the executable stack problems that affects Java are due to the architecture, or just a problem of not having the GNU stack markings on the source files).

And while looking at fixing this, and seeing a tempnam() warning at linking stage, I ended up finding a tiny memory leak, as the string coming from tempnam() is never freed. I’ve prepared a patch and sent it, hopefully to the right mailing list.

Other hacks that might be useful would be finding a way to enable or disable ALSA and Motif bindings building, to reduce the size of the final output, and to avoid depending on those to build openjdk, but I wonder if Sun would ever accept such changes.

When I’ll be comfortable enough with both build system and development environment, I’ll see to start working on building OpenJDK on FreeBSD; for what I can read on the build system mailing list, it should be possible, for now, to build OpenJDK using a JDK 1.5, which is available for Gentoo/FreeBSD, even if the best thing would be using 1.6. Probably I’ll have to provide a openjdk-bin package for Gentoo/FreeBSD to use as a seed, afterward.. this of course if the license allows to do this (most of OpenJDK is GPL-2, but there are some binary blobs still present, until they are replaced, it might not be possible to redistribute the binary itself).

Unfortunately a big problem I have to face while hacking at this is that I don’t have any Solaris/OpenSolaris installation, and I suppose that Sun will accept more willingly contributions that don’t break their main target platform 🙂

Now, of course, the reasons I have to find this project interesting and to revert my attitude toward Java are not limited to the simple GPL-2 licensing. What I find more attractive, and makes me hope I’m not mistaken on my judgement, is that now it would be possible to support more hardware platforms, making Java a true platform agnostic language (okay, Kaffe help a bit with this, but the results are not really at the same level), and will also allow to support more operating systems. And with more users’ contributions, it will probably also get better optimisations (hey we got guys like FFmpeg devs who are able to optimise the hell out of multimedia codecs, someone might find useful things to improve on OpenJDK too!).

For what concerns Gentoo/FreeBSD, for sure FreeBSD guys have already some build definitions to support FreeBSD; the problem of those are that are likely not GPL-2 as it is, as they were designed for previous JDK versions, so I’d rather not even look at them to avoid legal issues. The assembler code would likely be the same between Linux and FreeBSD, with the same architecture; for SPARC, the code might be just taken out of the Solaris assembler sources, at least on i486, the assembler between Linux and Solaris doesn’t change besides from a few minor places, and the main issue there is the difference in the assembler program used, and thus in the syntax.

Let’s try to make Java a truly Free platform, and allow it to run on as many system as possible, then it might replace Flash and beat the heck out of Silverlight; Sun seems to be in the right mind set… so waste no time!