osdir.com

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

Re: [collections] breaking changes


Just to clarify, when I said "It's built with gradle and uses Ant", I
mean our build is gradle based and our call of Bridger uses Ant.
Bridger itself is built with Maven.

On Fri, Mar 30, 2018 at 12:20 PM, Paul King <paul.king.asert@xxxxxxxxx> wrote:
> In the Groovy build we do this using Bridger
> (https://github.com/dmlloyd/bridger). It's built with gradle (and uses
> Ant). They have a Maven plugin but I haven't used it.
>
> In our build we have this:
>
> compileJava {
>     doLast {
>         ant.java(classname:'org.jboss.bridger.Bridger', classpath:
> rootProject.configurations.tools.asPath, outputproperty: 'stdout') {
>             arg(value:
> "${sourceSets.main.java.outputDir.canonicalPath}/org/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 <peter@xxxxxxxx> wrote:
>> This could be solved if it were possible to force javac to generate bridge
>> methods. There's an extension which would allow that here:
>> https://github.com/infradna/bridge-method-injector, but I suspect it would
>> complicate the build process quite a bit.
>>
>> On Thu, Mar 29, 2018 at 4:48 PM sebb <sebbaz@xxxxxxxxx> wrote:
>>
>>> The return type is part of the method signature that Java uses to find
>>> resolve references.
>>>
>>> Even changing from void to non-void will cause binary incompatibility.
>>> (Source-wise, that's fine)
>>>
>>> On 29 March 2018 at 18:20, Gary Gregory <garydgregory@xxxxxxxxx> wrote:
>>> > Yep, that's no good. I'll revert.
>>> >
>>> > Gary
>>> >
>>> > On Thu, Mar 29, 2018 at 10:16 AM, Paul King <paul.king.asert@xxxxxxxxx>
>>> > wrote:
>>> >
>>> >> I haven't looked into the IteratorUtils class at all but it's easy to
>>> >> show binary incompatibility when changing the return type.
>>> >> Compile this "library" class:
>>> >>
>>> >> import java.util.ArrayList;
>>> >> import java.util.List;
>>> >>
>>> >> public class Lib {
>>> >>     List getMyList() {
>>> >>         return new ArrayList();
>>> >>     }
>>> >> }
>>> >>
>>> >> Now compile this user of the library:
>>> >>
>>> >> import java.util.List;
>>> >>
>>> >> public class Main {
>>> >>     public static void main(String[] args) {
>>> >>         doit(new Lib().getMyList());
>>> >>     }
>>> >>
>>> >>     private static void doit(List list) {
>>> >>         System.out.println("list is: " + list);
>>> >>     }
>>> >> }
>>> >>
>>> >>
>>> >> Ensure it all works:
>>> >>
>>> >> > java -cp path_to_lib Main
>>> >>
>>> >> Should output:
>>> >>
>>> >> List is: []
>>> >>
>>> >> Now change the Lib class to return ArrayList instead of List and
>>> >> recompile just the Lib class (i.e. importantly don't recompile Main).
>>> >>
>>> >> Now if you try:
>>> >>
>>> >> > java -cp path_to_lib Main
>>> >>
>>> >> you should see:
>>> >>
>>> >> Exception in thread "main" java.lang.NoSuchMethodError:
>>> >> Lib.getMyList()Ljava/util/List;
>>> >>         at Main.main(Main.java:5)
>>> >>
>>> >> Cheers, Paul.
>>> >>
>>> >> On Fri, Mar 30, 2018 at 1:41 AM, Gary Gregory <garydgregory@xxxxxxxxx>
>>> >> wrote:
>>> >> > Can you show how older code would not function. Aside from using
>>> >> reflection.
>>> >> >
>>> >> > Gary
>>> >> >
>>> >> > On Thu, Mar 29, 2018, 09:03 Claude Warren <claude@xxxxxxxxx> wrote:
>>> >> >
>>> >> >> if we are using semantic numbering would this not cause a major
>>> revision
>>> >> >> change as older code will no longer function?
>>> >> >>
>>> >> >> Claude
>>> >> >>
>>> >> >> On Thu, Mar 29, 2018 at 3:51 PM, Gary Gregory <
>>> garydgregory@xxxxxxxxx>
>>> >> >> wrote:
>>> >> >>
>>> >> >> > Hi All:
>>> >> >> >
>>> >> >> > Updating Commons Collections' commons-parent from version 43 to 45
>>> >> causes
>>> >> >> > the build to fail due to the use of japicmp which reports:
>>> >> >> >
>>> >> >> > [ERROR] Failed to execute goal
>>> >> >> > org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site)
>>> on
>>> >> >> > project commons-collections4: Error generating
>>> >> >> > japicmp-maven-plugin:0.11.0:cmp-report report: Failed to generate
>>> >> report:
>>> >> >> > Breaking the build because there is at least one incompatibility:
>>> >> >> > org.apache.commons.collections4.IteratorUtils.
>>> >> peekingIterator(java.util.
>>> >> >> > Iterator):METHOD_RETURN_TYPE_CHANGED,org.apache.commons.
>>> >> >> > collections4.IteratorUtils.pushbackIterator(java.util.
>>> >> >> > Iterator):METHOD_RETURN_TYPE_CHANGED
>>> >> >> > -> [Help 1]
>>> >> >> >
>>> >> >> > This is caused by:
>>> >> >> >
>>> >> >> > - [COLLECTIONS-676] Modify IteratorUtils.pushbackIterator
>>> signature to
>>> >> >> > return PushbackIterator.
>>> >> >> > - [COLLECTIONS-675] Modify IteratorUtils.peekingIterator signature
>>> to
>>> >> >> > return PeekingIterator.
>>> >> >> >
>>> >> >> > Which are reasonable changes IMO.
>>> >> >> >
>>> >> >> > Does anyone object to these changes and adding exceptions to allow
>>> >> >> japicmp
>>> >> >> > to
>>> >> >> > not fail the build?
>>> >> >> >
>>> >> >> > Thank you,
>>> >> >> > Gary
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> I like: Like Like - The likeliest place on the web
>>> >> >> <http://like-like.xenei.com>
>>> >> >> LinkedIn: http://www.linkedin.com/in/claudewarren
>>> >> >>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
>>> >> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
>>> >>
>>> >>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
>>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
>>>
>>>

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