Tim,
By no means I want to see further development of [Codec] stopped or
hindered for the sake of other projects' convenience. All I want is to
ensure that basic features of [Codec] are still usable in those projects
that are less fortunate with the JDK compatibility requirements.

BTW, did anyone have time to take a look at the patch (PR #26617)
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26617> I submitted a
while ago? If you find it worthy of further work, I'll happily provide
all the missing bits.

Cheers

Oleg

On Tue, 2004-02-24 at 22:12, Tim O'Brien wrote:
> Oleg, no one has talked about breaking existing interfaces - 1.2 will 
> still be supported be (at the very least) by all existing features.  
> 
> This is more of a discussion of future growth, we are going to find a way 
> to enable features dependent on 1.4 while still support (creating a 
> distributable) for 1.2.
> 
> Tim
> 
> On Tue, 24 Feb 2004, Oleg Kalnichevski wrote:
> 
> > 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]
> > 
> > 
> > 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to