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.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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
