areas of divergence

Sat Jul 16 17:30:00 GMT 2005

Here's some info on the areas where libgcj and classpath still
diverge.
gnu.gcj.convert
java.io
 The charset conversion framework still differs.
 I think Bryce has a patch to fix this, though perhaps there are
 still performance concerns (btw if we have benchmarks here it would
 be good to have them in a mauve module or something like that)
gnu.gcj.runtime.*
 Most of this is gcj-specific.
 However some of it could probably be shared. E.g., Classpath has
 system and other class loaders as anonymous classes in
 java.lang.ClassLoader; perhaps one implementation could be changed.
gnu.gcj.xlib
gnu.awt.xlib
 Our xlib peers that use CNI. These are unlikely to be merged.
gnu.java.net
java.net.URLClassLoader
 We have some additional protocol handlers (core, gcjlib), but also
 some divergences in file, jar, and http. These need to be
 investigated, as I don't think there is a good reason to diverge
 here.
gnu.java.locale
java.text
java.util
 We're still using the old locale framework. The only reason for
 this is that I didn't want to do too much in the merge. I hope to
 look into this soon.
gnu.java.rmi.rmic
 Classpath doesn't have rmic in the tree any more. And the rmic in
 classpath-tools now uses ASM. I'm not sure what we want to do
 about this. Removing it would mean stepping back a bit from our
 completeness goal; OTOH merging in tools would mean handling ASM
 somehow ...
gnu.java.nio
 I think we differ here because CNI lets us be more efficient. I
 haven't looked at this much.
java.net
 Not sure
java.util.logging
 Minor differences having to do with how getCallerStackFrame is
 handled. This is an area to VM-ize and push into Classpath.
java.util.zip
 Most of the divergences are because we use zlib. More could be
 merged than currently is; some of the Classpath code here looks like
 it isn't doing enough checking (I have a partial, untested patch...).
 I think kaffe also has a zlib-based implementation so perhaps we
 could do a 3-way merge and get a JNI/zlib implementation into
 Classpath as an alternative somehow.
java.util.ResourceBundle
 Stack trace differences again
java.lang
 The Float/Double diffs seem to be because we wanted some native
 methods for things like floatToIntBits. This seems like a bad
 choice to me. IMO these methods can be inlined by the compiler if
 performance is needed, and if not, an extra method call is not super
 important.
 Object, Class, and String are unlikely to be fully merged.
 Perhaps Character falls into this category as well.
java.lang.ref
 A change for how we handle references.
 I think our handling here is actually subtly wrong :-(
java.lang.reflect
 I haven't looked at the Classpath versions here.
 Most of the classes we have seem to be in the vm-specific area, so
 perhaps there's nothing to do.
java.nio
 I think CNI-isms again. Not sure about java.nio.charset
There are a few changes here and there that I haven't mentioned. Over
time I would like to reduce our divergences as much as possible. In
most cases there is no benefit to having changes from Classpath.
Tom