Wed 30 May 2007
Posted by gnu_andrew under Jikes RVM
, OpenJDKNo Comments
I’ve been away for pretty much all of last week, attending a UK GRADSchool in Bournemouth, so there’s not been much action on the Free Java front. However, SoC officially started for real on the bank holiday (28th), so expect things to heat up from here on in. I’m still chewing over the JikesRVM build process, which managed to stall my machine the other night!
The good news is that the apt problem looks to be resolved. I’ve succeeded in splitting out javac and apt from the OpenJDK (although actually the javac is still the separate one from earlier, as I was having problems with the newer version) and can now build them using some autoconf jiggery-pokery. Which means I now have an apt ‘binary’ or actually a shell script that invokes cacao with the appropriate com.sun.tools.apt.Main wizardry. Probably should try creating a native binary with gcj at some point as well. Unless I missed it, JikesRVM is yet to hit this in the build process, but it is building the appropriate classes now, having found them in my little fake tools.jar. So things are looking brighter.
Hopefully some actual dev work soon…
Mon 14 May 2007
So I’ve been playing around with the OpenJDK source code drop over the last week, in addition to still trying to build JikesRVM and doing odd bits of gjdoc maintainer stuff (Michael Koch is packaging the newest version for Debian). Unfortunately, I’ve not yet managed to build it without the binary blobs, which I don’t want to even have to download (in the belief that if I do that, I may as well just download a proprietary JDK). The build system relies heavily on an existing JDK and a lot of environment variables… oddly makes me miss the autotools!
My discoveries so far have lead me to find that the full build (hotspot+the j2se classes) won’t build without an existing tools.jar, of which Classpath does not have a full implementation (it wants com.sun.jdi, whatever that is). Of course, this stuff is in the tree as well (but the hotspot build doesn’t seem to know that). Hacking things to make hotspot use these classes lead to the revelation that it actually wants an older version; it tries to do a 1.4 compile, while the versions in the tree use 1.5 features such as generics.
Giving up on Hotspot and trying a j2se_only build gave more interesting results (seeing the build pull out bits of Classpath, believing them to be from the Sun JDK was fun), but again stalled because it wanted a libjvm.so from Hotspot. Assuming that it would be more difficult to remove this dependency than those in the full build (as I guess the classes are closely tied to Hotspot as their VM), I went back to that and tried to pull out the tools so they can be built separately. This has other uses, in so far as it would, for one, give me an apt I could use to build JikesRVM Javadoc and appletviewer also seem to be in there. I’ve since been plodding through a dependency hell which sees me slowly pulling more and more of the JDK into my newly created ‘tools’ directory. javax.script, javax.xml.bind and some management code are an example of the larger stuff it needs that Classpath doesn’t yet have.
This also gave me a patch for Classpath (fixing the RMI classes to use generics so rmic could build) and I have had apt at least give me its help output. More troubling is that I can’t find some stuff — ‘Version’ and ‘JDWP’ classes seem to be proving elusive. If anyone can shed any light on that, it would be much appreciated. In the meantime, hopefully the CP teams ‘iced tea’ plans will come to fruition and we can work on the code while the legal guys sort out a wonderful shared community between OpenJDK and Classpath.
Wed 9 May 2007
As expected, JavaOne was the venue for yesterday’s announcement that the JDK class library source code is now available. Unfortunately, it is still heavily encumbered. About 60 megabytes of binary blobs are emitting a rather nasty smell. Seems like the next task for us freedom fighters is to at least try and build it without these dependencies and with a Free environment (not the proprietary JDK). It was nice to hear of people building it early and getting ebuilds out (well done Betelgeuse), but for me doing so in a Free environment will be the real result. I can safely assume that Sun has already built it themselves with the JDK (including itself presumably).
The hard work is now to come as Sun has to forge a community around this. A good start was made with the governance board, which includes our own Kaffe maestro, Dalibor Topic (congrats to him). The thing is Sun will now have to change their usual attitude towards the JDK in order to best work with the community. I doubt long turnarounds on patches which have to be approved internally by Sun will find much favour with the majority of FOSS hackers. The best thing about working on GNU Classpath has been the vibrant, happy and fun community that has been built around it, formed from a diverse group of folks with their one goal of a full Free Java implementation. Of course, this has still not been achieved, there is still work to be done and I hope that the new OpenJDK project can harness some of the enthusiasm and vigour that has been the epitome of our community.
Tue 8 May 2007
So I finally got some time to hack some Classpath code again this bank holiday weekend, and ended up feeling like I got nowhere, running into bugs and annoying problems at each turn.
Me and JikesRVM are still fighting; I haven’t had a successful build as yet. After working round the apt problem (by moving the offending files out the way and commenting out the build rule, hehe), I proceeded to watch it download ecj (after having ignored my native version earlier). This ran into problems, which I later found were down to my own stupidity. I hadn’t installed the optional ant tasks as required. That fixed, I ran into a fun issue with its Classpath download. It decided to try and ungzip it twice, so tar complained and stopped the build. Something is being clever along the way and decompressing the gzip before it reaches tar I guess.
That fixed (by again hacking the build files), I realised that the file Ian kindly gave me (the one generated by the apt tool) had got mangled in downloading. Leastways, it didn’t look like any Java file I’d ever seen before. To cap it all, I then updated and that broke the build even earlier. Hopefully, that will be fixed soon.
Returning to Classpath itself, I noticed that the Mauve runs were coming up with a ridiculous number of errors, so decided to investigate. Updating, I found I couldn’t even build. The new gtkpeer.c file wonderfully assumes that the system is 32-bit. Good job I have -Werror on or I would be experiencing some nice random segfaults next time I use the GUI stuff. A couple of #ifdefs later and it was fixed.
I then proceeding to uncover the root of the test problems — there had to be some common problem, given that it was a fairly mixed bunch of tests. Turns out the build was no longer including the locale information. I’m quite amazed no-one had spotted this earlier. It was soon fixed by correcting the new find invocation in lib/Makefile.am.
So all in all, didn’t get very far but at least thinks seem to work again…