Re: Classpath / GCJ java.io Merge

[Aaron M. Renn]

Tom Tromey (address@hidden) wrote:
> Aaron> For #1, I have no idea what has been decided regarding native code.
> Aaron> Last I checked, we still had a JNI/CNI deadlock going on.
> 
> I'm resigned to the fact that we'll need dual implementations of
> certain native code.  The Gtk AWT peers I imported into libgcj as-is,
> using JNI, but that is a special case.
> 
> This does hamper merging since it is a lot of effort to rewrite the
> JNI code.  I've never had time, or really much motivation.
> I think there's also some question of which approach is preferable.

One problem is that it is not just the native methods that are different.
I think it would be relatively easy to write a CNI and a JNI version of
the code as there is not a huge amount of native code to write for
IO and networking.  The problem is that the entire implementation strategy
of the classes is different.  For example, gcj relies heavily on delegating
to OS file access methods in the FileDescriptor class, which Classpath
doesn't use at all.  The challenge would seem to be getting agreement
on what native methods need to be written and what their signatures are.
 
> Aaron> For #2, it seems that the answer is to switch to NIO.  I hear
> Aaron> that the Classpath version is not yet functional however.
> 
> I think Michael just got the gcj version to work.  I think his plan is
> at least to merge all the Java code back to Classpath.  I'm not sure
> if he is planning to write the JNI side or not.  I also don't know how
> much work that would be.

That will have to be addressed, I guess.  I just noticed that there are
shitloads of native methods in this package.  Hopefully except for
falling back on iconv, there aren't a huge number of them for charest
conversion.
 
> In Classpath, methods in DataOutputStream are used by
> RandomAccessFile.  So this puts DataOutputStream effectively into
> category 1.  Also the Classpath implementation allocates in many of
> the write methods, which we preferred to avoid in libgcj (especially
> when I wrote this code, way back when).

Those shared methods can die, IMO.  They don't do much.  The allocation
is an interesting point.  Classpath does it to avoid doing what gcj
does: namely do tons of single byte writes.  This would be hideously
expensive in the JNI world.  Is allocation still a problem?
 
> For PrintStream it looks like there were conflicting goals.  From
> libgcj:

Hmm.  I kinda liked the Classpath approach, assuming it's actually a
valid implementation strategy, because I'm lazy by nature.  

> Also, the libgcj PrintStream knows about charset conversion, so it is
> effectively in category 2.
 
> LineNumberReader I don't know.  I think I just never found the
> motivation to compare the two implementations.  They are very
> different, so a lot of testing would probably be in order.

I'll take a look at this. 

-- 
Aaron M. Renn (address@hidden) http://www.urbanophile.com/arenn/