gcjx can now parse
and analyze all 2016 files in libgcj. This is a major milestone!

I had already done some work on code generation. I think that is
where I’m going to focus my efforts for a little while, to try to get
the first class file written.

I rewrote model_field to be subclass of
model_variable_decl, to make certain cases of name
resolution work correctly. In particular there were some problems
with local classes in the previous scheme. Well, doing this
predictably broke nearly everything, so I spent today debugging and
now things are more or less back to where they were.

Two steps forward, one step back.

I really loved Super Troopers. I suppose I should be embarrassed
by this, but the fact is that I thought it was hilarious and it has
retained its hilarity for me over time. I still laugh out loud
watching it. So, I was eager to see Club Dread, another movie by the
same guys.

It was funny enough, and I did laugh out loud from time to time,
but unfortunately it didn’t live up to the standard of the previous
movie. I enjoyed it but I doubt I’ll be seeing it a second time.

It’s been a while since I last wrote here. In the meantime I’ve
been to FOSDEM, a very cool
experience. I met many of the Free Java hackers and had many
interesting conversations. In many ways it felt like I was with “my
people”, something that doesn’t happen too often.

gcjx is coming
along. It can now correctly parse and analyze
java.lang.Object. This is more impressive than it
sounds; in order to do this we must parse and analyze 426 other
classes as well. Yes, the Java class library is that
interconnected.

Yesterday Michael Koch pointed out some more bugs in gcjx though.
A crash, plus the test he tried, on my machine, shows a serious name
lookup bug. Whoops. At the moment I’m sort of fixing bugs with one
hand and writing new code with the other; my laptop has most of a
major change to make the bytecode generator actually compile. So,
we’re pretty close to getting our first .class file.