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
