Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] request for API change exemption in M7

I'll guess in a different direction. Adding constants only results in name conflicts at compile time. At run-time everything magically works so old jar files will work against the new interfaces with the additional constants. That's what I've believed for a long time and the API tooling seemed to confirm. Never made me increase the major version when doing that.

On Fri, Apr 8, 2016 at 2:29 PM, Oberhuber, Martin <Martin.Oberhuber@xxxxxxxxxxxxx> wrote:
Hi Marc,

> Is it because someone extending the interface could already be using that name?

I think that's exactly the reason. See footnote 2 here:
https://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_Interfaces
"Interfaces that are defined to be implemented by clients should not include fields (==constants) at all"

If you can mark your interface @noimplement, then adding a field (==constant) would not be breaking binary compatibility.
Changing the value of the constant however, might break binary compatibility in case the constant can be used at compile time.

Martin





On 08/04/16 15:21, "cdt-dev-bounces@xxxxxxxxxxx on behalf of Marc Khouzam" <cdt-dev-bounces@xxxxxxxxxxx on behalf of marc.khouzam@xxxxxxxxxxxx> wrote:

>+1
>
>I still don't get why adding a constant to an interface is a breaking change? (sorry if it was explained
>before and I forgot).
>Is it because someone extending the interface could already be using that name?
>If that's the case, then wouldn't adding a method to a public class be a problem also?
>________________________________________
>From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Jonah Graham [jonah@xxxxxxxxxxxxxxxx]
>Sent: April 8, 2016 8:41 AM
>To: CDT General developers list.
>Subject: [cdt-dev] request for API change exemption in M7
>
>Hi all,
>
>I am working with Stefan Sprenger on fixing http://eclip.se/487998. As
>part of that work we want to add a new attribute to a breakpoint.
>
>This requires an API change after M6 as we are adding a new constant
>to ICLineBreakpoint2 [1].
>
>I would like an exemption for this API change ahead of M7. See [1] for
>the exact API change.
>
>Note that the review is not yet finished and Marc K has suggested
>pushing just the ICLineBreakpoint2 part of the change if it looks like
>we are going to have trouble finishing the whole review before M7.
>
>Thanks,
>Jonah
>
>
>[1] https://git.eclipse.org/r/#/c/69374/2/debug/org.eclipse.cdt.debug.core/src/org/eclipse/cdt/debug/core/model/ICLineBreakpoint2.java
>
>
>~~~
>Jonah Graham
>Kichwa Coders Ltd.
>www.kichwacoders.com
>_______________________________________________
>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
_______________________________________________
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