| Re: [cdt-dev] Adding default methods to interfaces, what's CDT's policy? |
|
Can we wait until PDE adds the settings to ignore those instead of adding API filters? Going back to delete API filters might be error prone.
Marc-Andre From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Marc Khouzam
Sent: Friday, September 23, 2016 10:02:30 AM To: CDT General developers list. Subject: Re: [cdt-dev] Adding default methods to interfaces, what's CDT's policy? I gather we agree that CDT's policy should be that:
- adding default methods to interfaces is allowed in a minor release
and API filters should be used to remove the error shown by the API tool. With this in mind, I will be pushing a patch for such filters for master to get rid of the last API errors.
Marc From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Doug Schaefer <dschaefer@xxxxxxxxxxxxxx>
Sent: September 19, 2016 2:45 PM To: Alexandre Montplaisir Cc: CDT General developers list. Subject: Re: [cdt-dev] Adding default methods to interfaces, what's CDT's policy? My point is that in practice, the probability of API breakage is very low
using default methods. Of course you don¹t want to over use them, but if you have to, they¹re a way out. On 2016-09-19, 12:45 PM, "Alexandre Montplaisir" <alexmonthy@xxxxxxxxxxxx> wrote: >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_Interfac >>es >> >> 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 > > _______________________________________________ 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 |