The bottom line is that new interface method in Collections 4.3 MUST be default methods to avoid blowing up code. This is possible since Collection now requires Java 8.
Gary On Mon, Jan 28, 2019 at 2:53 PM Rob Tompkins <chtom...@gmail.com> wrote: > > > > On Jan 28, 2019, at 2:35 PM, sebb <seb...@gmail.com> wrote: > > > > On Mon, 28 Jan 2019 at 19:22, Marcelo Vanzin > > <van...@cloudera.com.invalid> wrote: > >> > >> Haven't looked at the code, but if it's being compiled for java 8, and > >> the new methods have a default implementation, then it's fine. clirr > >> just complains because it's too old to know about default methods. > > > > I don't think so. > > > > I think Clirr is complaining because it affects source compatibility, > > and the Maven report does not distinguish source/binary complaints. > > > > By the way Japicmp says the same thing...that methods were added to > interfaces. > > > >>> On Mon, Jan 28, 2019 at 11:18 AM Rob Tompkins <chtom...@gmail.com> > wrote: > >>> > >>> @Marcelo - Many thanks...Yes. That makes sense. Thanks. Seems like > this release should be a -1 then because we’re breaking BC without a major > version change. Right?? > >>> > >>> -Rob > >>> > >>> > >>>> On Jan 28, 2019, at 2:07 PM, Marcelo Vanzin > <van...@cloudera.com.INVALID> wrote: > >>>> > >>>> On Mon, Jan 28, 2019 at 11:01 AM Rob Tompkins <chtom...@gmail.com> > wrote: > >>>>> Before I vote on the the thread, does adding a method to an > interface cause BC to break? I would think not. All of the clirr errors are > merely additions. Further the JAPICMP report confirms this. > >>>> > >>>> Existing classes that implement the interface won't have the newly > >>>> added method. So if some other code calls that method in one of these > >>>> implementations, they'll get an "AbstractMethodError" (or something > >>>> similar). > >>>> > >>>> -- > >>>> Marcelo > >>>> > >>>> --------------------------------------------------------------------- > >>>> 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 > >>> > >> > >> > >> -- > >> Marcelo > >> > >> --------------------------------------------------------------------- > >> 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 > >
