I've been heavily reviewing the NIO api in 1.4 to understand more fully its capabilities. j2sdk nio provides Charsets (ServiceProviders, Encoders, Decoders)
http://java.sun.com/j2se/1.4.2/docs/api/java/nio/charset/package-summary.html http://java.sun.com/j2se/1.4.2/docs/api/java/nio/charset/spi/CharsetProvider.html
Observations:
NIO already sports API's for Charactersets and encoding. It would appear to also be a strong point of "convergence" for Character Encoding given
that its already in the j2sdk.
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 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.
Which does bring us back to the StreamableCodec Discussion where "java.nio.charset" was recently discussed:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg29450.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg29951.html
In that thread: Brett stated:
What support is there within the JDK for performing character to byte conversion? JDK1.4 has the java.nio.charset package but I can't see an equivalent for JDK1.3 and lower, they seem to use com.sun classes internally when charset conversion is required.
If JDK1.4 is considered a sufficient base, I could extend the current framework to provide conversion engines that translate from one data representation to another. I could then create a new CodecEngine interface to handle character buffers (eg. CodecEngineChar).
Gary responded:
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?
-Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://osprey.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
