The return type is part of the method signature that Java uses to find resolve references.
Even changing from void to non-void will cause binary incompatibility. (Source-wise, that's fine) On 29 March 2018 at 18:20, Gary Gregory <garydgreg...@gmail.com> wrote: > Yep, that's no good. I'll revert. > > Gary > > On Thu, Mar 29, 2018 at 10:16 AM, Paul King <paul.king.as...@gmail.com> > wrote: > >> I haven't looked into the IteratorUtils class at all but it's easy to >> show binary incompatibility when changing the return type. >> Compile this "library" class: >> >> import java.util.ArrayList; >> import java.util.List; >> >> public class Lib { >> List getMyList() { >> return new ArrayList(); >> } >> } >> >> Now compile this user of the library: >> >> import java.util.List; >> >> public class Main { >> public static void main(String[] args) { >> doit(new Lib().getMyList()); >> } >> >> private static void doit(List list) { >> System.out.println("list is: " + list); >> } >> } >> >> >> Ensure it all works: >> >> > java -cp path_to_lib Main >> >> Should output: >> >> List is: [] >> >> Now change the Lib class to return ArrayList instead of List and >> recompile just the Lib class (i.e. importantly don't recompile Main). >> >> Now if you try: >> >> > java -cp path_to_lib Main >> >> you should see: >> >> Exception in thread "main" java.lang.NoSuchMethodError: >> Lib.getMyList()Ljava/util/List; >> at Main.main(Main.java:5) >> >> Cheers, Paul. >> >> On Fri, Mar 30, 2018 at 1:41 AM, Gary Gregory <garydgreg...@gmail.com> >> wrote: >> > Can you show how older code would not function. Aside from using >> reflection. >> > >> > Gary >> > >> > On Thu, Mar 29, 2018, 09:03 Claude Warren <cla...@xenei.com> wrote: >> > >> >> if we are using semantic numbering would this not cause a major revision >> >> change as older code will no longer function? >> >> >> >> Claude >> >> >> >> On Thu, Mar 29, 2018 at 3:51 PM, Gary Gregory <garydgreg...@gmail.com> >> >> wrote: >> >> >> >> > Hi All: >> >> > >> >> > Updating Commons Collections' commons-parent from version 43 to 45 >> causes >> >> > the build to fail due to the use of japicmp which reports: >> >> > >> >> > [ERROR] Failed to execute goal >> >> > org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on >> >> > project commons-collections4: Error generating >> >> > japicmp-maven-plugin:0.11.0:cmp-report report: Failed to generate >> report: >> >> > Breaking the build because there is at least one incompatibility: >> >> > org.apache.commons.collections4.IteratorUtils. >> peekingIterator(java.util. >> >> > Iterator):METHOD_RETURN_TYPE_CHANGED,org.apache.commons. >> >> > collections4.IteratorUtils.pushbackIterator(java.util. >> >> > Iterator):METHOD_RETURN_TYPE_CHANGED >> >> > -> [Help 1] >> >> > >> >> > This is caused by: >> >> > >> >> > - [COLLECTIONS-676] Modify IteratorUtils.pushbackIterator signature to >> >> > return PushbackIterator. >> >> > - [COLLECTIONS-675] Modify IteratorUtils.peekingIterator signature to >> >> > return PeekingIterator. >> >> > >> >> > Which are reasonable changes IMO. >> >> > >> >> > Does anyone object to these changes and adding exceptions to allow >> >> japicmp >> >> > to >> >> > not fail the build? >> >> > >> >> > Thank you, >> >> > Gary >> >> > >> >> >> >> >> >> >> >> -- >> >> I like: Like Like - The likeliest place on the web >> >> <http://like-like.xenei.com> >> >> LinkedIn: http://www.linkedin.com/in/claudewarren >> >> >> >> --------------------------------------------------------------------- >> 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