Classpath and micro-libgcj

Sun Jan 8 04:40:00 GMT 2006

Joel Dice wrote:
> 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?
>
You can simply use --with-glibj.zip option in classpath's configure to 
pass your own glibj.zip, which you are of course free to generate in 
whichever way works best for you. That's ideal for lightweight builds, 
where you purge all the unnecessary stuff from the class library, is 
pretty simple from the build system point of view, and does not require 
maintaining annotations, etc, in the Classpath tree.
> 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.
>
I don't think that's really a bad option for now.
Most of the work in GNU Classpath these days happens in areas that are 
not very interesting for something like mini-libgcj (which is afaict 
designed to be a java.io/lang subset), so I would not expect a lot of 
patches to have to be merged in manually. We've got syncing scripts in 
kaffe that almost automatically take care of the syncing now and we're 
working with the whole class library. Having done manual merges in the 
past, if your focus is only lang and io, I am sure you won't be spending 
a lot of time on syncing.
> 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?

I'd recommend option 3, as that's the easiest one ;)
cheers,
dalibor topic