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

[Doug Schaefer <dschaefer@xxxxxxxxxxxxxx>]

Of course, I missed the footnote.

Default methods are a must. It’s why they are there. I’m using them all over the place as I message the API for the new things I’m working on. And since it’s new things, I don’t expect to run into any issues with people actually needing backwards compatibility since I don’t think anyone is using this stuff except for QNX which is building against master.

Doug.

From: Doug Schaefer <dschaefer@xxxxxxxxxxxxxx>
Date: Monday, September 19, 2016 at 11:40 AM
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] Adding default methods to interfaces, what's CDT's policy?

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> on behalf of Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: Monday, September 19, 2016 at 11:36 AM
To: "cdt-dev@xxxxxxxxxxx" <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.