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
