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