RFC: micro-libgcj merge proposal
Joel Dice
dicej@mailsnare.net
Fri Jan 13 21:10:00 GMT 2006
On 2006年1月13日, Tom Tromey wrote:
> 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.
I would expect micro-libgcj to be handled like the xlib peers - the
micro-libgcj maintainer(s) would have the sole responsibility of fixing
breakage introduced by those maintaining the "standard" build(s). As far
as I'm concerned, a major code refactoring could eliminate micro-libgcj
code and directives completely if it made things easier. It would be a
pleasure to adapt micro-libgcj to a properly refactored codebase, even
if from scratch.
However, this does touch on a concern I have about breaking
--enable-micro-libgcj into a number of finer-grained options. The more
such options we have, the more confusing things will be for the
maintainers. We have to accept that we can't make things so fine-grained
as to satisfy every user without creating an unmaintainable mess, or a
library that only builds when configured with one of a few magic
combinations of options.
- Joel
More information about the Java
mailing list