A fully 1.5 supporting Classpath gets closer…
We got some good news the other night — RMS approved using ecj as a driver for gcj. Once this goes ahead, we’ll have two compilers supporting building a Classpath with all the 1.5 language goodies, which means we’ll probably be able to merge the generics branch back to HEAD and have just one Classpath again…
Unfortunately, we will drop from three to two compilers in the process; it doesn’t look like Jikes will ever be updated to match 1.5. It’s pretty sad that basically only one Free compiler will support 1.5 (ecj, and ecj masquerading as gcj for the front-end part). Tom Tromey’s experiment with a new frontend, gcjx, is, to use his own words, ‘dead’. I guess the amount of extra stuff that got added in is just too much.
So, how soon will we now have a final merge of the two branches? We’re basically still waiting on gcj, although with the politics now sorted out, things look a lot more hopeful. If some basic support could be snuck in for 4.2, we could have support pretty soon (by the end of the year). If things keep going the way they are, we might just have 1.5 largely done by the time it gets to October and 1.6 appears.
In prospect of this merge, I’ve been trying to ease things a little this weekend, by getting most of the stuff that can go over on to HEAD. Unfortunately, it does mean there are a few files with some nasty hacks in and missing methods that will never be resolved until the merge occurs. The classes are still functional; I’m limiting it to stuff where a few minor removals or changes will get something workable on to the main branch, and where the changes that are made will show up in our JAPI results. Things will be much nicer though, when everything is one again.
June 5th, 2006 at 2:03 pm
I don’t understand why it is sad that there are so few free Java 1.5 compilers.
Why would fragmentation be a good thing in this case?
Multiple browsers, multiple window managers, multiple word processors, sure. In those cases, you can get diverse experience and experiment with new usage paradigms. But a compiler should always do the same thing, a straight translation from sourcecode to bytecode. And with Java the optimization passes aren’t even that important, since the JIT will do that at a later stage. Multiple java compilers simply means you split the resources into multiple projects.
June 17th, 2006 at 12:16 am
It’s not so much becoming ‘a few’, but one (as gcj will largely consist of wrapping ecj, with gcj just doing the native compilation, as I understand it). And how well a few compilers work depends on whether they fulfil the needs of those using them.
No doubt if there aren’t enough good Free compilers, the userbase will again respond with a new one.
ecj certainly has its faults. It has the benefit of being part of Eclipse, and thus receiving lots of developer attention. However, it’s a Java compiler written in Java (there’s an immediate chicken-egg situation there) which can be painfully slow. It takes something on the scale of Classpath to show this to an extreme.
A native version of ecj is usable, but still seems slower than Jikes (which seems to have met an untimely demise). ecj via a VM used to take forever to compile the generics branch, although this may partly be to do with the VM. That said, I can’t see a JIT doing much here as compiled bits don’t tend to be reused; most compilers (I don’t know the specifics of ecj) tend to consist of distinct stages of lexing, parsing, type checking and conversion into the end format (bytecode with JVMs). IMO, I don’t think Java is the best choice for a compiler; it stills has the same structural issues of a language like C++, but without any of the speed advantage. If you’ve ever seen the elegance of a compiler written in a functional language, you’ll know what I mean.
Jikes is an odd case; it obviously had the parser bits added for generics (in that it can understand e.g. List and warn that it is a 1.5 construct rather than spitting out the ‘<’). I’d be interested to know why development stopped. I’m sad mostly for gcjx; Tom put a lot of work in for something that’s never really been used, but I suppose it’s his choice.