GCC 3.4 is coming out soon. I think this will, unfortunately, be
the worst gcj release in quite a while. Basically no one worked on
looking at bugs, and it turns out there are some dumb ones in there —
but now it is too late in the release cycle to fix them.

More generally nobody is working on fixing gcj bugs, and gcj is
really in pretty bad shape. Bugzilla doesn’t tell the whole story
here, since nobody has had the time or the heart to file all the Jacks
failures as bugs.

Today I’m depressed about it, probably leakage from other parts
of my life and the fact that I didn’t really sleep last night. I’m
sure tomorrow it won’t affect me quite as much.

McNealy

McNealy says
that Sun won’t open source their Java implementation. No surprise
there — did anyone really expect them to?

Equally dumb is his comment “We’re trying to understand what
problem does it solve that is not already solved”. How about letting
people fix bugs that affect them? How about letting people port to
new platforms? Both of these have come up for me in the last year.
How about growing a community to drive the technology forward faster?
How about sharing development costs among all Java stakeholders,
instead of footing the whole bill yourself?

These reasons and more are why we work to build free systems.

libgcj future

Various Classpath hackers have been pushing the idea of unifying
Classpath even further, perhaps to the point of doing Classpath
releases and having VMs use it unmodified. This is pretty
interesting, I think.

The logical next step is to just erase the different VMs and
decide on a single one. We could put it directly into Classpath.
The fact is, at least for C-based Unix-y VMs, there really isn’t much
difference outside the execution engines. These we could comfortably
leave separate, perhaps following the pluggable JIT talks at FOSDEM.

As Mark points out, libgcj remains the problem child in these
discussions, stubbornly sticking to, as he puts it,
micro-optimizations we’re proud of. In most cases this isn’t far off
the mark.

Lately I’ve been wondering a bit if we should just treat the
standard library like we plan to treat any other Java application.
That is, make the precompiled runtime the bare minimum to bootstrap,
then load the standard library using our binary-compatible shared
library cache.

This has several advantages. First, we could work with a standard
Classpath, at least if we resolved a few issues (placement of native
methods in some cases). Some classes we still couldn’t, or wouldn’t
want to, merge, but that is no big deal — these would just be loaded
by the bootstrap loader and the Classpath versions would be
ignored.

This would let us debug more easily, since we could just point gij
at Classpath. We could even completely decouple libgcj from gcc,
which I’m sure would make many gcc maintainers happy.

Don’t get your hopes up on this actually happening. I’m just
brainstorming.