It has to be as “Adding method to the public class”. See the following bug for
an example of how adding a seemingly-innocuous default method caused issues
downstream:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=477779#c3
I don’t think it would be a runtime problem though.
Brian.
> On 16-Jun-2016, at 8:47 AM, Mikaël Barbero <mik...@eclipse.org> wrote:
>
> Hi Andrey,
>
> You may be interested in John's presentation about API design with Java 8
> https://jarthorn.github.io/EclipseCon2014/java8/.
>
> Cheers,
> Mikael
>
>> Le 16 juin 2016 à 13:59, Andrey Loskutov <losku...@gmx.de> a écrit :
>>
>> Hi all,
>>
>> I'm trying to understand if "adding default method to interface" API change
>> is binary compatible for Eclipse project or not?
>>
>> I've just checked [1] and have not found a hint how should we deal with the
>> new "default" methods (Java 8) added to the existing interfaces.
>>
>> Are we considering this as "Add API method -> If method need not be
>> implemented by Client -> Binary compatible (0)" case from [1]?
>>
>> Or do we threat this case as "Adding method to the public class" from [2],
>> which has a very detailed but fuzzy example which says basically "yes and
>> not", quote:
>>
>> "However, if the method is added to a class which Clients may subclass, then
>> the change should ordinarily be viewed as a breaking change. The reason for
>> this harsh conclusion is because of the possibility that a Client's subclass
>> already has its own implementation of a method by that name. Adding the API
>> method to the superclass undercuts the Client's code since it would be sheer
>> coincidence if the Client's existing method met the API contract of the
>> newly added method. In practice, if the likelihood of this kind of name
>> coincidence is sufficiently low, this kind of change is often treated as if
>> it were non-breaking."
>>
>> So which way do we like to deal with that?
>>
>> I personally would love to see this change as "binary compatible", because
>> this would allow easier interface evolution.
>>
>> It would be nice to extend the guideline [1] by explicitly adding this case:
>> "Add API method -> If the new method has "default" qualifier (Java 8) ->
>> Binary compatible (0)"
>>
>> Also if this is true, and we consider this case as binary compatible, how
>> about the existing guideline regarding "numbered" interfaces? (Example:
>> IPerspectiveListener4 extends IPerspectiveListener3 extends
>> IPerspectiveListener2 extends IPerspectiveListener)
>>
>> Would we then also change this and allow interface evolution with new
>> *default* methods without creating new interface?
>>
>> See also Oracle guideline which strictly speaking says: it will be binary
>> compatible but *can* in theory lead to runtime issues [3].
>>
>> [1]
>> https://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_Interfaces
>> [2]
>> https://wiki.eclipse.org/Evolving_Java-based_APIs#Example_4_-_Adding_an_API_method
>> [3] https://docs.oracle.com/javase/specs/jls/se8/html/jls-13.html#jls-13.5.6
>>
>> Kind regards,
>> Andrey Loskutov
>>
>> http://google.com/+AndreyLoskutov
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe from
>> this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
