1

This SDK have an interface like this:

public interface Contract {
     void update(..);
     void action(..);
     void delete(..);
}

Now, we need to change it to something like this:

public interface Contract {
     String update(..);
     String action(..);
     String delete(..);
}

The interface is implemented internally by the SDK; that is not a problem. The question scope is beyond the case who somebody has implemented this interface too outside the SDK.

Does this change introduce a breaking change?

  • What do you mean by "The question scope is beyond the case who somebody has implemented this interface too outside the SDK"? – Carl Manaster Jul 29 '15 at 17:03
  • 1
    @CarlManaster if somebody has implemented the interface. The user code will fail at compile. – rnrneverdies Jul 29 '15 at 17:09
  • What, are you telling us that you don't have extensive unit tests in place that will tell you, after any given refactoring, whether anything broke? – Mike Nakis Jul 29 '15 at 18:49
  • @MikeNakis not at all. I have unit tests, all pass, but these test are updated with the new contract. Whaterver, I want to know if i'm introducing a breaking change or not. For instance to report it in the release notes. – rnrneverdies Jul 29 '15 at 19:12
6

If you only change the interface as outlined here, then yes you are breaking the code. Because every implementation of the interface must now return a String, and before the change none of them does.

Assuming you make each implementor actually return a String, then no, this cannot break the code because no caller of any of these methods is using the return value.

One obscure exception: if you are using reflection, this could break things. Because your reflection code may still be looking for the null-returning methods.

  • 2
    This will work on source level but not on byte code level. Class compiled with older SDK won't work with new SDK. – Banthar Jul 29 '15 at 18:06
4

Possibly. "Classic" existing consumers do not expect a value to be returned, thus would simply ignore the string being returned. By "classic", I mean something like this:

public void DoSomething(Contract contract)
{
    contract.update();
    contract.delete();
}

Now, there's a possibility that there is some functionality in Java that expects a method to have a void return value. I believe there's threading-related calls in C# that require methods to return void. Something like that might exist in Java as well. This could potentially break something.

Existing implementations will need to be updated to implement the new interface. However, if this is part of a 3rd party library, where only you provide implementations, then consumers of the library will not be affected.

However, changing the String to, say, Error (or any other type) would be considered a breaking change.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.