Last night I packaged BBDB for Fedora. I submitted it to Extras. I’ve also got most of a package for ERC ready. Let me know if you want either one, I will make them available somewhere.

Roman writes disparagingly of proposals to add properties to Java.

Properties seemed cool when I first heard about them. They seem like a nice tool for maintaining source compatibility — for allowing local refactorings between fields and methods, without requiring massive changes to the rest of the code. In gcjx, I used something a bit like properties (I think you can emulate them in C++, with some work, but I picked something a bit simpler) for just this reason.

But upon further reflection I don’t really see the point of adding them to Java. Java is more concerned with binary compatibility. And, for properties to be binary compatible, they have to be implemented as functions from the beginning (or as a new VM feature — but that seems like overkill). And if you are doing that, you might as well consider that your IDE can generate the methods for you already.

Regardless of what happens here, I think it is interesting that the Java language debates have moved to the blogs. There are several influential Java people blogging about these topics on a regular basis. We’re also starting to see language experimentation being done in the OpenJDK javac.

Both Andrew Cowie and Behdad wrote recently about spell-checking comments in code. I thought it would be worth pointing out that Emacs can do this for you while you type. Try M-x flyspell-prog-mode. I enable this in various hooks so that is on by default when I’m hacking C, Java, Python, etc.

I’ve been reading about Gnome 3.0 lately and I’ve run across some interesting links.

I thought the lazuli mockups looked quite nice. One problem I see in Gnome is that many programs feel quite heavy — e.g., I use evolution only for its calendar, and it seems like an awful lot of UI for something that is conceptually much less important. Programs should have a UI presence about equal to their general importance in my daily life; I only “calendar” occasionally. So, my calendar ought to be invisible most of the time (evo does this well), and quite minimal when I do pull it up (evo fails here). The lazuli screenshots seem to capture this idea pretty well.

This site is sort of a bumptop-y thing written in flash. It is pretty fun to play with. If you click on one link in this post, click on this one.

Gimmie looks pretty cool.

I’m including a link to the Mozilla desktop only because it exists. Mostly I think focusing on the implementation technology is a mistake. Users don’t care — I know I sure don’t. Working on multiple platforms is nice, too, and I can see how that would be useful, but doesn’t fit into my reality.

On the calendaring front, wuja looks like an interesting idea. I’m not a huge fan of web-only software; wuja bridges the gap in a nice way.

On September 12 I’ll be in Fort Collins, at the NCLUG meeting, giving a talk about Autoconf, Automake, and Libtool.

I haven’t been involved in the auto-tools for quite a while, but I still know enough to give a tutorial :-). I gave a similar talk at the Boulder LUG a while back (a few years now); I’ll dig up those slides and also probably take some thing from Alexandre Duret-Lutz… but if you will be there and there are particular things you want me to cover, post a comment.

I’m in Toronto this week, visiting the office and talking with co-workers. It is as great here as always; I love the occasional visit to a big city, riding the subway, etc — doing the kinds of things you can’t do in Boulder. Seeing folks face-to-face occasionally is also very helpful for my morale; brainstorming and discussing what we’re doing is energizing.
Someone posted a link to the bumptop video on Mugshot today. I’m always entranced by these gee-whiz desktop ideas. This one is no different, I loved watching the video and then I made Andrew Overholt watch it too. Unfortunately he pointed out that if you watch it you may notice what you don’t see: any actual use of an application. And, it is pretty hard to see how this would improve my productivity at all. For one thing I barely even use Nautilus, so improvements to abstract document manipulation are not likely to do much for me.

I also read The Six Dumbest Ideas in Computer Security recently. This is interesting and easy to read. I often think that the most important frontier in programming is reliability, which is similar to his points about designing in security. Unfortunately this area isn’t sexy enough, so language and platform designers tend to focus on productivity and ease of hacking, rather than ease of getting things right. Java, IMO, started off with a nice reliability boost over C, but these days it is also headed down a bad road, what with AOP (which I really dislike) and the forthcoming XML-in-the-language thing.

I’ve been looking at moving my blog to something less lame —
right now I can’t blog while I’m traveling, which is why I still
haven’t written about my trip to the Red Hat Summit. I’ve also been
looking at other software for creating web sites.

While exploring I ran across the Open Source CMS site.
This site lets you play with many different CMS, blog, photo gallery,
etc, installations, so you can try them out before committing to one.

So far my experiences with these programs haven’t been very
positive. I’ll write more about that later.

I’ve been working steadily on replacing gcj’s front end with the
Java compiler from Eclipse. This is largely working now. I have a
new main program for the Eclipse compiler, and I have gcc set up to
invoke this (via the magic of gcc specs — an evil little ad hoc
scripting language that you should hope you never have to learn).

The new driver is a little funny. When ecj compiles a file, it
writes the classes to a jar which gcj compiles. This way we don’t
have to have an arbitrary number of temporary files for communication,
e.g. for all the inner classes. This takes advantage of java’s
built-in ability to make jars, and gcj’s existing ability to compile a
jar file all at one. I thought this was amusing, anyway… maybe I’ve
been working too much.

I thought this would be very simple, but I should have realized
that this would reveal every bizarre class file compilation bug in
gcj, some of which can only be seen if you are compiling the core
class library this way. For example, the bytecode verifier needed a
special case to handle the constructor in Object.

In any case, I can now build all of libgcj this way. I’m
debugging a few runtime failures now.

LLVM-based JIT

Aside from the whole exception handling mess — which experts more
expert than I are, hopefully, busily hacking on — the JIT seems to be
working reasonably well. I’m just about ready to clean up the API and
check it in (as an experimental preview), I don’t think any more
changes in that area will be needed in the near future.

There are still a few lurking code generation bugs. Nothing too
hard, just mishandling jsr a little.

I recently added the first bits of recompilation to the JIT. Now
it will realize when it resolves a constant pool entry, and mark the
method as ready for re-jitting. The idea here is that before linking,
a constant pool reference requires a method call to incrementally link
the class, whereas after linking, a constant pool reference is simply
a constant. Another similar optimization is that when we initialize a
class, we mark the method as ready for re-jitting — the code to lower
from bytecode to LLVM will check a class’ state and avoid emitting
initialization calls as needed.

This still hasn’t seen much testing. And, to really do a good job
here we have to add profiling code of some kind. I really need to
read the literature here. If only there were time.

In Classpath we’ve narrowly avoided most of the team-related
Eclipse problems Daniel
Berrange mentions encountering.

Partly this has been because we’re all mad free software hackers,
and so we don’t even try to ensure we all have the same tools.
Instead folks doing development in Eclipse have a choice of operating
systems and of virtual machines (both jamvm and cacao work nicely in
this environment).

Over time Eclipse has gotten better at separating the personal
from the project — Eclipse 3 is much better than Eclipse 2 was here
(e.g. now you can store the coding style for the formatter in the
project). And, we do make an effort to set things up so that typical
uses won’t require any changes to the project metadata; that both
avoids unpleasant accidents and lets people in different environments
continue to get sane results. Partly we’re able to do this because we
have an unusual hybrid build which includes autoconf (this isn’t
without its bad qualities as well).

We put a fair amount of effort into making our setup turnkey.
There’s a
nice web page on the wiki which explains, step-by-step, how to get
set up for working on Classpath. This is still a lot harder than we’d
like, but it can be done in thirty minutes or so if you’re already
familiar with Eclipse. I demoed this at FOSDEM this year; most of the
time during the demo was spent waiting for the build (Classpath is
over a million lines of code, so that can be forgiven). In real life
you also spend some time waiting for the network — my demo was with a
local cvs server.

Also, supposedly team sets help a bit here. As I understand it a
team set is a way to specify a group of projects to check out. My
brief experiment here was a little un-promising; I think it picked the
wrong user for CVS repositories by default (I was hoping it would know
that when I used “anonymous”, I wanted the end user not to have to
specify a username). Someone in the Classpath community (I forgot
who, sorry) did make a team set but then it never ended up on the
wiki… (ping).

As a user you do have to watch out a bit. I once installed the
FindBugs plugin, and then to my dismay found out that it modified the
project builders. This is unacceptable; I had to remove the plugin to
avoid accidentally contaminating the shared build. (Any plugin
architecture suffers from problems like this, though. Allowing
plugins means giving up centralized quality control.)

For what it’s worth, our “initial setup” problems with Eclipse
haven’t been much better or worse than the problems we’ve had with
shell-based builds. Eclipse could definitely improve here. (Once
you’re set up, of course, the difference is startling.)

Ideally Speaking

My ideal setup for these things would involve more integration
between Eclipse, the OS, and the organization.

It would be nice if a project could specify required plugins; when
checking out the project Eclipse would first launch the update manager
to install them. In this ideal world, the update manager would work
with RPM rather than stand perpendicular to it.

It would also be very nice to have rendezvous support or the like;
the idea being that in a typical organization you would simply launch
Eclipse and not have to figure out where the version control server
lies. In the free world an analog would be the ability to click a
link in Mozilla and have the repository automatically show up in
Eclipse. Every project’s home page would have a big “Hack Me” button
which you would click to get a working development tree. Or, you
could have Eclipse interface to irc and pick up on repositories and
update sites that way… join #classpath, get a dialog asking if you
want to access the classpath team set.

This latter idea gets to something that bothers me about
programming. Computers are powerful communication devices, and a huge
part of our jobs entails using them to communicate. However, much of
this communication happens at two extremes — there is the extremely
unstructured form like email or irc; and there is the overly
structured form, like a cvs commit. I’m hoping for a generation of
tools that is a bit more loose; tools that notice interesting things
without too much interaction or attention on my part; and also tools
that let me more easily wire up communication the way I need it (my
perennial example here is the amount of time I would’ve saved over the
years if only we could simply drive the debugger over irc).

There’s some work in this area. Eclipse has ECF, NetBeans has its
thing, whatever it is called. There’s also the Jazz project for
Eclipse, from IBM. This isn’t open source (it may be someday), but I
hear the demo is quite cool. It sounds a little too
command-and-control for my taste, perhaps, but I’d imagine it can be
made a little more peer-oriented.

Naturally, none of this is available on the timescale I want,
namely last week.