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.