This could be solved if it were possible to force javac to generate bridge
methods. There's an extension which would allow that here:
https://github.com/infradna/bridge-method-injector, but I suspect it would
complicate the build process quite a bit.
On Thu, Mar 29, 2018 at 4:48 PM sebb <seb...@gmail.com> wrote:
> 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
>
>
