On 30 March 2011 16:19, Jochen Wiedmann <jochen.wiedm...@gmail.com> wrote: > On Tue, Mar 29, 2011 at 8:52 PM, sebb <seb...@gmail.com> wrote: > >> I think that should be avoided unless the API is also being changed in >> an incompatible way, and then only if it really is impossible to >> maintain backwards compatibility. > > I think there are excellent reasons to change the API in codec. > Reasons include lack of support for streaming in most cases, lack of > support for integration in SAX or StAX streams and the like, which > could be relatively easy with standard interfaces. Take, for example, > > > http://www.jarvana.com/jarvana/view/org/apache/ws/commons/util/ws-commons-util/1.0.2/ws-commons-util-1.0.2-javadoc.jar!/org/apache/ws/commons/util/Base64.html >
But does the API have to change, or could these additional features be supported by adding new methods and classes? For example, I originally thought that the fixes to Net NNTP to support long article Ids would require a compatibilty break, as ints were used throughout, but having done the work it turned out that compatibility could be maintained by adding one or two new classes, and some new methods. Users wanting to use the new methods will of course have to edit and recompile, but other Net users won't be affected. > > -- > I Am What I Am And That's All What I Yam (Popeye) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
