commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett Henderson" <>
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

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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message