Instead of flooding two mailing lists, please open a bug report that requests to update https://wiki.eclipse.org/Evolving_Java-based_APIs_2. Markus Keller was working on that but did not yet update the wiki. You can assign the bug to him.
Dani From: "Andrey Loskutov" <[email protected]> To: [email protected] Cc: Cross project issues <[email protected]> Date: 16.06.2016 10:10 Subject: Re: [platform-ui-dev] [cross-project-issues-dev] Adding new default method to existing interface Sent by: [email protected] 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 _______________________________________________ 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
