gcjx status

[Tom Tromey <tromey at redhat dot com>]

Mark asked me to send a note to the list with an overview of current
gcjx status.

* Front End

  We can parse and analyze 1.4 code just fine.  There are some bugs
  (run against jacks to see) but so far they don't seem to be hit much
  by real code.

  There is one known parser bug for 1.5 -- with gcjx you can't
  intermix annotations and other modifiers.  (This is just a mistake
  on my part.)

  A lot of semantic analysis for 1.5 works.  With a few ugly hacks I
  can build the Classpath generics branch.  Many error checks still
  need to be written.  The simpler 1.5 features work ok, the problems
  are mostly with generics.

  We could benefit greatly from comprehensive jacks tests for all the
  new features.  Some small number of tests do exist.  At some point
  I will make a systematic effort to write more.

* Bytecode generator

  Aside from being slow gcjx is suitable for use as a 1.4 bytecode
  compiler today.  I don't know of any bugs in the 1.4 part of
  bytecode generation.  I've built Classpath and Mauve with it and run
  these with JamVM.  I've also built Classpath with the
  verify-after-bytecode-creation flag, with good results.  (So, it
  could benefit from heavier testing.)

  Much of the code needed for 1.5-style bytecode generation has been
  written.  We still don't generate bridge methods, but I have been
  looking at that recently.  The code to write enums, annotations,
  etc, exists but is largely untested.

* Tree back end.

  We can compile simple programs to object code and run them.  My test
  cases have been the little programs in testsuite/libjava.lang.  I've
  done this by building against a known-good libgcj.so, I haven't yet
  gotten a purely-gcjx-built libgcj to work.  Compiling from .class
  does not work.  I haven't done any work on 1.5 stuff here.  I forget
  whether I've tested BC ABI compilation or not.

* Merge requirements.

  To merge I think gcjx needs to do what the current gcj does at least
  as well.  Most of the needed work is in the tree back end, but also
  the parsing performance problem must be addressed, and the
  replacement for jcf-dump must be merged in.  After a couple more
  generics-related tweaks I plan to focus on the tree back end.

Tom