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