In fairness, it was pretty reckless to just "update" the existing method without providing a dummy "throw an informative error if anything attempts to call the old method" fallback method
There were all sorts of "wrong" with that attempted refactoring that goes back to the original "subclass the StoredProcedure class and overload the execute(Object ...) method rather than creating a new one... and name it callProc (for example).
I'd have to spin up a test to verify, but I believe that if Spring had made it a protected method so that execute could only be called by a subclass rather than public where it can be called from other methods in other classes it would have mitigated the issue that allowed for the original developer to overload it. That would have made it so when the arguments changed it now was a compile error since the execute(Object...) form of the call would only have been accessible from the subclass.
