On 17 July 2012 15:15, Gary Gregory <garydgreg...@gmail.com> wrote: > On Tue, Jul 17, 2012 at 5:47 AM, sebb <seb...@gmail.com> wrote: > >> 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 >> > > Ok, that that takes care of all the methods added to interfaces, which is > in 2.1 territory > > I'm not sure if the other changes are easily changeable. I (or someone) > will have to see if this can be hacked back. > > For the curious: > > Changed type of field entry from > org.apache.commons.vfs2.provider.tar.TarEntry to > org.apache.commons.compress.archivers.tar.TarArchiveEntry > org.apache.commons.vfs2.provider.tar.TarFileObject entry > > Parameter 2 of 'protected > TarFileObject(org.apache.commons.vfs2.provider.AbstractFileName, > org.apache.commons.vfs2.provider.tar.TarEntry, > org.apache.commons.vfs2.provider.tar.TarFileSystem, boolean)' has changed > its type to org.apache.commons.compress.archivers.tar.TarArchiveEntry > org.apache.commons.vfs2.provider.tar.TarFileObject protected > TarFileObject(org.apache.commons.vfs2.provider.AbstractFileName, > org.apache.commons.vfs2.provider.tar.TarEntry, > org.apache.commons.vfs2.provider.tar.TarFileSystem, boolean) > > Parameter 1 of 'protected void > setTarEntry(org.apache.commons.vfs2.provider.tar.TarEntry)' has changed its > type to org.apache.commons.compress.archivers.tar.TarArchiveEntry > org.apache.commons.vfs2.provider.tar.TarFileObject protected void > setTarEntry(org.apache.commons.vfs2.provider.tar.TarEntry) > > Return type of method 'protected > org.apache.commons.vfs2.provider.tar.TarInputStream > createTarFile(java.io.File)' has been changed to > org.apache.commons.compress.archivers.tar.TarArchiveInputStream > org.apache.commons.vfs2.provider.tar.TarFileSystem protected > org.apache.commons.vfs2.provider.tar.TarInputStream > createTarFile(java.io.File) > > Parameter 2 of 'protected > org.apache.commons.vfs2.provider.tar.TarFileObject > createTarFileObject(org.apache.commons.vfs2.provider.AbstractFileName, > org.apache.commons.vfs2.provider.tar.TarEntry)' has changed its type to > org.apache.commons.compress.archivers.tar.TarArchiveEntry > org.apache.commons.vfs2.provider.tar.TarFileSystem protected > org.apache.commons.vfs2.provider.tar.TarFileObject > createTarFileObject(org.apache.commons.vfs2.provider.AbstractFileName, > org.apache.commons.vfs2.provider.tar.TarEntry) > > Parameter 1 of 'public java.io.InputStream > getInputStream(org.apache.commons.vfs2.provider.tar.TarEntry)' has changed > its type to org.apache.commons.compress.archivers.tar.TarArchiveEntry > org.apache.commons.vfs2.provider.tar.TarFileSystem public > java.io.InputStream > getInputStream(org.apache.commons.vfs2.provider.tar.TarEntry) > > Return type of method 'protected > org.apache.commons.vfs2.provider.tar.TarInputStream getTarFile()' has been > changed to org.apache.commons.compress.archivers.tar.TarArchiveInputStream
The main issue is that the TarEntry class has been removed; this was used in various protected method signatures. Given that the TarEntry class was package-protected, I'm not sure how subclassing was supposed to work. Was it possible to subclass TarFileObject in the previous VFS releases? AFAICT, that would require creating the subclass in the package org.apache.commons.vfs2.provider.tar. If so, then I think we can be fairly sure that there are no external subclasses. If there are, then the authors must realise that their code is fragile, as it is based on the private API. As such, IMO breaking BC is not really an issue. Note: the entry field really needs to be made private or package protected; add a protected getter. This can be done now. > Gary > > >> >> >> [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 >> >> > > > -- > 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
