commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Graham <grahamdavid1...@yahoo.com>
Subject Re: [digester] local ArrayStack implementation not backwardscompatible?
Date Tue, 04 May 2004 21:34:39 GMT

--- robert burrell donkin <robertburrelldonkin@blueyonder.co.uk> wrote:
> 
> On 4 May 2004, at 22:23, David Graham wrote:
> 
> >
> > --- robert burrell donkin <robertburrelldonkin@blueyonder.co.uk>
> wrote:
> >> On 24 Apr 2004, at 04:19, Craig R. McClanahan wrote:
> >>
> >> <snip>
> >>
> >>> From what I can see on TOMCAT-DEV, the Tomcat developers think that
> >>> there are backwards incompatibilities for Tomcat users (beyond any
> >>> issues that might affect Tomcat itself).  Based on that, I've
> >>> certainly been one of those casting aspersions.  If we're all full
> of
> >>> it, a [collections] statement on the nature and scope of backwards
> >>> compatibility, pointing out the error of our (Tomcat developers and
> >>> my) ways, would go a long ways towards addressing this concern.
> >>>
> >>> Struts is shortly going to be in the same boat ... the dependency of
> >>> Struts itself on collections is only that inherited from
> >>> Digester/BeanUtils; but the Struts developers will want to ensure 
> >>> that
> >>
> >>> an upgrade to Collections 3.0 won't cause undue problems for users
> of
> >>> Struts, before we switch.
> >>
> >> i've been wondering if a possible solution might be to include
> >> org.apache.commons.collections.ArrayStack and
> >> org.apache.commons.collections.Buffer in with a new beanutils
> release.
> >> these are very stable classes and only the javadocs have changed
> since
> >> the 2.1 collections release.
> >
> > I don't have beanutils source in front of me but why do we even need
> > ArrayStack at all?  It doesn't seem to do anything that standard Java
> > collection classes don't already provide.  I'm assuming Buffer is only
> > needed because ArrayStack implements it?  It would be nice to make a 
> > clean
> > break from Commons Collections and not include duplicate classes from 
> > its
> > jar.
> 
> we screwed up :(
> 
> a reference (in a public API) to the collection packaged version was 
> introduced and not picked up before it had been released.

Can we deprecate the offending API, provide standard Java collection
alternatives for this release and remove the methods in the release after
this?

David

> 
> - robert



	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 

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