On 16 July 2012 22:58, sebb <seb...@gmail.com> wrote: > On 16 July 2012 21:31, Gary Gregory <garydgreg...@gmail.com> wrote: >> Hi All: >> >> With the addition of many new methods to the FileObject interface and other >> TAR changes reported by Clirr [1], the next release will break BC for VFS >> providers (those not provided by VFS itself.) >> >> For normal call sites of the interfaces, nothing should change. For call >> sites that use the TAR provider classe, some VFS TAR changes might need >> call site changes. >> >> Therefore, strictly speaking, the next release should be 3.0 with a package >> rename. >> >> Thoughts? > > If it is only the TAR classes that break BC, could these alone be renamed? > If so, the original classes could be kept and deprecated. > > As a separate issue, if BC does have to be broken in some or all of > the code, then please consider privatising all mutable variables (use > setters/getters) and reducing visibility of classes and methods that > are not intended to be part of the public API. > > I've not looked at the code, but it also strikes me that it might be > possible to maintain BC by keeping and deprecating the methods that > have changed parameter types; introducing a new interface for the new > methods, and creating new methods for createTarFile and getTarFile > which have changed return types.
Just remembered that adding a method to an interface is binary compatible [2], however it can affect source compatibility. Allowing these changes would much reduce the work needed to maintain BC. [2] http://docs.oracle.com/javase/specs/jls/se5.0/html/binaryComp.html >> [1] http://oi46.tinypic.com/2ef46qr.jpg >> >> Thank you, >> Gary >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 >> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
