Hi Brian, I mean a different case: adding *new* default methods, not adding "default" modifier to existing method on an interface.
The example of Bug 477779 fits to "Change abstract to non-abstract" and "Binary compatible" according to https://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_Classes. Source/runtime compatibility is different topic. Kind regards, Andrey Loskutov http://google.com/+AndreyLoskutov > Gesendet: Donnerstag, 16. Juni 2016 um 15:49 Uhr > Von: "Brian de Alwis" <[email protected]> > An: "Cross project issues" <[email protected]> > Cc: "Platform UI" <[email protected]> > Betreff: Re: [platform-ui-dev] [cross-project-issues-dev] Adding new default > method to existing interface > > It has to be as “Adding method to the public class”. See the following bug > for an example of how adding a seemingly-innocuous default method caused > issues downstream: > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=477779#c3 > > I don’t think it would be a runtime problem though. > > Brian. > > > On 16-Jun-2016, at 8:47 AM, Mikaël Barbero <[email protected]> wrote: > > > > Hi Andrey, > > > > You may be interested in John's presentation about API design with Java 8 > > https://jarthorn.github.io/EclipseCon2014/java8/. > > > > Cheers, > > Mikael > > > >> Le 16 juin 2016 à 13:59, Andrey Loskutov <[email protected]> a écrit : > >> > >> Hi all, > >> > >> I'm trying to understand if "adding default method to interface" API > >> change is binary compatible for Eclipse project or not? > >> > >> I've just checked [1] and have not found a hint how should we deal with > >> the new "default" methods (Java 8) added to the existing interfaces. > >> > >> Are we considering this as "Add API method -> If method need not be > >> implemented by Client -> Binary compatible (0)" case from [1]? > >> > >> Or do we threat this case as "Adding method to the public class" from [2], > >> which has a very detailed but fuzzy example which says basically "yes and > >> not", quote: > >> > >> "However, if the method is added to a class which Clients may subclass, > >> then the change should ordinarily be viewed as a breaking change. The > >> reason for this harsh conclusion is because of the possibility that a > >> Client's subclass already has its own implementation of a method by that > >> name. Adding the API method to the superclass undercuts the Client's code > >> since it would be sheer coincidence if the Client's existing method met > >> the API contract of the newly added method. In practice, if the likelihood > >> of this kind of name coincidence is sufficiently low, this kind of change > >> is often treated as if it were non-breaking." > >> > >> So which way do we like to deal with that? > >> > >> I personally would love to see this change as "binary compatible", because > >> this would allow easier interface evolution. > >> > >> It would be nice to extend the guideline [1] by explicitly adding this > >> case: > >> "Add API method -> If the new method has "default" qualifier (Java 8) -> > >> Binary compatible (0)" > >> > >> Also if this is true, and we consider this case as binary compatible, how > >> about the existing guideline regarding "numbered" interfaces? (Example: > >> IPerspectiveListener4 extends IPerspectiveListener3 extends > >> IPerspectiveListener2 extends IPerspectiveListener) > >> > >> Would we then also change this and allow interface evolution with new > >> *default* methods without creating new interface? > >> > >> See also Oracle guideline which strictly speaking says: it will be binary > >> compatible but *can* in theory lead to runtime issues [3]. > >> > >> [1] > >> https://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_Interfaces > >> [2] > >> https://wiki.eclipse.org/Evolving_Java-based_APIs#Example_4_-_Adding_an_API_method > >> [3] > >> https://docs.oracle.com/javase/specs/jls/se8/html/jls-13.html#jls-13.5.6 > >> > >> Kind regards, > >> Andrey Loskutov > >> > >> http://google.com/+AndreyLoskutov > >> _______________________________________________ > >> cross-project-issues-dev mailing list > >> [email protected] > >> To change your delivery options, retrieve your password, or unsubscribe > >> from this list, visit > >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > > _______________________________________________ > > cross-project-issues-dev mailing list > > [email protected] > > To change your delivery options, retrieve your password, or unsubscribe > > from this list, visit > > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > _______________________________________________ > platform-ui-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/platform-ui-dev _______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
