areas of divergence

[Tom Tromey <tromey at redhat dot com>]

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