I’ve had a full week and didn’t manage to find a minute to write
about the Free Java Summit, which was about a week ago. I thought it
was fairly successful.

There were a number of good talks. For me the most interesting
ones were about the Jupiter VM and about JikesRVM,
which is really an excellent program (check out MMTk, a GC-building
toolkit).

Miguel was there and he talked about Mono, and after the talks
spoke a bit about the Mono debugger and other things. We did talk
briefly about the possibility of a completely shared runtime — one
that could run both Java and .NET bytecode, without needing any of the
hacks that IKVM needs — but the
general consensus seemed to be that there isn’t a real use case for
it. That’s too bad, it sounds like a fun project 🙂

The very best thing, though, was that Onno Kluyt was there. He
chairs the JCP and urged us to join. Whether this will happen remains
unclear — we need yet another pass through the legalese — but the
current plan is to have someone (Dalibor 🙂 join and see about
running the TCK against kaffe.

BC Merge

I merged the BC branch to the trunk this last week. This turned
into a horrible disaster. My testing failed to catch some
bootstrap-breaking bugs, I failed to cvs add a couple of files, we
broke ARM newlib yet again (this port is the canary for the most
trivial target port bugs). I spent most of the weekend hanging my
head in shame.

gcjx

Elliott Hughes wrote a lot of nice code for gcjx this weekend,
including adding internationalization support to the output
formatter. He also has a knack for finding bugs.

My recent gcjx hacking has been on attributes. I think all the
parsing and semantic analysis of attributes is working ok. gcjx still
doesn’t read them from class files, or write them. And we don’t
actually use them in the compiler, e.g. @Override doesn’t
do anything yet. Still, this is a big step forward.

The missing 1.5 bits for gcjx are: some work on enums, and
implementing generic methods. The latter looks simpler than I had
feared.

There’s been some talk about arch and
other VC systems lately. I’m not really too interested in going over
all the details via a blog entry; we should probably set up a
version-control-flame-fest mailing list or panel at some conference
for that sort of thing. But, I did want to put in a few good words
for monotone.

monotone is very friendly for “off-line” use, by which I mean
there’s actually no such thing as “on-line” use as there is with cvs.
You keep the subset of history that you want in a local database, and
all the ordinary user commands interact with this. You can sync this
database with other databases; I would suggest ordinarily just doing
this automatically via cron. Ordinarily it is simplest to just keep
all of history around.

A consequence of this approach is that you can commit at any time.
If two commits are made against the same base revision, a micro-branch
is made that you must then merge. This has some nice properties. For
instance, if someone sends you a patch against some release of your
package, you can just check out that release — no matter how long ago
that was — apply the patch directly, and then use the normal monotone
merge commands to merge the results with other changes.

Since monotone has all the other nice properties of the current
generation of free VC systems (atomic commits, cheap branches), and
since there is no enforced central server, it is trivial to do things
like have experimental branches, private branches for unfinished
patches, and the like.

You can do one better than that, though. With monotone you aren’t
required to accept any particular person’s changes, you can choose
keys to trust and keys not to trust. The way this would work is that
core maintainers would be generally trusted (you could have a
re-signing robot to automate this if you cared). Other people could
commit patches more or less freely, they just wouldn’t show up until a
core maintainer approved them. So, this would be a nice supporting
piece for the typical project, where non-core maintainers submit
patches for approval; it would eliminate the need to actually apply
such patches.

The other feature worthy of note, and the reason for monotone’s
name, is its support for testing. Monotone lets you attach some
metadata to a revision (using the normal signing process); then you
can use this metadata to change how “update” works. So, you can have
an automated tester sign
revisions that are known to work, and then only update to
known-working versions. For GCC, you could have multiple such
testers, with different acceptance criteria (works on x86 native,
works for ppc cross, etc).

Some of my Eclipse wish-list items got crossed off this week:

• As Anthony writes, you can download the the ChangeLog
  plugin. This plugin makes it much easier to hack on GNU Classpath
  in Eclipse.
• There’s now a bugzilla
  plugin for Eclipse. It is still a work-in-progress but at least
  seems to let you integrate queries into your workspace.
• GCJ Builder lets
  you compile projects with gcj.

Lives up to its name. I loved it.

Dave
Orme’s blog on Eclipse and gcj came at a funny time. We’ve really
solidified parts of gcj recently, so compiling SWT and Eclipse is
basically trivial now. Also, I recently made a list of
projects that would help integrate Eclipse better into the free
software world. I’ve been meaning to propose this as a theme for the
next round of Eclipse development, but haven’t quite figured out who
to send it to.

This week I’ve been working on the new gcj binary compatibility
code some more. This is looking pretty solid now, so I thought I’d
write a little tutorial on compiling a random Java application. If
you want to do this, you will need to check out the BC branch and
build it. We’re planning to merge all this into the trunk in time for
GCC 4.0.

The general approach is to make a small database that maps class
files (by hash code) to the shared library defining the class. This
approach doesn’t give the best possible performance, but it has the
advantage of working transparently with any application. If you’re
willing to modify your application a little (or if your application
just uses the standard class loaders like
URLClassLoader), then you can do a little better.

The branch has Andrew’s new jv-dbtool program
(probably will be renamed) which is used to manipulate the database.
First run it to create your database:

mkdir /libdir
jv-dbtool -n /libdir/eclipse.db

Now, compile each jar file using the new verifier (eventually this
will be the default) and the indirect dispatch code:

gcj -fnew-verifier -findirect-dispatch -fjni -fPIC -shared -o /libdir/foo.jar.so foo.jar

Update the database to know about the new jar:

jv-dbtool -a /libdir/eclipse.db foo.jar /libdir/foo.jar.so

Now you’re ready to launch your application. Run it using
gij, and arrange to set the system property
gnu.gcj.precompiled.db to point to your database (you
can use a number of databases separated by “:” if you like):

gij -Dgnu.gcj.precompiled.db=/libdir/eclipse.db My.Application.Class

That’s all there is to it! Your application will use the compiled
classes. You can debug your application with gdb, profile it with
oprofile, etc.