Tom> libgcj still has some core classes which diverge from Classpath (and Tom> which most likely will continue to do so); one example is String. So, Tom> I had to add support to the Classpath build infrastructure to let us Tom> override some core Classpath classes with our own copies.
Mark> How many (and which) other public classes are in the same situation? Right now there are a lot of classes in this category -- over 100. However, not all of these represent unsolvable cases. For instance, some are related to charset conversion; once the nio changes are dealt with in libgcj, these can go away. One important point here is that this approach makes incremental merging simpler -- once we merge a piece, we simply delete the override classes from libgcj and then it will not diverge again. I would say the theoretical minimum number of override classes is on the order of 10. At least String (and therefore StringBuffer), Character, Object, and Class are not likely to be fully merged for the foreseeable future. Mark> I am still slightly troubled by the fact that you seem to depend Mark> on a different class byte code version of some of the public core Mark> classes. That makes my dream of a common glibj for all tools on the GNU Mark> platforms further away. In my opinion doing this makes this dream closer, as it makes it simpler to do merges and simpler to experiment. As I see it there are still unsolved technical problems with making the dream work well for libgcj. Namely, first CNI must be made to work BC; second, gcj can't deal with a non-libgcj Object or Class at the moment, so this would have to be fixed; and third, someone would have to do a lot of profiling to show that changing String's representation doesn't hurt. Mark> The only real nitpick I have with this is that it seems to be an all or Mark> nothing option. There are not that many classes in vm/reference, 28 atm, Mark> but it would be nice if the majority could be used as is. I'm not averse to this if we can make it work. Originally I planned to make one patch that solved everything, but while working on it I realized that the result was simply too big to manage well. So, my current plan is incremental: do as minimal a build change as possible, and then, once it is in, write followup patches to clean up specific oddities. Tom _______________________________________________ Classpath-patches mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath-patches
