Tim, Gary Currently [Codec] is still Java 1.2 compatible. And yes, there are [Codec] users who would like it to stay that way at least for some time. Not that we enjoy working around Java 1.2 limitations that much, but we simply have obligations to our users as well (there are several projects, including Apache ones, dependent on [HttpClient] that need to support a wide spectrum of platforms including those that do not have modern JDKs).
We will support 1.2 compatible [Codec] branch ourselves, if we absolutely have to, but would still very much appreciate if you kept us posted before the decision was taken to make [Codec] dependent on Java >1.2 features. I apologize for being such a pain in the rear Oleg On Tue, 2004-02-24 at 04:37, Tim O'Brien wrote: > Gary Gregory wrote: > >> public java.util.List operation(java.nio.ByteBuffer buffer); > > > > This brings up an interesting issue: How do we potentially package and > > deliver some code that depends on Java 1.4. In a second [codec] jar? I think > > we should keep the JRE requirement to a minimum for [codec]. Here, we are > > stuck on 1.3.1 for the foreseeable future. > > We'll tackle the problem of creating a 1.3 compatible release at relase > time, but for the time being, I'm not going to reject good code from > highly motivated parties within the ASF. I don't think anyone plans on > breaking existing interfaces, but the proposed addition is new > functionality. > > > Some others, I imagine need 1.2 compatibility. > > If you are using 1.2, you can expect releases that support 1.2 to be > maintained if there are developers with the motivation to maintain these > releases. > > Tim > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
