> Does CharSet/Util's in [lang] approach a similar > functionality to nio.charset? After reviewing the codebase, > my viewpoint is no, as it is more for "building" charsets, > than for using them (authors rebuttals always welcome).
I'd also be interested to see if this functionality exists somewhere. > I think [httpclients] static ASCII methods (once in > HttpConstants) now also in [codec-multipart] are very similar > in functionality to the idea of CharsetEncoders/Decoders of > nio.charset. > > So we begin to have functionality for charset's in [lang] and for > encoders in [codec]. How do we bring this all together? I'd > like to see > similar CharsetEncoding/Decoding capabilities as nio (with > the eventual > goal of actually having Jakarta Commons converge to using nio of > Charsets in the future. > > As a possible bridge for transition I think a CharsetEncoder > API in [codec] that duplicates that of nio.charset would form > an excellent path for convergence. The eventual goal once > j2sdk1.3 was no longer in service would be to simply refactor > Apache Projects dependent on this API to use NIO instead. Does the CharSetEncode class in my library approach the functionality you require? http://www32.brinkster.com/bretthenderson/BHCodec-0.6.zip Internally it uses an OutputStreamWriter which leverages JDK functionality albeit in a somewhat inelegant way. I would expect performance to be fairly reasonable however. I intend to write a corresponding CharSetDecode class but haven't gotten around to this yet. If you have any interest I can up the priority. It will use an InputStreamReader internally unless better alternatives are found. If at some point in the future JDK 1.4 becomes an accepted base I will be reworking CharSetEncode to use java.nio features because they provide a cleaner interface than wrapping streams. > >> If JDK1.4 is considered a sufficient base, I could > > > > I think tha considering 1.3.1 as the base requirement is safe. > > Unfortunately, as discussed on this list under various > heading, making > > 1.4 a requirement is too aggressive. > > > > Gary > > Yes, we're still supporting 1.3 in many cases, BUT, wouldn't we want > convergence eventually to the API's provided by the j2sdk? > AND, by that > point in the future, is j2sdk 1.3 even going to be in play? I will always be leaving a CharSetEncode feature in my library because it allows charset conversion to be performed within a processing chain but I would see the internal implementation moving to java.nio eventually. Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
