This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: RFC: micro-libgcj merge proposal
- From: Tom Tromey <tromey at redhat dot com>
- To: Joel Dice <dicej at mailsnare dot net>
- Cc: java at gcc dot gnu dot org
- Date: 13 Jan 2006 12:25:03 -0700
- Subject: Re: RFC: micro-libgcj merge proposal
- References: <Pine.LNX.4.62.0601131049390.14852@joeldicepc.ecovate.com>
- Reply-to: tromey at redhat dot com
>>>>> "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