I liked Anthony’s post
about looking forward quite a bit. It is definitely time to be
thinking about the next big targets.

In particular I liked his approach of looking at existing programs
we can make work. So far this has worked quite well for us, and I
think it can continue to work well in the short term — it lets us
efficiently leverage our manpower into the greatest number of working
applications. (It would be great to be writing new gcj-using
applications, say using java-gnome, but the gcj hackers are probably
not the best bunch to be doing this. Plus which there simply aren’t
very many of us.)

There are a couple of things to think about here. First, are
these actually good additions to FC? I think there are two important
criteria for choosing a “target application” — what it provides to
users, and then how it helps us evolve our implementation. So we need
to talk to the desktop guys about this — throwing random applications
into the mix isn’t the best approach; instead we have to think about
how they fit into the desktop and OS offering as a whole. Azureus, I
think, is probably a good choice, but as for RSSOwl we probably need
to think more carefully. For instance, how does this tie into
something like Project Soylent?
(Assuming that project is even real. I have no clue what goes on in
the Gnome world any more; but this is exactly why we need to talk to
other projects.)

I think Anthony’s idea of working on security before the GUI makes
a lot of sense. In particular I think we’re more likely to see GUI
fixes from the community, whereas the security work seems to need a
dedicated effort to get through. I’m sure someone will tell me if I’m
overestimating the completeness of the AWT implementation.

In addition to Anthony’s goals, I think we ought to also implement
the 1.5 language features. These aren’t heavily used yet, but uptake
is beginning and it would be good if we weren’t completely behind the
times for a change. This isn’t a user-visible feature, but is an
important completeness and developer feature.

One other little thing I’d like us to ship is a JNLP
implementation, set up to make it trivial to launch programs from the
web. This requires minimal work on our part really, and seems like a
nice piece of infrastructure, to make deploying an application much
simpler for third parties.

Suppose for instance we decide that RSSowl is not a good match to
ship in FC. What is the advantage of packaging it in an RPM and
requiring root access to install it? Someone could simply ship a
.desktop file describing it and users would run it off the network.
We would provide a way to drag a launcher from a web page and drop it
on the panel, and that would suffice.

Today I looked into Java Web Start a little and tried out netx using gcj. The demo
program worked just fine, which surprised me a bit. For those not in
the know, Java Web Start is a simple way to download (and cache) and
run java applications. As I understand it, you write a little “.jnlp”
file describing the application, then there is a generic local
launcher that interprets these, and then downloads and executes the
bits.

I think this will end up working well as a side effect of the
security work that is needed for the Mozilla plugin. A couple nice
additional tweaks would be first, hacking netx to gcj-compile the jars
it caches, and second, packaging this nicely in the distro so that
jnlp links work in Mozilla, it is trivial to make jnlp-based desktop
launchers, etc. Neither of these seems very hard.

Our current idea for the next big gcj project is to make applets
work. Lately, however, my hacking has mostly been fixing bugs and
redoing the build system so that we can more easily merge with
Classpath — boring stuff.

So, last week when I happened across a java chess game applet at
the excellent chessgames.com, I
tried it out with gcjwebplugin. A
couple little bug fixes later (thanks Sven), and it is working fine.
(You can see from the screenshot that I’m running it via the applet
viewer, and not as a Mozilla plugin.)

The
game in the screenshot is old and beautiful and somewhat famous.
See if you can find the final move without looking at the move list.

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.

I read Freakonomics this week. This is a fairly entertaining
book, dealing with topics like the economics of crack dealing or baby
naming.

The Accidental Theorist

I also read The Accidental Theorist by Paul Krugman. This seems
to be just a collection of his columns from the mid 90s, so it isn’t
all that relevant today. There is some nice basic economics
background, though, and some good examples.

One thing I really didn’t get is, in his hot dog economy analogy,
why would we assume that if production increases, so will consumption?
I mean, it may, and it probably will initially — but eventually there
are only so many hot dogs you can eat. Or wear. Or make houses out
of. Not that this has any immediate bearing on what Krugman is
talking about.

Another interesting statement: “… in general when the economy
becomes extremely good at doing something, that activity becomes less
rather than more important”. The implication for programmers is
immediately obvious. First, thank goodness that the general state of
programming is really bad: inefficient, bug-inducing, difficult to
schedule well, and prone to outright project failure. Second, let’s
keep it that way — or, perhaps more appropriately, let’s hope that
the problems of programming are really intractable.

One problem that occurs when writing JNI code is that it is easy
to mistype a method name or signature, yielding errors only detectable
at runtime. Another problem is that if you change a class, you might
forget to update your JNI code, giving the same problem along a
different path. Neither of these problems can occur with CNI, and
last night it occurred to me that you could duplicate this in JNI with
just a little work.

The idea is to modify javah to generate slightly
different headers, and in particular to generate headers for the
classes you plan to reference from JNI. For each method or field in a
header, the new program would emit a define for the name and another
for the signature. Then JNI code would simply always use these new
defines.

The last step is to ensure that these headers are rebuilt whenever
the corresponding java classes change. Then you will either get
always-correct compilations of your JNI code, or, if the change was
incompatible, an error since the symbols used in your C code will not
be declared.