| Re: [cdt-dev] Adding default methods to interfaces, what's CDT's policy? |
Hi Doug, Classes can only extend one other class, so adding a method to an abstract class cannot cause conflicts. Classes may implement more than one interface though, so adding a method to an interface may indeed cause a name clash. Still, I think it is very overkill to consider this the same type of breakage as adding an abstract method... Cheers, Alexandre On 2016-09-19 11:40 AM, Doug Schaefer wrote: > I want to know why that’s true and “Add abstract method, If method need not be implemented by Client” is compatible. Seems like the same thing to me. > > From: <cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx>> on behalf of Marc Khouzam <marc.khouzam@xxxxxxxxxxxx<mailto:marc.khouzam@xxxxxxxxxxxx>> > Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>> > Date: Monday, September 19, 2016 at 11:36 AM > To: "cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>" <cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>> > Subject: [cdt-dev] Adding default methods to interfaces, what's CDT's policy? > > > Hi, > > > according to > > https://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_Interfaces > > adding a default method to an existing interface (that is implementable), > > is a breaking API change. The rule does provide an 'exception' if the benefit is felt > > to outweigh the risk. See below for explanation. > > > I find using default method makes the code much simpler (avoiding interface2, interface3, interface4, etc). > > > What do others feel we should do? Should it be on a case-by-case basis (I find that hard to establish)? > > Or should we have a recommended, or allowed approach? > > > Thanks > > > P.S. We have such changes in 9.2 > > > P.P.S. The explanation from that wiki about why the default breaks the API. > > > (8) Adding a default method will break an existing client type if it already implements another interface that declares a default method with a matching signature, and the client type already refers to the default method from the other interface (except when using the Interface.super.method() notation). The added default method will cause an IncompatibleClassChangeError at run time, see JLS8 13.5.6 (http://docs.oracle.com/javase/specs/jls/se8/html/jls-13.html#jls-13.5.6). Furthermore, re-compiling the type will result in a compile error. > > In cases where the risk of multiple inheritance of the same method from multiple interfaces is deemed low and the added value is deemed sufficiently high, selected default methods can be added to existing interfaces. However, such a change should only be applied in an early milestone, and it should be reverted if clients report any difficulties with the change. > > > > > _______________________________________________ > cdt-dev mailing list > cdt-dev@xxxxxxxxxxx > To change your delivery options, retrieve your password, or unsubscribe from this list, visit > https://dev.eclipse.org/mailman/listinfo/cdt-dev
Attachment:
signature.asc
Description: OpenPGP digital signature