micro-libgcj merge reconsidered

[Joel Dice <dicej at mailsnare dot net>]

Hi all.

Thanks to everyone who contributed to the discussion following my proposal 
last Friday.

Reading through that discussion, I found that there are two major 
concerns.  The first is that micro-libgcj does not adhere to any existing 
standard, nor does it provide any well-defined criteria to determine what 
features it should or shouldn't have.  It has a guiding principle 
("smaller is better"), but everyone has his or her own idea of how that is 
best achieved.

The second concern is that the cost of maintaining the Java source files 
will be high whether we maintain them seperately from the J2SE-targeted 
classpath or maintain a unified tree with preprocessing.

In light of both of these concerns, I think the advice of Steph 
Meslin-Weber and others is most appropriate - create a branch for 
micro-libgcj as proposed, but without intending to merge it into the 
trunk.  Others may then use that branch as a basis for their own branches 
and take them in whatever directions they care to.  Elements from any of 
these branches may then be merged back into the trunk if and when there is 
demand for them.

How does that sound?

 - Joel