commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett Henderson" <jaka...@bretth.com>
Subject RE: [codec] More thoughts on CharSets and Encoders (references: RE: [codec] Streamable Codec Framework)
Date Fri, 16 Jan 2004 02:49:06 GMT
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message