Re: [cdt-dev] Adding default methods to interfaces, what's CDT's policy?

[Doug Schaefer <dschaefer@xxxxxxxxxxxxxx>]

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
>
>