if you have a method "void x(int i)", and change it to "void x(long i)", it will cause NoSuchMethodError if the code is not recompiled, i.e. if it's a dependenc

if you have a method "void x(int i)", and change it to "void x(long i)", it will cause NoSuchMethodError if the code is not recompiled, i.e. if it's a dependency on a jar file. Likewise when there were methods in URLConnection that returned (or take) int for content-length, it would not be possible to convert them to long by just changing the existing signatures. The same applies to having a method "void x(String s)", it cannot be changed to "void x(Object s)" (even though all the code would compile with auto downcast) but both methods have to co-exist being overloaded. There is more to the binary compatibility but I'd leave it here. The way to do it is keeping the existing public (and protected) methods (&fields), possibly deprecating them, along with introducing new ones. Effectively any removal of anything that has been made accessible, public mostly, is forbidden. Personally, whenever I had to maintain library code I stuck to the same principle, so folks could grab a new version w/o worrying or doing any changes on their own.