You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Simon Kitching <si...@ecnetwork.co.nz> on 2004/04/19 10:01:17 UTC
[digester] local ArrayStack implementation not backwards
compatible?
Hi all,
There was a recent change by Craig to add a copy of the collections
ArrayStack class into digester to make it independent of collections.
The critical emails seem to be:
http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=107574718316162&w=2
and
http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg35448.html
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?
Below is the draft text I wrote for the release notes.
I don't think these incompatibilities are *too* severe. However given
that we can't drop the Collections library until BeanUtils2.0 anyway,
maybe it makes sense to roll this change back?
Any comments?
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.
== Potentially incompatible changes
* ArrayStack
Previously, Digester required the collections library, simply for a
single class: ArrayStack. To avoid depending explicitly on the
commons-collections library, a copy of this class has been made within
the digester library. All places which once used the collections version
now use the digester version. Unfortunately, user classes which subclass
the modified classes may need to be recompiled. The affected classes
are:
CallParamRule (member bodyTextStack)
Digester (members bodyTexts, params and stack)
xmlrules.DigesterRuleParser
Note that the following class *uses* ArrayStack, but because it is
private, not protected I believe there is no issue (?)
FactoryCreateRule
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] local ArrayStack implementation not
backwardscompatible?
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Wed, 2004-05-05 at 09:09, robert burrell donkin 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.
+1 from me.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] local ArrayStack implementation notbackwardscompatible?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Simon Kitching" <si...@ecnetwork.co.nz>
> So the only question is: should it be BeanUtils that copies the class
> and does a release (with Digester depending on the new BeanUtils
> release), or should the copied class be added to Digester, with Digester
> depending on the existing BeanUtils release?
>
> The latter is probably easier as we are about to do a Digester release
> anyway, but a new BeanUtils release would provide this "decoupling"
> feature to all BeanUtils users, not just Digester.
I would favour beanutils as I would like to minimise the places the code
gets copied to in this manner.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] local ArrayStack implementation not backwardscompatible?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 5 May 2004, at 13:56, David Graham wrote:
> --- Simon Kitching <si...@ecnetwork.co.nz> wrote:
<snip>
>> So the only question is: should it be BeanUtils that copies the class
>> and does a release (with Digester depending on the new BeanUtils
>> release), or should the copied class be added to Digester, with
>> Digester
>> depending on the existing BeanUtils release?
>>
>> The latter is probably easier as we are about to do a Digester release
>> anyway, but a new BeanUtils release would provide this "decoupling"
>> feature to all BeanUtils users, not just Digester.
>
> I would prefer BeanUtils because Validator depends on it and is trying
> to
> remove its Collections dependency.
+1
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] local ArrayStack implementation not backwardscompatible?
Posted by David Graham <gr...@yahoo.com>.
--- Simon Kitching <si...@ecnetwork.co.nz> wrote:
> On Wed, 2004-05-05 at 11:57, Craig McClanahan wrote:
> > I like copying the class without a package rename as a medium-term
> step
> > while we deprecate and create a new public method that returns a
> > standard collection class instead of a [collections] class. The
> chances
> > of a bad change on the [collections] version of this class are low;
> > especially in the kind of time frame we are talking about.
>
> So the only question is: should it be BeanUtils that copies the class
> and does a release (with Digester depending on the new BeanUtils
> release), or should the copied class be added to Digester, with Digester
> depending on the existing BeanUtils release?
>
> The latter is probably easier as we are about to do a Digester release
> anyway, but a new BeanUtils release would provide this "decoupling"
> feature to all BeanUtils users, not just Digester.
>
I would prefer BeanUtils because Validator depends on it and is trying to
remove its Collections dependency.
David
> Regards,
>
> Simon
__________________________________
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
Re: [digester] local ArrayStack implementation not
backwardscompatible?
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Wed, 2004-05-05 at 11:57, Craig McClanahan wrote:
> I like copying the class without a package rename as a medium-term step
> while we deprecate and create a new public method that returns a
> standard collection class instead of a [collections] class. The chances
> of a bad change on the [collections] version of this class are low;
> especially in the kind of time frame we are talking about.
So the only question is: should it be BeanUtils that copies the class
and does a release (with Digester depending on the new BeanUtils
release), or should the copied class be added to Digester, with Digester
depending on the existing BeanUtils release?
The latter is probably easier as we are about to do a Digester release
anyway, but a new BeanUtils release would provide this "decoupling"
feature to all BeanUtils users, not just Digester.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] local ArrayStack implementation not backwardscompatible?
Posted by Craig McClanahan <cr...@apache.org>.
Stephen Colebourne wrote:
>From: "David Graham" <gr...@yahoo.com>
>
>
>>What happens if someone is using both digester and collections? Which
>>ArrayStack class would be used when they're in the same package in
>>different jars? Hoping that the class doesn't change seems rather
>>optimistic and error prone.
>>
>>
>
>Its a judgement on the stability of the classes in question. Buffer is an
>interface, and thus doesn't change. ArrayStack is very old and stable.
>
>I am also in favour of digester moving to not requiring the classes ASAP as
>well ;-)
>
>
>
FWIW, we did indeed decouple Digester's *direct* dependence on
[collections]. This was done by copying the ArrayStack class (with a
package rename, since it was only used internally and not publicly
exposed) into o.a.c.digester. The only remaining dependency is the one
inherited from [beanutils].
I like copying the class without a package rename as a medium-term step
while we deprecate and create a new public method that returns a
standard collection class instead of a [collections] class. The chances
of a bad change on the [collections] version of this class are low;
especially in the kind of time frame we are talking about.
>Stephen
>
>
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] local ArrayStack implementation not backwardscompatible?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "David Graham" <gr...@yahoo.com>
> What happens if someone is using both digester and collections? Which
> ArrayStack class would be used when they're in the same package in
> different jars? Hoping that the class doesn't change seems rather
> optimistic and error prone.
Its a judgement on the stability of the classes in question. Buffer is an
interface, and thus doesn't change. ArrayStack is very old and stable.
I am also in favour of digester moving to not requiring the classes ASAP as
well ;-)
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] local ArrayStack implementation not backwardscompatible?
Posted by David Graham <gr...@yahoo.com>.
--- Stephen Colebourne <sc...@btopenworld.com> wrote:
> From: "robert burrell donkin" <ro...@blueyonder.co.uk>
> > maybe we could sidestep this issue by including the two collections
> > classes (ArrayStack and Buffer) that beanutils depends upon (either
> > directly or indirectly) within the beanutils release and removing the
> > collections dependency. since the versions of these classes in
> > collections 2.1 and 3.0 seem to differ only in licensing and
> > documentation, this would make beanutils and digester compatible with
> > both 2.1 and 3.0 collections.
>
> I am in favour of removing the direct dependency on [collections]. The
> proposed solution of copying the two classes to digester (no package
> rename)
> is fully acceptable to me, and I will happily add comments to
> [collections]
> noting that the copy has occurred (or you could add the comments to
> collections yourself ;-).
What happens if someone is using both digester and collections? Which
ArrayStack class would be used when they're in the same package in
different jars? Hoping that the class doesn't change seems rather
optimistic and error prone.
David
>
> I have no plans to update either Buffer or ArrayStack, nor are there any
> known issues. They are very stable classes, and well suited to this kind
> of
> copy.
>
> Stephen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
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
Re: [digester] local ArrayStack implementation not backwardscompatible?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "robert burrell donkin" <ro...@blueyonder.co.uk>
> maybe we could sidestep this issue by including the two collections
> classes (ArrayStack and Buffer) that beanutils depends upon (either
> directly or indirectly) within the beanutils release and removing the
> collections dependency. since the versions of these classes in
> collections 2.1 and 3.0 seem to differ only in licensing and
> documentation, this would make beanutils and digester compatible with
> both 2.1 and 3.0 collections.
I am in favour of removing the direct dependency on [collections]. The
proposed solution of copying the two classes to digester (no package rename)
is fully acceptable to me, and I will happily add comments to [collections]
noting that the copy has occurred (or you could add the comments to
collections yourself ;-).
I have no plans to update either Buffer or ArrayStack, nor are there any
known issues. They are very stable classes, and well suited to this kind of
copy.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] local ArrayStack implementation not backwardscompatible?
Posted by David Graham <gr...@yahoo.com>.
--- robert burrell donkin <ro...@blueyonder.co.uk> wrote:
> On 4 May 2004, at 22:34, David Graham wrote:
> > --- robert burrell donkin <ro...@blueyonder.co.uk>
> wrote:
>
> <snip>
>
> >> 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?
>
> i think that would be the right medium term strategy. (the next release
> would have to be a 2.0)
Why 2.0? Over in Struts, Validator, and DBUtils we've been following the
Maven release guidelines that state deprecated API can be removed in the
next point release. This seems to be working well and I'd be surprised to
find out more projects didn't follow this scheme.
David
>
> there is a short term issue with the incompatibility between
> collections 2.0 and 3.0. this is worrying to tomcat and struts (and
> other folks as well ;).
>
> maybe we could sidestep this issue by including the two collections
> classes (ArrayStack and Buffer) that beanutils depends upon (either
> directly or indirectly) within the beanutils release and removing the
> collections dependency. since the versions of these classes in
> collections 2.1 and 3.0 seem to differ only in licensing and
> documentation, this would make beanutils and digester compatible with
> both 2.1 and 3.0 collections.
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
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
Re: [digester] local ArrayStack implementation not backwardscompatible?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 4 May 2004, at 22:34, David Graham wrote:
> --- robert burrell donkin <ro...@blueyonder.co.uk> wrote:
<snip>
>> 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?
i think that would be the right medium term strategy. (the next release
would have to be a 2.0)
there is a short term issue with the incompatibility between
collections 2.0 and 3.0. this is worrying to tomcat and struts (and
other folks as well ;).
maybe we could sidestep this issue by including the two collections
classes (ArrayStack and Buffer) that beanutils depends upon (either
directly or indirectly) within the beanutils release and removing the
collections dependency. since the versions of these classes in
collections 2.1 and 3.0 seem to differ only in licensing and
documentation, this would make beanutils and digester compatible with
both 2.1 and 3.0 collections.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] local ArrayStack implementation not backwardscompatible?
Posted by David Graham <gr...@yahoo.com>.
--- robert burrell donkin <ro...@blueyonder.co.uk> wrote:
>
> On 4 May 2004, at 22:23, David Graham wrote:
>
> >
> > --- robert burrell donkin <ro...@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
Re: [digester] local ArrayStack implementation not backwardscompatible?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 4 May 2004, at 22:23, David Graham wrote:
>
> --- robert burrell donkin <ro...@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.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] local ArrayStack implementation not backwardscompatible?
Posted by David Graham <gr...@yahoo.com>.
--- robert burrell donkin <ro...@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.
David
>
> i think that this would buy us a little time to fix the problem
> properly (in beanutils2 and digester2).
>
> i'm little reluctant to put betwixt on hold right now (i'm very close
> to being able to merge back in the refactoring branch) but i think i'll
> try to concentrate my efforts on digester and beanutils since these
> problems seem both important and quite pressing.
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
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
Re: [digester] local ArrayStack implementation not backwardscompatible?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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 think that this would buy us a little time to fix the problem
properly (in beanutils2 and digester2).
i'm little reluctant to put betwixt on hold right now (i'm very close
to being able to merge back in the refactoring branch) but i think i'll
try to concentrate my efforts on digester and beanutils since these
problems seem both important and quite pressing.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] local ArrayStack implementation not backwardscompatible?
Posted by Craig McClanahan <cr...@apache.org>.
Stephen Colebourne wrote:
>This slipped past me...
>
>I have already examined the source and test compatability of collections 3.0
>and 2.1:
>http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg37636.html
>
>Binary compatability is much more difficult to test for. As there is no
>automated tool, some binary incompatabilities did occur, mainly affecting
>the IteratorUtils class. See mail just sent today, header [collections].
>
>I also ought to point out that I sent mails about binary incompatabilities
>in the upcoming 3.1 a few days ago and no-one replied. It is quite difficult
>to manage a project with limited feedback!
>
>
>
I can appreciate that feeling :-). Thanks for the detailed list ...
that should really help reduce concerns.
>Stephen
>
>
Craig
>From: "Craig R. McClanahan" <cr...@apache.org>
>
>
>>>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.
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] local ArrayStack implementation not backwardscompatible?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
This slipped past me...
I have already examined the source and test compatability of collections 3.0
and 2.1:
http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg37636.html
Binary compatability is much more difficult to test for. As there is no
automated tool, some binary incompatabilities did occur, mainly affecting
the IteratorUtils class. See mail just sent today, header [collections].
I also ought to point out that I sent mails about binary incompatabilities
in the upcoming 3.1 a few days ago and no-one replied. It is quite difficult
to manage a project with limited feedback!
Stephen
From: "Craig R. McClanahan" <cr...@apache.org>
> >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.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] local ArrayStack implementation not backwardscompatible?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Stephen Colebourne wrote:
>From: "Simon Kitching" <si...@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
Re: [digester] local ArrayStack implementation not backwardscompatible?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Simon Kitching" <si...@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.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org