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.