This week I proposed
killing gcjx and replacing it with the Eclipse compiler.
Per had looked into this before, but this proposal was triggered by a
comment that Andrew made on irc that same morning. I surprised
myself by taking to it with enthusiasm.

Since then I’ve done some more investigation. This project seems
very practical, and I think will let us have a 1.5 gcj much quicker.
There are a couple potential optimization regressions by going this
route, but these are fixable in the compiler without too much work.

I also spent a little time hacking on the eclipse compiler’s
driver, trying to get it in shape for an experiment to test this
plan. That turned out to be easy.

While doing this though I finally felt the sadness I knew would
eventually arrive. The trigger was something very minor — I was
looking at the eclipse compiler driver, and realized that on a lexical
level it is pretty ugly code. There aren’t many comments, and the
ones that are there aren’t very good; the class I was hacking on
didn’t have a very layout or even consistent indentation style. And
so I took a quick look at the corresponding code in gcjx… we’re
definitely losing something in this exchange. (But to be fair, the
driver is not exactly a core part of the compiler. I doubt it gets
much love.)

We’re not losing much though, and I still think this is the best
way forward. Plus, and this also surprised me, I seem to have gotten
whatever emotional fix I was looking for from writing gcjx. I started
it at a kind of professional local minima, and writing it helped
remind me that I’m reasonably competent at this programming thing.
Now I’m on to feeling inadequate at a higher level.

Future compilers

I think some aspects of gcjx should be emulated in all future GCC
front ends. For one thing, front ends should have their own
representation, derived from the language being compiled — they
should treat GCC trees as a target format, not a high-level
representation. Trees aren’t statically typed, and they carry too
much other baggage as well.

Second, front ends ought to be written as libraries. These days
it isn’t enough to write a traditional batch compiler — you really
want to look ahead a bit and consider IDE indexing, incremental
compilation, and other uses of the parser and semantic analyzer.

More recently I’ve been interested in applying this treatment to
the C++ compiler. Recently I’ve been surprising myself quite a bit; I
was never interested in C++ compilation at all until the last few
months.

I was looking around today and noticed that Frysk has a redesigned web page.
Looking good!

The “questions” page seems to be fleshed out a bit more, at least
as compared to what I remember. For one thing it is a lot clearer
about the relative strengths of frysk and gdb. Nice job guys.

Graydon pointed me at a
paper on context threading, a somewhat different way to organize
an interpreter. It is a nice trick — subroutine threading with a
twist, or a baby step toward JITting. It is a way to avoid trashing
the pipeline, which happens in an ordinary interpreter due to all the
unpredictable branching. Unfortunately I don’t think this would work
well for gij, due to the way we handle exceptions; a problem that also
affects most of the JITs we’ve considered embedding. Andrew has
talked occasionally of changing our exception handling approach, that
is looking more and more necessary.

Java Language Future

Here’s the
presentation on the future of the Java Language that I saw part of
while I was in Brazil. It is interesting for the most part. The XML
bits are fairly weird.

I downloaded and installed Chandler yesterday, and
copied over my (few) appointments to try it out. I only use evolution
for its calendar, and I’ve left it running as well so that I can more
easily compare the two side-by-side.

Chandler installed easily — the FC2 RPM installed without hitch
on my FC4 box. There’s no
.desktop file for it, so I ended up making one of my own… in
general its Gnome desktop integration is weak at the moment. The
install is big, but then they do package their own copy of Python in
there — a typical (and sane) ISV approach, but still a little
unfortunate.

Chandler is definitely prettier than evolution. It shows my
events in color with a nice (but by now almost standard) gradient
effect. The icon for Chandler is also beautiful, though again in a
somewhat standard way. You can see this stuff on the main Chandler
page.

Chandler does fix one evolution bug
that has bothered me. So far they are doing well on the little
details like these, especially when you consider that this is a pre-1.0
release. Also, they have been very responsive on my bug reports —
big plus to them!

It seems more memory-hungry than Evolution, that’s a minus.

I didn’t try any of the sharing stuff. Unfortunately for Chandler
my calendaring needs are quite modest at the moment.

I frequently wonder about the rationale behind writing Chandler.
It is nicer than Evolution in some ways, but surely not enough to
justify writing an entirely new application. Is it really about the
cross-platform-ness of it? As in, success looks like Mozilla, having
users across the platform spectrum? I haven’t found a really straight
answer to this, and I missed a chance to ask it directly at
OSCON.

Cosmo

The OSAF is also working on Cosmo,
a calendar server. This is an area I’ve never really looked into; I
seem to remember hearing a lot of complaints about the lack of this in
the past, but now there seem to be a few of these around. Maybe
someone out there knows what they are and how to compare them?

I’ve packaged Netx for FC5: x86
RPM, SRPM.
Thanks to Anthony this version will install itself as the handler for
JNLP files. WARNING: I’ve disabled the security code in this version,
so use at your own risk.

Install it and you will have a new javaws command.
Now you can try a couple fun things. First, listen to the radio:

javaws -headless -jnlp http://irate.sourceforge.net/webstart/stable/irate-client-swt.jnlp

(This one must be run headless due to an unusual
bug… either be patient while it downloads, or run it normally
and then kill it after the download and then re-run with
-headless.)

Then you can run a fun game:

javaws -jnlp http://rockz.co.uk/preview/plugin/rockz.jnlp

I’ve been playing this lately but I’m really bad at it.

Unfortunately netx doesn’t play too well with gcj 4.0.x, so this
package won’t really work on your FC4 box.

Duh, I just realized that I should just give out real JNLP links:
here’s iRate
Radio and Rockz. I
still haven’t tried this part, let me know if it works 🙂

I went through a number of the applications on the connect and work
site, trying them with netx and gij. Only a few really worked,
mostly due to bugs in our still-new swing implementation.

However, Rockz is a fun game
that actually works great.

Last night I made a netx RPM; I’ll post it once I dig up a rawhide
box to test it on.

NetBeans -vs- gcj

The NetBeans FAQ mentions
gcj. We must have officially arrived. Dalibor thinks we’ll run
NetBeans this year. I’m a bit less sure, simply because it uses a
number of internal APIs, which are occasionally a pain to work
around.

I ran across this absurd JNLP site
the other day. It has 2,927 web-startable applications on it.
I need to find a minion to test each one of these with gcj and netx.
Please email me to volunteer.

Voight-Kampff

Politically relevant Voight-Kampff test.

This white
paper explains why Java doesn’t have C#-style delegates. It
should be read with care; the “application footprint” section is
pretty bogus, contrasting the existing reality of delegates with a
hypothetical (but easily possible) future world where anonymous
classes have less metadata.

What I found most interesting about this paper, though, is its
bigger mistake. Much of its argument is actually quite reasonable.
However, it completely misunderstands the psychology of programming
language adoption by developers, and in particular of those developers
most likely to imprint on a language and argue (usually inanely) about
its details. People in this mode don’t want to hear reasons why not,
they want notational convenience. I’m there myself when I complain
about missing UI interconnects and missing Gnome features… I don’t
care about the cost, I just want the darn feature.

Usually languages handle this by using their bureaucracy to thwart
some kinds of additions — which is usually a good thing. Java is no
exception here, but the situation is somewhat unusual because C#
occupies such a similar niche but has a very different design
philosophy.

C++/CLI

I read a draft of the proposed ECMA C++/CLI language
specification. This thing is so bad that it is hard to know where to
start critiquing it. How about, context-sensitive keywords? Or, my
personal favorite, keywords with embedded whitespace? This latter is
scarily close to Dalibor’s joke that some future Java will have
keywords in color… “oops, you want the salmon ‘if’ there”.

(This will actually be an important development for two reasons. First it will allow the
long-promised but never-quite-actualized crossover between
programming and interior decoration. Second, it will give a new and
richer meaning to the traditional Emacs haiku:
M-x font-lock-mode:
Your buffers should resemble
Angry fruit salad)

But back to the subject… a language with both templates
and generics. Yeah! A language that adds “^” and “%”
operators to go alongside “*” and “&”! Rock! This language is
like an ordinary programming language that fell into a huge vat at a
chemical factory, and emerged as a supervillain. With tentacles,
laser beam eyes, and the ability to change sex at will.

Clearly, though, what we really need is Objective C++/CLI. That
way we can combine all the bad and overlapping features, all the
punctuation, and all the insanity into one nice package. Which we can
then detonate.

I saw that a new Chandler release came
out, and that reminded me of a missing interconnection.

I read a number of mailing lists via the excellent Gmane news gateway. This is great
because I can open a group and reply to a message.

Sometimes, though, I’ll run across a posting to some mailing list
via the list’s online archives. Replying to this is much harder —
really, absurdly hard. Mailing list archives ought to have associated
read-only imap servers, so I can drag a URL from Mozilla to my mailer
and have it magically start browsing the list in a reply-able way.

I suppose archives could add mailto: links all over. That would
work reasonably well for the particular case of replying.

Frysk remains a bit
opaque, unfortunately — there’s a steady stream of cvs commits but
little action on the mailing list and little marketing. That’s too
bad… sometime soon I’ll try to find out more about what is going on
and talk about it here.

One thing that did float by on the mailing list looked cool: scripting
frysk with python. (This is kind of old but I’ve been wanting to
mention it.)

More JNLP stuff

I thought this
hack was cute. Interconnection is awesome.