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.