Removing a checked exception can affect source compatibility, for example, if that particular exception is caught in a try block and nothing else in the try block can throw the exception. Or at least that's how I remember it I think.
On 29 May 2017 at 06:05, Nicolas Lalevée <nicolas.lale...@hibnet.org> wrote: > > > Le 29 mai 2017 à 11:46, Jan Matèrne (jhm) <apa...@materne.de> a écrit : > > > > Sounds like I would do ;) > > I'll merge the PR locally and insert the delegates. > > > > Open is > > "src/java/org/apache/ivy/osgi/util/Version.java: > > the constructor removes the (IMO unneccessary) ParseException. > > But because it is a checked Exception we break BC." > > > > https://wiki.eclipse.org/Evolving_Java-based_APIs_2 defines the removal > of a checked exception: > > "Breaks compatibility" > > "Adding and deleting checked exceptions declared as thrown by an API > method > > does not break binary compatibility; however, > > it breaks contract compatibility (and source code compatibility)." > > > > What do we want? > > Thanks for the link, I’ll bookmark it. > > Then I am OK with that. The Ivy jar can still be a upgraded without > worries, and if somebody compile against it, then he has the source so he > can modify them. > > I am OK with that also because having stricter compatibility rules will be > painful considering the wide API Ivy is exposing. > > Nicolas > > > > > > > > > Jan > > > >> -----Ursprüngliche Nachricht----- > >> Von: J Pai [mailto:jai.forums2...@gmail.com] > >> Gesendet: Montag, 29. Mai 2017 10:26 > >> An: Ant Developers List > >> Betreff: Re: PR-33: problems > >> > >> IMO, for each of these public classes/methods/fields that we are fixing > >> for typos, we should mark them @Deprecated (and add a @deprecated > >> javadoc too and point to the new field/method/class) and introduce the > >> rightly named class/method/field. For methods it’s straightforward, the > >> deprecated method internally calls the new method. For fields too it’s > >> straightforward. The deprecated field uses the value of the new field. > >> For classes, I think we can copy over the existing class into the new > >> one and leave around the existing one just for possible external > >> references (that we can’t control off) and migrate all internal > >> references to the new one. > >> > >> At some point, in some future version of Ivy, we remove/delete these > >> deprecated method/field/class. > >> > >> > >> -Jaikiran > >> > >> > >> On 29-May-2017, at 1:43 PM, Jan Matèrne <j...@materne.de> wrote: > >> > >> I did a review of <https://github.com/apache/ant-ivy/pull/33> > >> https://github.com/apache/ant-ivy/pull/33 > >> > >> Here are the points I have problems with, so I want to discuss them > >> here. > >> > >> Basically it's about breaking BC. So how to deal with that? > >> > >> > >> > >> > >> > >> Jan > >> > >> > >> > >> > >> > >> Fixing the spell error in DelegateHandler$ChildElementHandler > >> (s/childHanlded/childHandled/) means breaking beakward compatiblity. > >> > >> We could introduce a delegetate for that: > >> > >> /** for BC */ > >> > >> @Deprecated > >> > >> public void childHanlded(DH child) throws SAXParseException { > >> > >> childHandled(DH child); > >> > >> } > >> > >> While refactoring you have renamed all occurences in the Ivy codebase. > >> > >> On the other hand I don't know the impact (maybe outside of Ivy). I'll > >> bring that to the dev-list. > >> > >> > >> > >> > >> > >> src/java/org/apache/ivy/osgi/repo/FSManifestIterable.java: renaming the > >> public constant DEFAULT_BUNLDE_FILTER also means breaking BC. > >> > >> > >> > >> > >> > >> src/java/org/apache/ivy/osgi/util/Version.java: the constructor removes > >> the (IMO unneccessary) ParseException. But because it is a checked > >> Exception we break BC. > >> > >> > >> > >> > >> > >> renaming EncrytedProperties to EncryptedProperties means breaking BC. > >> If required we could introduce a delegating class or a subclass. > >> > >> > >> > >> > >> > >> ArtifactOrigin: renaming unkwnown() to unknown() means breaking BC. If > >> required we could introduce a delegating method. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional > >> commands, e-mail: dev-h...@ant.apache.org > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > > For additional commands, e-mail: dev-h...@ant.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > > -- Matt Sicker <boa...@gmail.com>
