Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <4089DCAF.3040003@apache.org>
Date: Fri, 23 Apr 2004 20:19:11 -0700
From: "Craig R. McClanahan" <craigmcc@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20031111
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [digester] local ArrayStack implementation not
 backwardscompatible?
References: <1082361677.714.212.camel@pcsimon>
 <005301c42644$9cbed440$de668051@oemcomputer>
In-Reply-To: <005301c42644$9cbed440$de668051@oemcomputer>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stephen Colebourne wrote:

>From: "Simon Kitching" <simon@ecnetwork.co.nz>
>  
>
>>While compiling the release notes, and checking for API
>>incompatibilities between releases, it occurred to me that there is a
>>backward compatibility issue. Am I right in thinking that when
>>subclassing a class with "protected" members, if the parent class
>>implementation changes the type of those members then that is a binary
>>incompatibility with the subclass?
>>    
>>
>You are correct.
>
>  
>
>>PS: I've tested BeanUtils and Digester against collections-3.0, and:
>>(a) binaries compiled against collections-2.1 complete all tests ok
>>    when 3.0 is put in the classpath instead of 2.1.
>>(b) all source compiles against 3.0 fine, and tests run ok.
>>    
>>
>I have avoided commenting on digester/beanutils issues with collections, as
>I believe the long term proposed solution of separation to be correct
>(commons components should be pretty isolated). However, at the very least
>it needs to be made clear in any release notes that digester and beanutils
>will run correctly with either 2.1 or 3.0. Perhaps that way tomcat can be
>convinced to change to 3.0.
>  
>
 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.

>Stephen
>  
>
Craig


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org