Classpath and micro-libgcj

[Joel Dice <dicej at mailsnare dot net>]

First, thanks to everyone for their feedback re: micro-libgcj.  I'm 
excited by the prospect of merging it into the GCC repository now that 
it's clear how widely useful it would be.

Before I propose a plan for executing this merge, I'd like to understand 
exactly how it will relate to the ongoing GNU Classpath merge.  I 
apologize if the answer to the following question is documented 
somewhere; if so, I haven't found it:

  Is the ultimate goal of the Classpath merge to use Classpath as the 
upstream source, such that future releases of will GCJ contain an 
unmodified distribution of Classpath, plus some GCJ-specific classes (ex. 
java.lang.VMClassLoader)?

If the answer is "yes", we have (at least) three options:

  1a. Try to convince the GNU Classpath team that they should accept a 
patch that adds support for a lightweight build, based on some sort of 
preprocessing scheme.  Considering that Classpath is now being used by 
many projects, this seems like a tough sell.  Is it likely to succeed?

  1b. If the above succeeds, we do a three-way merge on the core classes 
used by micro-libgcj (a subset of java.lang.*).  Thus, for each class we 
combine the libgcj, micro-libgcj, and Classpath versions into one 
preprocessed version and submit a patch to Classpath.  I'll definitely 
need some help with this :).

  2. Maintain a seperate tree containing the micro-libgcj classpath, where 
bugfixes and improvements from libgcj and Classpath will have to be 
continuously merged by hand.

  3. Start with option 2, wait until the libgcj/Classpath merge is 
complete (at least as far as java.lang.*), and then do option 1, 
simplified by the fact that there are two branches to merge instead of 
three.

I prefer option 3, since it seems to be easiest in both the short term and 
the long term.  Any thoughts?

 - Joel