The only very vague advice/feeling I have on NIO and 1.4 APIs and using 1.4 APIs "eventually" is:
(1) "eventually" is, sadly I think, a ways off in the future. See discussions on this list WRT J2ee containers, WebSphere, most common installed base of such containers, etc. (2) What could be done, and please forgive my lack of intimacy with these APIs, is to create [codec] APIs that are forward compatible to any extent possible. What I mean by this if NIO has a class Foo with methods a() and b(Foo) is to create an equivalent [codec] class Bar with methods a() and b(Bar), which would allow one to do search and replace in the future. This is quite a stretch I know, but guess what, we've done this at work in the logging domain (we have our own logging which we want to eventually move to 1.4 or log4j). Gary > -----Original Message----- > From: Mark R. Diggory [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 15, 2004 09:38 > To: Jakarta Commons Developers List > Subject: [codec] More thoughts on CharSets and Encoders (references: RE: > [codec] Streamable Codec Framework) > > 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/CharsetProvid > er.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]
