[collections] breaking changes

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[collections] breaking changes

garydgregory
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
Reply | Threaded
Open this post in threaded view
|

Re: [collections] breaking changes

Claude Warren
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 <[hidden email]>
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
Reply | Threaded
Open this post in threaded view
|

Re: [collections] breaking changes

garydgregory
Can you show how older code would not function. Aside from using reflection.

Gary

On Thu, Mar 29, 2018, 09:03 Claude Warren <[hidden email]> 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 <[hidden email]>
> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [collections] breaking changes

Paul King-2
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 <[hidden email]> wrote:

> Can you show how older code would not function. Aside from using reflection.
>
> Gary
>
> On Thu, Mar 29, 2018, 09:03 Claude Warren <[hidden email]> 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 <[hidden email]>
>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] breaking changes

garydgregory
Yep, that's no good. I'll revert.

Gary

On Thu, Mar 29, 2018 at 10:16 AM, Paul King <[hidden email]>
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 <[hidden email]>
> wrote:
> > Can you show how older code would not function. Aside from using
> reflection.
> >
> > Gary
> >
> > On Thu, Mar 29, 2018, 09:03 Claude Warren <[hidden email]> 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 <[hidden email]>
> >> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [collections] breaking changes

sebb-2-2
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 <[hidden email]> wrote:

> Yep, that's no good. I'll revert.
>
> Gary
>
> On Thu, Mar 29, 2018 at 10:16 AM, Paul King <[hidden email]>
> 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 <[hidden email]>
>> wrote:
>> > Can you show how older code would not function. Aside from using
>> reflection.
>> >
>> > Gary
>> >
>> > On Thu, Mar 29, 2018, 09:03 Claude Warren <[hidden email]> 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 <[hidden email]>
>> >> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] breaking changes

Peter Burka
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 <[hidden email]> 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 <[hidden email]> wrote:
> > Yep, that's no good. I'll revert.
> >
> > Gary
> >
> > On Thu, Mar 29, 2018 at 10:16 AM, Paul King <[hidden email]>
> > 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 <[hidden email]>
> >> wrote:
> >> > Can you show how older code would not function. Aside from using
> >> reflection.
> >> >
> >> > Gary
> >> >
> >> > On Thu, Mar 29, 2018, 09:03 Claude Warren <[hidden email]> 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 <
> [hidden email]>
> >> >> 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: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [collections] breaking changes

Paul King-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>> > Yep, that's no good. I'll revert.
>> >
>> > Gary
>> >
>> > On Thu, Mar 29, 2018 at 10:16 AM, Paul King <[hidden email]>
>> > 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 <[hidden email]>
>> >> wrote:
>> >> > Can you show how older code would not function. Aside from using
>> >> reflection.
>> >> >
>> >> > Gary
>> >> >
>> >> > On Thu, Mar 29, 2018, 09:03 Claude Warren <[hidden email]> 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 <
>> [hidden email]>
>> >> >> 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: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] breaking changes

Paul King-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>> > Yep, that's no good. I'll revert.
>>> >
>>> > Gary
>>> >
>>> > On Thu, Mar 29, 2018 at 10:16 AM, Paul King <[hidden email]>
>>> > 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 <[hidden email]>
>>> >> wrote:
>>> >> > Can you show how older code would not function. Aside from using
>>> >> reflection.
>>> >> >
>>> >> > Gary
>>> >> >
>>> >> > On Thu, Mar 29, 2018, 09:03 Claude Warren <[hidden email]> 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 <
>>> [hidden email]>
>>> >> >> 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: [hidden email]
>>> >> For additional commands, e-mail: [hidden email]
>>> >>
>>> >>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] breaking changes

dbrosIus
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>> Yep, that's no good. I'll revert.
>>>>>
>>>>> Gary
>>>>>
>>>>> On Thu, Mar 29, 2018 at 10:16 AM, Paul King <[hidden email]>
>>>>> 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 <[hidden email]>
>>>>>> wrote:
>>>>>>> Can you show how older code would not function. Aside from using
>>>>>> reflection.
>>>>>>> Gary
>>>>>>>
>>>>>>> On Thu, Mar 29, 2018, 09:03 Claude Warren <[hidden email]> 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 <
>>>> [hidden email]>
>>>>>>>> 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: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] breaking changes

Claude Warren
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 <[hidden email]>
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 <[hidden email]>
>> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> Yep, that's no good. I'll revert.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Thu, Mar 29, 2018 at 10:16 AM, Paul King <
>>>>>> [hidden email]>
>>>>>> 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 <
>>>>>>> [hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Can you show how older code would not function. Aside from using
>>>>>>>>
>>>>>>> reflection.
>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>> On Thu, Mar 29, 2018, 09:03 Claude Warren <[hidden email]> 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 <
>>>>>>>>>
>>>>>>>> [hidden email]>
>>>>>
>>>>>> 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: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>> ---------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Reply | Threaded
Open this post in threaded view
|

Re: [collections] breaking changes

garydgregory
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> >> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> >>>>> wrote:
> >>>>>
> >>>>>> Yep, that's no good. I'll revert.
> >>>>>>
> >>>>>> Gary
> >>>>>>
> >>>>>> On Thu, Mar 29, 2018 at 10:16 AM, Paul King <
> >>>>>> [hidden email]>
> >>>>>> 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 <
> >>>>>>> [hidden email]>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Can you show how older code would not function. Aside from using
> >>>>>>>>
> >>>>>>> reflection.
> >>>>>>>
> >>>>>>>> Gary
> >>>>>>>>
> >>>>>>>> On Thu, Mar 29, 2018, 09:03 Claude Warren <[hidden email]>
> 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 <
> >>>>>>>>>
> >>>>>>>> [hidden email]>
> >>>>>
> >>>>>> 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: [hidden email]
> >>>>>>> For additional commands, e-mail: [hidden email]
> >>>>>>>
> >>>>>>>
> >>>>>>> ------------------------------------------------------------
> >>>>> ---------
> >>>>> To unsubscribe, e-mail: [hidden email]
> >>>>> For additional commands, e-mail: [hidden email]
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> I like: Like Like - The likeliest place on the web
> <http://like-like.xenei.com>
> LinkedIn: http://www.linkedin.com/in/claudewarren
>
Reply | Threaded
Open this post in threaded view
|

Re: [collections] breaking changes

garydgregory
On Sat, Mar 31, 2018 at 6:52 AM, Gary Gregory <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]
>> >
>> >> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> Yep, that's no good. I'll revert.
>> >>>>>>
>> >>>>>> Gary
>> >>>>>>
>> >>>>>> On Thu, Mar 29, 2018 at 10:16 AM, Paul King <
>> >>>>>> [hidden email]>
>> >>>>>> 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 <
>> >>>>>>> [hidden email]>
>> >>>>>>> wrote:
>> >>>>>>>
>> >>>>>>>> Can you show how older code would not function. Aside from using
>> >>>>>>>>
>> >>>>>>> reflection.
>> >>>>>>>
>> >>>>>>>> Gary
>> >>>>>>>>
>> >>>>>>>> On Thu, Mar 29, 2018, 09:03 Claude Warren <[hidden email]>
>> 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 <
>> >>>>>>>>>
>> >>>>>>>> [hidden email]>
>> >>>>>
>> >>>>>> 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: [hidden email]
>> >>>>>>> For additional commands, e-mail: [hidden email]
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> ------------------------------------------------------------
>> >>>>> ---------
>> >>>>> To unsubscribe, e-mail: [hidden email]
>> >>>>> For additional commands, e-mail: [hidden email]
>> >>>>>
>> >>>>>
>> >>>>> ------------------------------------------------------------
>> ---------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>>
>>
>> --
>> I like: Like Like - The likeliest place on the web
>> <http://like-like.xenei.com>
>> LinkedIn: http://www.linkedin.com/in/claudewarren
>>
>