Quoting Oleg Kalnichevski <[EMAIL PROTECTED]>: > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
