There’s been planning internally at Red Hat for a while to host a
Free Java Summit. This is a reality now, it will be happening
November 18 and 19 in Boston. The agenda is still in a state of flux,
but I gather one of the main focuses will be promoting better
cooperation, unity, and information sharing in the free java space.

The summit is invitation-only, but I was told that community types
are welcome — so if you are a free java hacker or fellow traveler,
and you want to come, let me know and I will pass the information to
the list-keepers. I probably can’t say much about the attendee list
at the moment, but it will be a good cross-section of academia,
industry, and the free software community.

Eclipse Plugins

Today Red
Hat released a couple new Eclipse plugins — one for RPM hacking
and one for using OProfile from inside Eclipse. This is some cool
stuff.

Movie Editing

From time to time, Anthony and I work on a
movie editor. It is between names at the moment, so no nice tag line,
but we do have a
first screenshot (looks like I broke thumbnail generation in this
one, bleah).

The first thing you’ll notice is that it is an Eclipse plugin.
While almost everyone I’ve talked to agrees that this is a crazy idea,
to me it makes a lot of sense, as Eclipse provides a lot of nice
facilities. We get to write in a high level language, and Eclipse
provides a lot of core support for writing applications — the kind of
things I had hoped, back in the day, that libgnomeui would provide.

It seems to me that editing a movie isn’t too different from
developing a program, and Eclipse makes it very easy for us to exploit
this. E.g., we already have CVS integration, and media files, which
you probably wouldn’t store in CVS, are easily handled as linked
resources. As another example, if you wrote an effects plugin, you
could easily have your movie project depend on the plugin, so that a
complete rebuild would first build the effect, then the movie would
apply it. This could all be done inside Eclipse — changes to the
effect would cause the movie to be re-rendered.

More on the state of this, and our plans, and justifications for
and benefits of using Eclipse, later. If you’ve got a good idea for a
name, that isn’t cutesy, send it my way :-). Maybe I’ll also post a
bit about our long search for an appropriate media framework — or
maybe I can get Anthony to write about that.

I downloaded Croquet today to give
it a try. This didn’t work out very well, but I’m still optimistic
about this project. For one thing, this eliminates my need for a
gdb/irc interface, by adding collaboration to the whole desktop. The
screen shots look super-cool, the 3D-ness makes me immediately think
that lack of screen real estate won’t be a problem again.

I really find this project inspiring — it has reawakened some of
my interest in GUI hacking, which has long been dormant. I’d love to
see this ship as the default UI in, say, FC5 :-).

gcjx

We’re probably going to fork Jacks,
though nobody will know about it since my email never makes it to the
list. I’ve written a few simple tests for new language features and
put them in my own private copy. I did a little bug fixing in gcjx,
too. On the tree front, I wrote an article about writing GCC front
ends, the thesis of which is that it is way easier than you have
heard. More on that later.

Telling the gcc world about gcjx, so far, has been a painless
process. I’ll be making my branch sometime pretty soon, maybe this
week.

In the meantime I made boxing, unboxing, varargs, and static
import work. That means that all the easy additions to the language
are working. Now on to fix up the harder things. I got a burst of
energy for this since Mark pointed me at a non-click-through way to
see the JLS3 (complete with change bars).

The algorithm for handling generic methods is several pages of
notation, it reads like a math text. One wonders if this isn’t
overkill.

LLVM

Some day, if I’m super motivated, I’ll hook gcjx up to LLVM. Well, maybe someone else
will. I’m actually more interested in LLVM’s potential to provide a
JIT for libgcj. That seems stalled on exception handling (the problem
child) at the moment, but hopefully someday someone will implement the
small piece of infrastructure we need.

License Harmony

The whole gcjx effort would probably not be needed at all if we
had better license harmony. Instead we would just share efforts with
some other free java compiler. This situation is pretty lame. I
suppose we could have worked around it by having a little driver that
runs a different compiler and feeds the resulting class files to gcj;
but that feels too much like intentional GPL circumvention for my
taste.

Of course, now that I’ve sunk a year’s worth of spare time hacking
into this, I find I don’t really want us to reach license
harmony.

Nevertheless, I see this as one of two major issues facing free
software, with the other being patents. Patents are an external
threat, a way that companies intent on protecting their antiquated
business models can (with luck temporarily) defeat us.

Lack of license harmony is more of an internal threat, balkanizing
the community: putting up barriers to code sharing and communication,
and creating software stacks that ought to interoperate but cannot do
so efficiently.

An interesting documentary about the Al Jazeera network.
Trenchant yet, for my taste, a bit jumpy. The political observations
in it have circulated on the US left for quite a while, so it wasn’t
surprising, but nevertheless it managed to be moving. Squeamish as I
am, I had to close my eyes a couple of times. The personal
observations were quite well done, reminiscent in a small way of The
Sorrow and the Pity.

Yesterday I got my first .s file from gcjx. This
means that enough gcc integration exists to avoid crashing, and that a
fair chunk of the tree lowering pass exists. I wrote a letter about
making a new gcc branch, now I just have to make myself actually send
it…

Eclipse 3

Today I got Eclipse 3 to start up using the “BC branch”
interpreter. Now to try compiling bits of it.

Tonight I turned gcjx into a shared library and hacked on the tree
back end enough to make it link. You have to go through some build
hackery to make this work for yourself — I suggest waiting for the
gcc branch. That should be coming a lot sooner than I thought.

My goal is to get gcjx fully working (to 1.4) and in the gcc tree
by its one year anniversary, December 1. Today this looks completely
possible, given that it is already better than gcj in most
respects.

This week was fairly scattered, I ended up doing a little bit all
over. Work was mostly bug fixing, or in some cases just bashing up
against regressions all over. We never have quite enough testing or
quite enough time to look at little problems as they crop up. And of
course the test suite doesn’t include big things like Eclipse 3 that
stress many things at once.

GDirect

I added a renaming feature to GDirect this week. Now it is pretty
easy to control the mapping of a Java method name to the underlying
native function name. There is an interface for renaming, and a
couple useful built-in renamers. So, for instance, now you can have a
Java-style method name like “setFocusOnClick” and have it call the C
function “gtk_button_set_focus_on_click”.

Currently I’m thinking of wrapping object-oriented C APIs (e.g.,
gtk) by having these classes derive from a Pointer class that supplies
the implicit “this”. There are several plausible approaches, but this
one is simple and fairly easy to understand.

gcjx

I had taken a small hiatus from gcjx, but I’ve been working on it
more lately. Mostly I’m working on lowering to the GCC tree
representation. Really that is largely there and I’m really doing
some cleanup work and writing some of the needed glue — building all
the right decls, hooking in to gcc’s command line processing, stuff
like that. None of this stuff compiles.

I’m planning to relicense gcjx to the LGPL. This will let me do
things like use it from ant via dlopen(). I’ll have to rewrite a few
little bits that come from the old gcj. The tree-lowering code will
remain GPL, since it links directly into gcc.

Once I get it actually able to compile a java program to trees
without crashing, I think I’ll try to get it into the gcc repository
on a branch. Currently I’m thinking most of gcjx would go in a new
top-level directory (like libcpp), with just the tree-lowering and
glue code in the gcc directory.

Writing a GCC front end

Once you understand trees (there are some intro manuals
around, a couple nice examples
— hint: don’t read gcj or g++, and as a last resort tree.def),
you might be wondering how to hook your front end to GCC. This part
was intimidating me a bit; I was afraid I’d have to dig through gcj to
figure it out.

I started doing this, but a simpler way is to read langhooks.h.
This provides a decent, though imperfect, overview of what a front is
either required to do or can easily override. It doesn’t mention
things like build_common_tree_nodes, and I’m sure other
stuff I have yet to figure out, but it is still pretty helpful.

Last night I watched the presidential debate on TV. Kerry did
pretty well. He seemed fairly collected, and, despite weird
pre-reports, did not sweat excessively. (It’s ridiculous that this
was even a topic of conversation.) In any case it was pretty clear
that he’d prepared pretty well, he handled the tough questions (the 87
billion dollar question) without cracking. It was what I would
expect, pretty much… I’ve read that you can’t really win the debates
so much as you can lose them, and Kerry definitely didn’t do that.

Bush on the other hand seemed rather petulant. There was one
moment where he spoke directly to the camera very powerfully, and I
thought that he had a real chance to nail this debate. But then he
performed poorly the whole second half, just repeating himself and
looking and acting as if he’d really rather be somewhere else. It was
sort of sad to hear him mention Poland’s contributions to the war a
couple of times. I kept thinking he would roll out his plan to woo
Panama back.

This evening I spent a little time hacking on GDirect. No new
features, but now it is purely JNI based. This means it is portable
to any JVM that uses JNI (i.e., basically all of them). I even tested
this theory using both gij and the BEA JDK. Eventually I’ll probably
add some gcj support to make it work more efficiently there, but that
is lower priority than a few needed features. If you’re interested
you can find it in the gcjx cvsroot on sourceforge.

I did some research today into alternatives to GDirect. Time to
do a little more hacking on it, I suppose.

I’ve been talking to the NativeCall guys for a
little while, hoping to convince them to take a more GDirect-like
route. Their approach is more like Java reflection: construct an
object representing a native call, then use an invoke
method on that object to actually call it. This is a nice idea,
complementary to GDirect’s current approach; I’ll probably add it at
some point. Unfortunately they’re taking the wrong direction
implementation-wise, writing custom inline assembly for each kind of
method call. This will never scale. By way of contrast, even in its
half-baked state GDirect already works on 11 architectures for any
combination of (primitive) arguments and return types. Also, the
reflection-like approach is great when you need to call a native
function in a fairly dynamic way; but GDirect’s current approach is
superior when you want to wrap a native API. Both are probably
needed.

Noodle
Glue sounds really great but, as far as I can tell, is not open
yet. (There are a couple other proprietary libraries in this space
too, like we care.)

JNIDirect is basically a
free version of the non-free inspiration for GDirect. Reading through
the white paper indicates that it has some functionality I hadn’t
thought up yet, so that’s cool. It seems to be Apple-specific, so
that isn’t very interesting.

Jace looks
more like a library to make JNI friendlier. Basically it lets you
write something like CNI that is portable across VMs. That’s pretty
cool (though not exactly what I’m looking for). It would probably be
worthwhile exploring how to make CNI and Jace source compatible.