osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [collections] breaking changes


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 <garydgregory@xxxxxxxxx> wrote:
> Yep, that's no good. I'll revert.
>
> Gary
>
> On Thu, Mar 29, 2018 at 10:16 AM, Paul King <paul.king.asert@xxxxxxxxx>
> 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 <garydgregory@xxxxxxxxx>
>> wrote:
>> > Can you show how older code would not function. Aside from using
>> reflection.
>> >
>> > Gary
>> >
>> > On Thu, Mar 29, 2018, 09:03 Claude Warren <claude@xxxxxxxxx> 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 <garydgregory@xxxxxxxxx>
>> >> 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-unsubscribe@xxxxxxxxxxxxxxxxxx
>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx