Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-ui-dev] Adding new default method to existing interface
It might be binary compatible because when a Java class is compiled, I suspect the compiler will "hardcode" a method implementation to whatever superclass or (unique) default implementation is available to that class from an interface. The contents of interface default methods don't really exist at runtime in the interface, rather they are plugged-in (mixed-in) into the class at compilation time.

I haven't verified this because I don't get is why any of this matters: Such a change can cause a compilation error, and as such it means you must increase the API major version regardless of whether it's binary compatible or not, no?


On 16 June 2016 at 12:59, Andrey Loskutov <loskutov@xxxxxx> wrote:
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
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev



--

Back to the top