RFC: Moving java.io, java.lang to NIO charsets

[Sven de Marothy]

Hello everyone.

Ok folks, this is it. Assuming you've got all my fixes to the NIO
charsets, this patch re-implements String, InputStreamReader and
OutputStreamWriter to use the java.nio charset converters.

The good:
1) Eliminating the need for a seperate set for .io and .lang.
2) Allowing for different implementations without changes to these
classes (e.g. a native iconv-based implementation)
3) Allowing for user charset-providers to be used with .io and .lang
4) More supported encodings.
5) Cleaner.

The bad:
1) Could be slower, I haven't benchmarked. (But the architecture allows
for a potentially very fast iconv+NIO direct buffer implementation)
2) These classes are used in bootstrap before the NIO provider is
loadable. 

Since all encoding/decoding required early in bootstrap (loading
properties, jar manifests) is to or from ISO8859-1 (latin-1), I belive
I've solved the second problem, although this needs to be tested on more
VMs (I used JamVM) and under more circumstances. My solution was that
whenever the default encoding can't be retrieved for any reason, we fall
back on 8859_1. (i.e. casting byte to char) This is pretty much what the
old code did too, but the NIO provider needs more stuff than the old
charset handler.

I get no mauve regressions. But since we're talking about significant
changes to core classes here, I want this thing to be tested by at least
2 more people before I'll even consider commiting it. You shouldn't
notice any difference.

/Sven (going to bed now.)

io_to_nio.patch
Description: Text Data