Thanks Mickael, this is definitely nice presentation but is neither "official" no guideline for Eclipse projects.
My goal is to have a clear guideline stated in the Wiki, because in my concrete use case I need to know what can we do in Platform UI with our API's and what should we avoid to do with them :-). Kind regards, Andrey Loskutov http://google.com/+AndreyLoskutov > Gesendet: Donnerstag, 16. Juni 2016 um 14:47 Uhr > Von: "Mikaël Barbero" <[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 > > 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 > > _______________________________________________ > 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
