commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <>
Subject Re: [codec] More thoughts on CharSets and Encoders (references: R E: [codec] Streamable Codec Framework)
Date Thu, 22 Jan 2004 22:04:41 GMT
Oleg Kalnichevski wrote:

>>The most important phrase in Craig's email was:  "As such, I'm 
>>personally not interested in working on any revolutionary Struts or 
>>Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the 
>>base platform as the minimum requirement."
> Tim & Craig,
> I wish I could agree with you, but unfortunately I have to say that this
> is a very PC- (or let me say big-time computing) centric point of view.
> There are still enough platforms that are in a widespread use where even
> Java 1.2 is not available, for instance MacOS 9 and, more importantly,
> all sorts of micro devices and embedded systems. True, it does not make
> sense to run Struts on a PDA or on a mobile phone. However,
> commons-codec being a low level library may come quite handy when
> developing applications for PDAs. Same story goes for HttpClient, which
> has recently become dependent on commons-codec. HttpClient in its turn
> is a dependency for XML-RPM. Making Codec require Java 1.4 (at this
> point) will cause a rippling effect on many other projects which are
> dependent (either directly or indirectly) on this library. 
> IMHO, Commons-Codec as well as Commons HttpClient being low level
> libraries should target as wider user base as possible. Funny enough, we
> (HttpClient) still get requests for Java 1.1.8 compatibility once in a
> while. Some people went ever as far as creating a semi-official Java
> 1.1.8 fork to cater to their specific needs. The last thing I would like
> to see is a Java 1.2.x fork in addition to that.
> I am not saying Codec should not go forward and adopt new features in
> the Java platform that sense for it. However, we should consider not
> only the risk of working ourselves out of existence but also the risk of
> ending up working just for ourselves.
> At the very least I would like to see a more coherent policy towards
> Java platform compatibility across all Commons sub-project. I believe
> there must be a common baseline we should all agree upon and then stick
> to, whatever it is.
> Cheers,
> Oleg

I still really get a strong sense that more "Tag and Branching" would be 
an empowerment here, HttpClient for j2sdk 1.4 and greater could take 
advantage of those features 1.4 provides (for instance "nio") while a 
maintence branch on < 1.4 could maintain release for those specific JVM's.


Mark Diggory
Software Developer
Harvard MIT Data Center

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

View raw message