Re: areas of divergence

[Bryce McKinlay <mckinlay at redhat dot com>]

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

I have some code that allows PrintStream, OutputStreamWriter and 
InputStreamReader to use java.nio.charset in addition to gnu.gcj.convert 
converters. Classpath, I believe, currently uses java.nio exclusively.

I don't see java.nio.charset ever being as fast as our current 
converters - it doesn't seem possible to implement, say, 
OutputStreamWriter.write() using nio.charset without either additional 
allocations or copying. Ideally, we will have a "fast" set of converters 
for common character sets in classpath, based on gnu.gcj.convert, with 
the ability to use java.nio in other cases. We do need to do some 
benchmarking to make sure this is worthwhile, but based on what I've 
seen so far, I think it will be.

> 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 ...
>  
ASM is under the BSD license, and is designed to be small (only 33k of 
bytecode, apparently). Are there any hurdles to just importing it?

> gnu.java.nio
>  I think we differ here because CNI lets us be more efficient.  I
>  haven't looked at this much.
>  

I think VMs will typically want to provide their own implementations 
here. There are plenty of optimizations to be done when we know about 
object layouts, capabilities of the compiler, etc.

Bryce