Classpath and micro-libgcj

Sat Jan 7 17:44:00 GMT 2006

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