From: "Simon Kitching" <[EMAIL PROTECTED]>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.
While compiling the release notes, and checking for APIYou are correct.
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?
PS: I've tested BeanUtils and Digester against collections-3.0, and:I have avoided commenting on digester/beanutils issues with collections, as
(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 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.
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.
StephenCraig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
