On 30 January 2015 at 16:48, Gary Gregory <garydgreg...@gmail.com> wrote: > On Fri, Jan 30, 2015 at 6:06 AM, Stefan Bodewig <bode...@apache.org> wrote: > >> On 2015-01-30, sebb wrote: >> >> > On 30 January 2015 at 08:20, Stefan Bodewig <bode...@apache.org> wrote: >> >> On 2015-01-28, Benedikt Ritter wrote: >> >> >>> - PROPOSAL.txt is not in the src archives. Should it be? >> >> >> This is only there for historical reasons, I don't even think the other >> >> components still have a file like this. I've removed it completely. >> >> >>> - there is a typo in the release notes. The first line says "Apache >> >>> Apache Commons Compress" >> >> >> fixed, thanks. >> >> >>> - will clients who extended ZCompressorInputStream be affected by the >> >>> change in it's superclass hierarchy? In other words, is the change to >> >>> ZCompressorInputStream reported by clirr binary compatible with 1.9? >> >> >>> The last one would be a blocker for me. It could be resolved by >> restoring >> >>> the _internal_ package and deprecate it right away. >> >> >> It is reported as not compatible, so yes, we are breaking backwards >> >> compatibility. >> >> > Note that Clirr does not distinguish binary and source compatibility. >> > Breaking binary compatibility is almost never a good idea. >> > However source compatibility may be less important in some cases. >> >> > Which incompatibility is it? >> >> The superclass of ZCompressorInputStream has changed from one we've >> removed with the old __internal__ package to a new one in the now >> supported lzw package. >> > > Well, we cannot break BC in a minor release for a public class. Are we > sure BC breaks? > > If we want to make this internal package public, it needs to be copied to > the new location, not moved. Then ZCompressorInputStream would still extend > the internal package.
Not necessarily - that needs to be checked. Clearly if an accessible method or field has been dropped, or changed, then it won't be BC. But if the class or its superclasses still provides the original protected and public methods and members, it may still be BC. The JLS [1] has this to say: "Changing the direct superclass or the set of direct superinterfaces of a class type will not break compatibility with pre-existing binaries, provided that the total set of superclasses or superinterfaces, respectively, of the class type loses no members. " Given that the original super-class was internal, there is no need to allow for any direct references to it, e.g. in "instanceof" (which I imagine would fail BC). [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.4.4 > Gary > > >> >> Stefan >> >> --------------------------------------------------------------------- >> 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 > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > 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
