Does adding a new dependency to a library, with compatible API changes, affect binary compatibility?

Question

My question:

Does adding a new dependency to a library affect binary compatibility, as long as the library's external API is otherwise backwards compatible?

My situation:

My CBOR library contains classes for arbitrary-precision arithmetic (in the PeterO namespace). (It's in C# and Java; the Java version is in a separate repository, but the same issue applies to both versions.)

I have moved these classes to a new namespace (in PeterO.Numbers), and renamed them (retaining the original classes for backward compatibility), because the namespace where they are now is meant to contain only utility classes. I plan to move the new classes to a separate library and make the CBOR library call that library as a dependency, since the arbitrary-precision classes are obviously useful outside of CBOR. (I plan to eventually deprecate the old classes.)

But I'm concerned if making a separate library this way is a binary compatibility issue, such that I can't just update the minor version, but also the major version. The CBOR library is version 2.3.1 at the time of this writing. Am I able to do this and change the version to 2.4, or only 3.0?

Answer 1

As long as you started out with an interface to begin with and all your libraries' clients are aware of that interface, you will be fine. It does not matter where your code resides in your library or in a library outside of it as long as your library has an interface which its clients understand and it implements the interface.

This is an age old problem and has been solved 15 years ago by COM (component object model). Keep your interfaces separate from implementation and you are golden.

Answer 2

I'll answer for the Java version. This section of the Java Language Specification describes in detail the changes that can be done to applications while preserving binary compatibility.

From what I understand, your changes (although they may affect a great portion of the source) are simple refactorings that expose some utility classes to another module, and re-direct the old classes to call this new module. This is described in the section on Evolution of Packages:

A new top level class or interface type may be added to a package without breaking compatibility with pre-existing binaries, provided the new type does not reuse a name previously given to an unrelated type.

So this does not break binary compatibility with existing classes that use your library. Any existing class CBORClient that used to call CBORUtil.doArithmetic() will continue to work without the need to re-compile it, since the method is still there, only its body has changed to call another module to do the computation.