Re: areas of divergence

[Mark Wielaard]

Hi,

I CCed the main classpath list because I think this will interest most
hackers there. (Those that didn't notice yet: The Big Merge is done!)

On Sat, 2005-07-16 at 11:26 -0600, Tom Tromey wrote:
> 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.

Probably since only gcj currently supports CNI.
But even then it might be a good idea to merge them because that will
make it easier to keep them up to date when/if we make (peer interface)
changes.

> 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.

What we should probably do is split out the inner-class URLLoaders into
their own (package private) classes. And have a VMURLClassLoader through
which a runtime can register its own special URLLoaders (like the
gcjlib: and core: handlers of libgcj).

> 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 ...

We probably should make separate releases of GNU Classpath Tools on day.
These should of course also come with native gcj-compiled versions of
each tool. Just like we do now for gjdoc.

> 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.

Yes. Just before 0.17 I fixed up this code a but in GNU Classpath. But
it definitely must be either factored out completely into its own
VMLogger class, or it should use the VMStackWalker infrastructure
(another point to make sure libgcj and classpath align their
interfaces.)

> 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

Hopefully the same solution as java.util.logging.

> 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.

Thanks so much for the Big Merge Tom! This really brings us much closer
and should make maintanance a lot easier.

Do you have any guidelines for "keeping the big merge in sync"?
When is a new "overlay" version tagged and moved into the gcc tree?
Could/Should we coordinate that with GNU Classpath developer snapshot
releases? And how do we handle small (emergency) divergences that pop up
in the embedded classpath dir inside the gcc tree?

Cheers,

Mark

signature.asc
Description: This is a digitally signed message part