| Re: [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 <loskutov@xxxxxx> 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 > cross-project-issues-dev@xxxxxxxxxxx > To change your delivery options, retrieve your password, or unsubscribe from this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail