[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[cp-patches] RFC: Moving, java.lang to NIO charsets

From: Sven de Marothy
Subject: [cp-patches] RFC: Moving, java.lang to NIO charsets
Date: Sat, 09 Apr 2005 05:56:57 +0200

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

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

Attachment: io_to_nio.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]