Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Adding default methods to interfaces, what's CDT's policy?

What if the method added to the abstract class has the same signature as one that is part of an extending class, but with a different return value?

Won't that break things?  But we don't worry about that as it a low risk.  I am hoping we treat default methods the same...




From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Alexandre Montplaisir <alexmonthy@xxxxxxxxxxxx>
Sent: September 19, 2016 12:45 PM
To: Doug Schaefer
Cc: CDT General developers list.
Subject: 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



Back to the top