While writing gcjx, I’ve come to think that our current language
choices are really too weak for a programming task like this. For
most of the work, C++ does just fine, but I’ve run into a couple of
situations where a different approach would be notably better.

First, consider generating synthetic methods. Java compilers have
to do this in a few situations, the most simple one being an implicit
constructor. This involves creating a constructor, setting its return
type and some other attributes, creating a block, adding a
super call to the block, and then adding the block to the
constructor. In all this is about 30 lines of code, which isn’t too
bad in this particular case — but in a lisp-like language, this could
be done much more simply with a single backquoted expression.

Second, suppose you want to add a warning like “warn if
a binary operator on the right hand side of an assignment uses a
narrower type than the assignment itself”. This lets you catch bugs
like double = int / int. In this case, you’d really
like a language that makes tree-matching very easy, say something
with unification.

In both these cases C++ doesn’t fit the bill, and there’s no nice
way that I know of to add the needed syntactic support. I could use
lisp, of course, but then I’m sacrificing static typing. I’m not a
language wonk, though, probably there’s some language out there that
does everything and I just need someone to tell me what it is. Not
that I’ll switch 🙂

It was a sort of random week, where I did little bits of things
all over. I’m switching projects here, from Eclipse back to gcj, and
this week was a kind of transition period.

I haven’t been hacking gcjx much lately. It’s been sort of hard
to keep my morale up for it. However, Dalibor gave me
some motivation to run Mauve through gcjx. That
found a couple of easily-fixed bugs. I ran the resulting Mauve and it
seemed to do ok — no verification errors, so it looks like code
generation is in good shape for the most part.

A
bunch
of
C++
bootstrap
patches went into GCC recently. This is great news for gcjx since it
means I basically don’t have to do any GCC hacking to hook up gcjx.
So, I spent a little time on this, but not really enough. It does
now compile without error, but it doesn’t link yet.

As I’ve mentioned before, writing a GCC front end is basically
easy now. The documentation situation is still a bit unfortunate
though. I’ll probably write something longer about my experience
writing a front end from scratch once I’m a bit further along gluing
gcjx to the middle end, basically a document showing exactly how easy
it is to write your own compiler nowadays.

I also made
a generics branch for Classpath this week, and genericized a
pretty good part of the library (as well as added some other stuff
needed for full 1.5 support). Without this code there is really no
way to test all the new language features in gcjx — in Java, unlike
C++, the compiler has some knowledge of the standard class libraries.
For instance gcjx, at present, knows about 34 different classes in the
standard library.

The C++ wisdom is that this sort of dependency is a mistake. That
is probably true for some uses, but this approach does make it easier
to add language features that interact well with the library. For
instance, I don’t think you could add a nice foreach
construct to C++ without this. (You can do it with macros or with
function-like objects, but neither of those is really “nice”.) As it
is, gcjx is littered with needlessly verbose code using STL iterators.

This morning I did a little GDirect
hacking. It now actually compiles and a short example program works.
I checked it in to the gcjx repository,
since that was convenient for me. It is in the “gdirect” module if
you want to take a look.

I think the next step will probably be developing a way to
represent native pointers in GDirect. Most likely I’ll do this by
boxing and unboxing pointer arguments somehow. Offer suggestions if
you like, my ideas in this area are pretty vague at the moment.
Earlier I was just going to use RawData, but I find I’m
more interested in cross-VM portability than I was before.

Also on the table is the idea of having a notion of classes that
wrap some native object. This would let us wrap non-static methods in
a natural way.

So, there was another “should Sun free
Java?” debate, this time at OSCon. Once again, as far as I can
tell, no one actually working on a free Java implementation was
actually invited. Sigh. I tried to get Red Hat to send me, but
getting that to happen is like pushing peas uphill.

Reading the summary, it sounds like all the familiar arguments on
both sides. Ho hum.

Here’s a somewhat
interesting, but flawed anti-freeing-Java post. I’ve got some
replies to it; quotes in italics are his:

• Well, you can already download the source and fix a bug if you
  want to. You can even submit the fix to Sun. Yeah, that’s true.
  Of course, you can’t actually do anything else with that fix of yours;
  the license doesn’t come close to meeting the OSD. And, now you’re
  tainted by Sun’s obnoxious license, so you can’t help out on a free
  Java implementation. Plus, in practice we’ve seen that Sun is not
  always very good about even properly understanding bug reports, let
  alone replying to them intelligently. Critics will say that free
  software projects are also all over the map on responsiveness to bug
  reports, but high-quality projects like gcc are much better than Sun
  in this regard.
• Open sourcing would mean we’d have even more people bickering
  about trivial issues. Yeah, this is a price of openness. Some
  bickering, and really on most projects this doesn’t dominate
  communications, is worth it to have real openness.
• I think that Java would be fine without Sun. It’s a language,
  carefully spec’d out, with multiple implementations from many
  organizations, some with billions of dollars. False.
  First, if Sun goes under, someone will buy up all that IP — it isn’t
  just going to float around out there. It could very well end up in
  the hands of someone who wants to kill Java. Second, the
  specifications are spotty. Some parts are really good (the JLS),
  some less good (the JVMSpec), and some aren’t really “specifications”
  but rather “programmer documentation”, which is ok but not really
  suitable for writing a replacement — the class libraries all fall
  into this category. For some libraries the situation is even worse.
  Third, as far as I’m aware, there is only one Swing implementation in
  existence anywhere, the one Sun owns. So, contrary to what he says,
  I believe IBM does not have its own complete Java implementation.
• So now we can see that opensourcing Java doesn’t solve
  anything. Sure it does. Open sourcing Java
  almost immediately puts a lot more software into Debian. That’s
  “something”. Second, it helps align the free software community as
  allies of Java against MS. Third, it might help breathe some life into
  Java on the desktop.

That was basically the same old stuff, just with different words.
At least he didn’t take the familiar and bogus approach of accusing
all free software people of being Evil Communist GPL Zealots.

Wouldn’t it be interesting if, just once, a keep-Java-closed
advocate were to actually talk to and ask questions of someone
actually involved with working on a free Java implementation? There
are lots of us out here, mostly friendly.

I started doing some work on a free JDWP
implementation yesterday, but today on a whim I looked, and it turns
out there is a complete
implementation of it in Eclipse already, complete with
com.sun.jdi and a test suite, rewritten from scratch by
IBM. That’s great news since it means debugging gcj-built programs
with Eclipse is one big step closer — basically just hooking this
code up to the gdb/MI wrapper that is also in Eclipse.

Every episode of the A-Team had a sequence where the team would
spend their time welding, examining sheet metal and rolling 55 gallon
drums around. This scene was filler to work around the general lack
of content to the plot. This technique extends well past the A-Team,
though, and it isn’t hard to find A-Team sequences in many TV shows
and films once you know what you are looking for. It is a hallmark of
a certain style of bad movie.

Last week I got my first real gcjx patch from someone else —
Ranjit implemented reading of zip and jar files. That’s a big step
toward gcjx looking more like a real compiler.

I’ve been busy too. I wrote the parts of inner class support that
were missing, and as a result we’re down to 378 Jacks failures (pretty
good really). gcjx can compile the Eclipse java compiler and generate
code that mostly passes the bytecode verifier. So, code generation is
also in good shape.

I re-started work on the pass to lower to the gcc tree
representation. It all compiles now, except for a couple of C++
incompatibilities in the gcc header files. Luckily, this is being
worked on even as I write. Of course just having this code compile
means nothing; there are lots of stubs in there and things that just
abort. This is just a normal part of the development style I’ve used
for all of gcjx: write a lot of code that doesn’t even compile, then
make it compile, then make it work. So on to stage 3…

Once I can get it actually compiling and not completely bogus, I
am going to move to a branch of the main gcc repository. Any
maintainer can make a branch, so I’m going to take advantage of that.
Hopefully nobody will mind when I add a bunch of new directories.

Last night on a whim I looked at enum support again.
These turn out to be pretty simple — for the most part they are just
syntactic sugar for fields and anonymous classes. I had already
written the parsing parts of this, so I wrote most of the semantic
analysis as well. All that remains, I think, are some minor error
checks and changing switch to allow enum expressions.
Now if only we had a 1.5-ish class library so I could test this
stuff.

I wrote a pretty good piece of definite assignment, and gcjx is
down to around 400 Jacks failures. There is some tricky code in
Jacks, here’s my current favorite example:

        void foo() {
            final int v;
            new T165a3(v = 1) {
                int i = v;
            };
        }

What’s tricky about this is that a compiler has to insert a dummy
parameter to the anonymous class constructor to capture the final
variable (unless the compiler is smart enough to see that this value
is already being passed in — which few are). If the compiler
inserts this variable at the start of the argument list, it will
generate invalid code.

gcjx was mentioned on
the gcc list this week. Of course, this happened in the context
of a C++ language flame war. Perhaps, as Ranjit
suggests, it will be harder to get gcjx into gcc than I previously
thought.

I’m still hopeful. I’m about ready to switch away from
Jacks-related hacking and back to other things. First will be a small
reorganization, then some class file reading fixes, and finally back
to work on lowering to gcc trees. Once tree lowering works, I think
I’ll move the source onto a branch in the gcc repository.

C++

So, why C++ for gcjx? Basically, I didn’t think the other gcc
maintainers would accept Java. Plus, using Java would mean a pretty
uncomfortable bootstrap — something that will be difficult enough
using C++ (since we’ll have to build libstdc++ and then go back and
build gcj).

There were a lot of arguments in the gcc thread about the various
problems with C++. Everybody has their own list of features they
hate. MI seems universally disliked, along with operator overloading,
but some folks were against templates, exceptions, and Dewar even
apparently dislikes virtual functions. gcjx uses all these features,
but purposely avoids something no one mentioned, namely statically
initialized objects.

As was pointed out several times, accepting C++ doesn’t mean
accepting the worst kind of spaghetti code that can be written in C++.
Egregious misuses, obscure operator overloading, etc, can be simply
rejected, and probably would be, just as we reject bogus C
constructs.

I like to think I made tasteful use of all these things in gcjx,
but I suppose I’ll get a different opinion at merge time.

Bill Gates

As said on slashdot, Bill Gates thinks that open source kills
jobs. It is sad to see capitalists not understand their own system.
In capitalism, Bill, if a product can be made efficiently by some
other means, old modes of production will simply die. The theory says
that this is painful for those displaced but good overall since it
frees people to work on other things. I don’t always agree that this
is the proper set of tradeoffs for us to make as a society, but then
I’m not a famous capitalist either.

There’s been a lot of interesting gcj and free Java work lately.

Tom Fitzsimmons has
made
Slime
Volleyball
work
in gcjwebplugin. That’s an important milestone for AWT work.

Anthony Green has made a new ant task to make it
easy to create native shared libraries from your Java code. He also
got
Eclipse 3 running using gij, though at the moment this still
requires a couple ugly hacks.

To Do List

Mark Wielaard ran gjdoc over Classpath recently and made some
online docs. This process is still much too slow and error prone —
Tom Fitzsimmons points out that there are about 40 javadoc
command-line options that gjdoc still doesn’t support. We really
need someone to get this moving along so that we can generate
documentation nightly.

Brian Jones had the excellent
idea that Mauve and JAPI should be linked so that we can see not
only API coverage but also API correctness. Yet another item for the
to-do list.

gcjx

This weekend I fixed a bunch of jacks-related bugs. I rewrote and
cleaned up access control, fixed a little parser bug, and did a few
other things. gcjx is down to 609 jacks failures, which is excellent
— better than gcj and I still haven’t written definite assignment.

gcjx code generation still needs some work. I wrote a little
script to try to load all the .class files generated by a jacks run.
This found a number of code generation bugs, via verifier failures.

Anyway, gcjx is pretty close to being actually useful for java
hacking. I’m hoping to be able to replace the gcj front end this
year; that seems like an achievable goal. This would mean replacing
it with no regressions (except perhaps in gcc bootstrap time), only
improvements and new features.

I’ve been running gcjx through Jacks
lately. This is an excellent test suite — basically they went
through the JLS and turned each constraint into a test (or sometimes
several).

At this point I’ve got gcjx down to about 800 failures, which
isn’t so bad considering its immaturity and that about one third of
these are tests for a module I haven’t written yet (definite
assignment).