A couple of remarkable things happened while I was working on the above. First, my wife got curious about what I was trying to fix and how I planned to fix it and pretty soon I found myself walking my wife through the parsing bits of the GCJ front end, including the Java grammar! She and my sister then left for a movie that I was not at all keen to watch, so I spent that time at home hacking on GCJ - that resulted in four and half hours of continuous hacking that was masochistically exhilarating, helped of course by the fact that I was actually able to find a satisfactory solution at the end of it. Such hacking binges are sadly so rare now, but used to be so frequent during my undergraduate days. ~sigh~ :-( Anyway, I found out that the GCJ front-end is not such a mess after all - there's a method to the madness, as they say, but it requires a bit of patience and perseverance to understand. Of course, to use another cliché, I have just seen the tip of the iceberg - who knows what horrors lurk as I try to delve deeper into the front end? Anyone wishing to understand the front end should definitely try out Alexandre Oliva's debugx to step through the code using a debugger like GDB to see how it works. Inside a debugger, GCC's cool debug_tree() function can be used to examine a TREE node. The GNU Coding Standards make it very easy to search for the implementation of a function in a file (ESC/^foobar in vi, for example). The function java_parse_file() in the file "java/jcf-parse.c" provides the "big picture" for the front end.