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).