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?

I had in ming that people could stay on Eclipse 4.6 but I guess we should not discourage people from testing 4.7 in their daily work. +1 for the API filters.


From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>
Sent: Friday, September 23, 2016 10:34:57 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Adding default methods to interfaces, what's CDT's policy?
 

Considering that we don't know when PDE will be updated for this, and that we'd still need people to upgrade their API tooling for the new feature, I prefer to remove the errors now; having a problems view with no errors makes it faster than having to verify if the errors are the expected ones or new ones.



From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Marc-André Laperle <marc-andre.laperle@xxxxxxxxxxxx>
Sent: September 23, 2016 10:22 AM
To: CDT General developers list.
Subject: 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

Back to the top