commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [codec] More thoughts on CharSets and Encoders (references: R E: [codec] Streamable Codec Framework)
Date Fri, 23 Jan 2004 00:45:28 GMT
Quoting Oleg Kalnichevski <olegk@bluewin.ch>:

> > 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,

Not really asking you to, since it was an expression of where *I* am going to
focus my own personal efforts :-).

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

It's up to the developers of each package.  The best way to influence that
decision, for the packages that people care about, is to become a developer on
them :-).

Most appear to have settled on 1.2 as a base platform, with some still trying to
make provisions for 1.1.  But this decision has negative consquences for
Jakarta packages as well -- it means we tend to spend a lot of time
re-inventing what is already available, and we tend to not even think about
designs that are enabled by the newer JDK's features, simply because it would
take lots of work to write corresponding support for pre-1.4 users.  Over the
last couple of years, the net result of this (across all the Jakarta projects
I'm familiar with) is a gradual reduction in innovation and new ideas.

I'm not a codec contributor, so I don't have a voice in the decision for that
package.  I agree with your point that the use cases are likely to be
different. Also, one could jusifiably accuse me of hijacking this message
thread :-) 

But I really would like to see Jakarta projects do things for all the 1.4 users
in the world, even if it means that code won't be helping users on pre-1.4
systems.  And, since my primary interest is on server side apps (where 1.4 is
more commonly available, or will be very soon), that's where I'm going to
focus.

> Cheers,
> 
> Oleg
> 

Craig


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