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.
Gary On Sat, Mar 31, 2018, 03:24 Claude Warren <cla...@xenei.com> 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 <dbros...@baybroadband.net> > 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.as...@gmail.com> > >> 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 <pe...@quux.net> 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 <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 > >>>>> > >>>>> > >>>>> --------------------------------------------------------------------- > >> 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 > > > > > > > -- > I like: Like Like - The likeliest place on the web > <http://like-like.xenei.com> > LinkedIn: http://www.linkedin.com/in/claudewarren >
