OSDir


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

Re: [collections] breaking changes


On Sat, Mar 31, 2018 at 6:52 AM, Gary Gregory <garydgregory@xxxxxxxxx>
wrote:

> These two changes will happen when we go to version 5, the next major
> version, which will also change the package name and maven artifact ID.
> There are no other BC breaking changes ATM, so I took them out of master
> since the next release is 4.2.
>

FWIW, I'd like to see 4.2 release as soon as we release new versions our
build plugin and parent POM.

Gary

Gary
>
> On Sat, Mar 31, 2018, 03:24 Claude Warren <claude@xxxxxxxxx> wrote:
>
>> I have been of 2 minds on this.  On one side I think we move forward, bump
>> the number.
>>
>> on the other side is the part of me from my $dayjob that has to deal with
>> new versions and security alerts and make it all run on Java 6 (I'll not
>> bore you with the details here).
>>
>> Having flopped back and forth on this in my mind I finally come down on
>> the
>> side of keeping the changes bumping the version number.  We should not
>> stop
>> progress for fear of breaking some code (eggs and omelets) as long as we
>> are clear and clean.  Those that need new functionality but can't take all
>> the changes a re free to recompile as they need; as we will do at my
>> $dayjob.
>>
>> +1 bump the number and keep the functionality.
>> +2 if we clearly document where it breaks from earlier version ;)
>>
>> Claude
>>
>> On Sat, Mar 31, 2018 at 2:08 AM, Dave Brosius <dbrosius@xxxxxxxxxxxxxxxx>
>> wrote:
>>
>> > i'm not sure i follow, don't we already have breaking changes for which
>> > we've decided to change bump the version?
>> >
>> >
>> >
>> > On 03/29/2018 11:00 PM, Paul King wrote:
>> >
>> >> Just to clarify, when I said "It's built with gradle and uses Ant", I
>> >> mean our build is gradle based and our call of Bridger uses Ant.
>> >> Bridger itself is built with Maven.
>> >>
>> >> On Fri, Mar 30, 2018 at 12:20 PM, Paul King <paul.king.asert@xxxxxxxxx
>> >
>> >> wrote:
>> >>
>> >>> In the Groovy build we do this using Bridger
>> >>> (https://github.com/dmlloyd/bridger). It's built with gradle (and
>> uses
>> >>> Ant). They have a Maven plugin but I haven't used it.
>> >>>
>> >>> In our build we have this:
>> >>>
>> >>> compileJava {
>> >>>      doLast {
>> >>>          ant.java(classname:'org.jboss.bridger.Bridger', classpath:
>> >>> rootProject.configurations.tools.asPath, outputproperty: 'stdout') {
>> >>>              arg(value:
>> >>> "${sourceSets.main.java.outputDir.canonicalPath}/org/codehau
>> >>> s/groovy/runtime/DefaultGroovyMethods.class")
>> >>>          }
>> >>>          ant.echo('Bridger: ' + ant.properties.stdout)
>> >>>      }
>> >>> }
>> >>>
>> >>> And in the relevant source file we have a small number of $$bridge
>> >>> methods like this one:
>> >>>
>> >>> public static <T> List<T> withDefault$$bridge(List<T> self, Closure<T>
>> >>> init) {
>> >>>      return withDefault(self, init);
>> >>> }
>> >>>
>> >>> to match the original methods we are duplicating, e.g.:
>> >>>
>> >>> public static <T> ListWithDefault<T> withDefault(List<T> self,
>> >>> Closure<T> init) {
>> >>>      // ... code here ...
>> >>> }
>> >>>
>> >>> Cheers, Paul.
>> >>>
>> >>> On Fri, Mar 30, 2018 at 9:52 AM, Peter Burka <peter@xxxxxxxx> wrote:
>> >>>
>> >>>> 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 <sebbaz@xxxxxxxxx> 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 <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
>> >>>>>
>> >>>>>
>> >>>>> ------------------------------------------------------------
>> ---------
>> >> 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
>> >
>> >
>>
>>
>> --
>> I like: Like Like - The likeliest place on the web
>> <http://like-like.xenei.com>
>> LinkedIn: http://www.linkedin.com/in/claudewarren
>>
>