RFC: micro-libgcj merge proposal

[Tom Tromey]

>>>>> "Joel" == Joel Dice <dicej@mailsnare.net> writes:

Joel> Plan
Joel> 0. Get write access to the GCC repository.
Joel> 1. Create a micro-libgcj branch in the repository.
Joel> 2. Do the merge on that branch.
Joel> 3. Document new build options.
 [ ... ]

I think we can separate this part of the plan from the merge-ability
part.  And, IMO this part is fine.


I do have some comments about the other part, which would affect the
eventual merge.

Joel>      --[enable|disable]-micro-libgcj
Joel>      --[enable|disable]-micro-synchronization

Joel> * Add preprocessor directives to various native source files (*.cc) under
Joel>    the libjava directory of the following forms:

Maintainability is the big issue here.

For J2SE we know when a given change is ok.  We have the spec (such as
it is :-), test cases, applications, JAPI, etc, to guide us.  But for
micro-libgcj, what is the guide?  Possible problem cases are: we
refactor native code, how do we know where to move #ifdefs?  We add
methods, do they go in micro-libgcj?  (E.g., new methods get added to
String from time to time.  Which go in?)

Now, strictly speaking it isn't a problem if we have a relatively
undefined subset of the libraries, provided that the maintenance of it
is also ad hoc -- we have that situation with the xlib peers, where
the "full" AWT is free to break them from time to time, and the
maintainer (and, I think, sole user) of them fixes them up as he
needs.

Tom