You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2018/03/29 14:51:34 UTC
[collections] breaking changes
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
Re: [collections] breaking changes
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Mar 31, 2018 at 6:52 AM, Gary Gregory <ga...@gmail.com>
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 <cl...@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 <db...@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.asert@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 <se...@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 <ga...@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.asert@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 <
>> >>>>>>> garydgregory@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 <cl...@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 <
>> >>>>>>>>>
>> >>>>>>>> garydgregory@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-unsubscribe@commons.apache.org
>> >>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> ------------------------------------------------------------
>> >>>>> ---------
>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>>>
>> >>>>>
>> >>>>> ------------------------------------------------------------
>> ---------
>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@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
>>
>
Re: [collections] breaking changes
Posted by Gary Gregory <ga...@gmail.com>.
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 <cl...@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 <db...@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 <pa...@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 <se...@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 <ga...@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.asert@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 <
> >>>>>>> garydgregory@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 <cl...@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 <
> >>>>>>>>>
> >>>>>>>> garydgregory@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-unsubscribe@commons.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>> ------------------------------------------------------------
> >>>>> ---------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@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
>
Re: [collections] breaking changes
Posted by Claude Warren <cl...@xenei.com>.
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 <db...@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 <pa...@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 <se...@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 <ga...@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.asert@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 <
>>>>>>> garydgregory@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 <cl...@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 <
>>>>>>>>>
>>>>>>>> garydgregory@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-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>> ---------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@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
Re: [collections] breaking changes
Posted by Dave Brosius <db...@baybroadband.net>.
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 <pa...@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/codehaus/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 <se...@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 <ga...@gmail.com> wrote:
>>>>> Yep, that's no good. I'll revert.
>>>>>
>>>>> Gary
>>>>>
>>>>> On Thu, Mar 29, 2018 at 10:16 AM, Paul King <pa...@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 <ga...@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 <cl...@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 <
>>>> garydgregory@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-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collections] breaking changes
Posted by Paul King <pa...@gmail.com>.
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 <pa...@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/codehaus/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 <se...@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 <ga...@gmail.com> wrote:
>>> > Yep, that's no good. I'll revert.
>>> >
>>> > Gary
>>> >
>>> > On Thu, Mar 29, 2018 at 10:16 AM, Paul King <pa...@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 <ga...@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 <cl...@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 <
>>> garydgregory@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-unsubscribe@commons.apache.org
>>> >> For additional commands, e-mail: dev-help@commons.apache.org
>>> >>
>>> >>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collections] breaking changes
Posted by Paul King <pa...@gmail.com>.
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/codehaus/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 <se...@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 <ga...@gmail.com> wrote:
>> > Yep, that's no good. I'll revert.
>> >
>> > Gary
>> >
>> > On Thu, Mar 29, 2018 at 10:16 AM, Paul King <pa...@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 <ga...@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 <cl...@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 <
>> garydgregory@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-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collections] breaking changes
Posted by Peter Burka <pe...@quux.net>.
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 <se...@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 <ga...@gmail.com> wrote:
> > Yep, that's no good. I'll revert.
> >
> > Gary
> >
> > On Thu, Mar 29, 2018 at 10:16 AM, Paul King <pa...@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 <ga...@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 <cl...@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 <
> garydgregory@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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [collections] breaking changes
Posted by sebb <se...@gmail.com>.
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 <ga...@gmail.com> wrote:
> Yep, that's no good. I'll revert.
>
> Gary
>
> On Thu, Mar 29, 2018 at 10:16 AM, Paul King <pa...@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 <ga...@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 <cl...@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 <ga...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collections] breaking changes
Posted by Gary Gregory <ga...@gmail.com>.
Yep, that's no good. I'll revert.
Gary
On Thu, Mar 29, 2018 at 10:16 AM, Paul King <pa...@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 <ga...@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 <cl...@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 <ga...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [collections] breaking changes
Posted by Paul King <pa...@gmail.com>.
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 <ga...@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 <cl...@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 <ga...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collections] breaking changes
Posted by Gary Gregory <ga...@gmail.com>.
Can you show how older code would not function. Aside from using reflection.
Gary
On Thu, Mar 29, 2018, 09:03 Claude Warren <cl...@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 <ga...@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
>
Re: [collections] breaking changes
Posted by Claude Warren <cl...@xenei.com>.
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 <ga...@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