What needs to be done to finish merging java.io ?

[Tom Tromey]

>>>>> "Nathanael" == Nathanael Nerode <neroden@doctormoo.dyndns.org> writes:

Nathanael> The subject line says it all, really.  A few classes simply
Nathanael> added serial version IDs.

A change like this can be merged in directly.

Nathanael> A bunch, however, have substantive changes or were never
Nathanael> merged at all.  Looking at them I'm not quite clear on
Nathanael> whether we have the support classes from Classpath
Nathanael> necessary to use the new Classpath versions, or indeed
Nathanael> whether we want to.  It looks like some rewrites of native
Nathanael> code would be necessary.

I think there are 3 issues in java.io:

* The native code is structured differently -- Classpath and libgcj
  made different decisions about where to put native code, how to
  write FileDescriptor, some other things like this.
  Someone who understands the issues (in particular the Windows port)
  would need to look into this to decide what to do.

* The serialization implementation diverged.
  Someone who understands (or is willing to learn) serialization will
  have to look into this.  I still have remained mostly ignorant of
  serialization.  Our last expert, Warren, hasn't done gcj work in a
  while.  In my opinion this is the most worthwhile task in this area;
  there are some known serialization bugs (see Gnats; there are also
  some serialization fixes in the "Intel patch" on the Classpath
  list); merging and fixing things here is really a correctness
  issue.

* Charset conversion code differs.
  The early JDKs didn't specify how this was to be implemented, so of
  course both Classpath and libgcj came up with their own design.
  Last time I looked I generally preferred the libgcj approach.
  However, I think we've all been waiting for java.nio to solve this
  problem.  Unfortunately java.nio work is proceeding slowly.

Tom