Re: Classpath / GCJ java.io Merge

[Tom Tromey]

>>>>> "Aaron" == Aaron M Renn <address@hidden> writes:

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.

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.

Aaron> 3. Random Classes
Aaron> -----------------
Aaron> DataOutputStream
Aaron> LineNumberReader
Aaron> PrintStream

Aaron> For #3, I'm a bit confused.  Does anyone have any background on
Aaron> why these classes aren't merged?  I poked around the source
Aaron> code, and it does not appear obvious.  Are the Classpath
Aaron> versions seriously broken or something?

I remember looking at this a long time ago.

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

For PrintStream it looks like there were conflicting goals.  From
libgcj:

  /* Notice the implementation is quite similar to OutputStreamWriter.
   * This leads to some minor duplication, because neither inherits
   * from the other, and we want to maximize performance. */

>From Classpath:

 * Ok, why is this class deprecated?  It could easily have been extended
 * to support character encodings.  In fact, PrintWriter is basically a
 * superset of this except for the write() methods.  So let's do something
 * tricky here and just redirect calls in this class to a hidden PrintWriter
 * instance.  All the functionality goes there since that is the 'real'
 * class.  The big win of doing this way is that the default character 
 * encoding is done automagicially by the PrintWriter tree!

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.

Tom