There's been a lot of fuss about Project Harmony this week, not to mention renewed efforts in the Gnome language wars, OO.o madness, and the like.
"Harmony" is a funny name for a project, not only because of the name's historical Qt connection, but also due to the Orwellian requirement of always naming in opposition to true meaning. I'm just making a joke here; the truth is that while Harmony is, as one might expect, showing us the various fault lines in our community, it also does provide a reasonable promise of achieving its namesake goal.
So what is it? Right, nobody knows what it is yet, because that is the Apache approach. If you're coming from a different hacker culture this will probably seem completely alien. My impression is that the Apaches are much more formal than most of the big umbrella projects out there, and a sub-project like this starts with an open discussion about directions and goals before moving on.
I think the Harmony project offers some great things to the free java efforts. At the moment, from my point perspective, they are mostly "soft" things -- increased awareness, better PR, and insider access to the JCP and the TCK. Also coming along with this is a concrete example of cooperation between the FSF and the ASF.
In addition to the license harmonization rant I usually give at this point, there is another point about convergence in the free software stack. One of the big benefits of a technology like Java is not a specific language feature, but rather that it lifts the common denominator so that old dreams, like universal use of libraries and shared code, become reality. So, for instance, you find Eclipse using Lucene and Tomcat, ostensibly "server" technologies; and it turns out to be trivial to do.
So, hopefully Harmony can show us the way forward in terms of unifying some of these divergent communities. The more we can share efforts, and concrete realize we're largely working on the same bigger goals, the stronger we are.
On the PR front alone this project is already a success.Whither and dye
I would like to take some time out here to explain the whys and wherefores of some of the work we've been doing.
There is a lot of Java code out there. There is Eclipse, which is not only a huge IDE, but also a bunch of other things besides (like a future video editor). There's also all the Apache code, jonas, OO.o, etc.
Those of us hacking on gcj have put our energy into making these applications work. This seems fairly obviously useful, as it lets us ship them on free platforms.
(Oh, by the way, you should read Planet Eclipse.)
Currently we -- and by this I mean the very small group of us who work on gcj at Red Hat -- are thinking we'll tackle a Mozilla plugin next. That will entail making the security model work, and making AWT more solid. But, this is just the current idea. You can influence this plan.Tofu Frying
Uraeus thinks that we don't publicize our Java work enough, but I think the problem is that we haven't put much effort into making inroads into other development communities like Gnome or KDE. That has turned out to be a mistake on our part, at least insofar as use of gcj on the desktop is concerned. Maybe I should have stayed a Gnome developer all those years ago.
As far as the multilingual thing, appearances may be against java, but I think Sun has always had some interest in this. There's a Groovy JSR, as I remember, and I thought I heard that Sun funded Groovy to some degree. Also I recently found out that Jython is not actually dead.gcj, the irrelevant menace
Miguel makes a number of claims about free java implementations. Some of it is true -- Sun's free beer strategy is a notable winner, and other companies wanting to successfully fight against free software should take note. The rest of it, well...Into the Fray
Seth is pretty much correct about the language differences, I think. Personally I am a checked exception person, but I can see why someone would prefer the other.
As for integration to native code... of course, gcj rocks here. You just write C++ code. Or, you can use GDirect if you want to go that route. The technology for all this kind of thing is just floating out there, waiting to be used. You can use libffi for simple things like this. Or if you are into something heavier, try LLVM.
Seth is mistaken about the 1.5 language, though. The Eclipse compiler already supports it. gcjx, the front end rewrite, is coming along nicely. Classpath has a generics branch where much of the new work has been done; in particular, all the collections classes are now generic. There is still more to do, but this is one of my major goals to accomplish this year.
There is a good question lurking about, which is why Red Hat Gnome hackers haven't been gung-ho for gcj. I'm not really sure why this is; I live out in the distant hinterlands, and I don't really have the sort of daily contacts with these guys that are so beneficial to, umm, brainwashing. But surely it can't be anything we've done :-).Oh, oh, oh
I've seen several references to the FSF announcement about OO.o and free java implementations (though the new, less insane, version is now up). I've also seen a few references to the supposed community anguish over the shocking news that Sun would put java code into their office suite.
Time to get a grip folks -- slashdot is not always right. Caolan has it all under control.