Does changing versions of a third party jar require recompiling of my code? [duplicate]

Question

This may seem like a silly question but before I go shooting my mouth off in a team meeting I want to absolutely certain that I understand things correctly.

I have a Java application that references a third party jar file. My code only uses their interfaces. If the third party gives me a different version of their jar file and I simply replace the old jar with the new do I need to recompile my application?

Is this still true if the interface method signature contains one of their classes, e.g.

public void thirdPartyMethod(ThirdPartyEvent e);

It is my understanding that unless the interface has changed I do not have to recompile. Even if the ThirdPartyEvent class is changed (new methods added) I still do not have to recompile unless I want to access those new methods.

Is my understanding correct?

Thanks in advance.

EDIT: This question can be closed it is a duplicate. Didn't see it when I did a search - don't know how I could of missed it...

BTW It was not clearly stated in my question but the API has not changed - the interfaces are the same.

FINAL EDIT: I do want to note though that there are times when deploying an new version of a third party jar is far easier than deploying an entire re-compiled application...

As a matter of practice I do routinely re-compile, there is absolutely no harm in doing so. However, where I work there is a complete lack of understanding on how Java Interfaces work. Everyone was worried that the new third party implementation has changed and our application would not work anymore. I told them that would only happen if the third party changed the API or gave us a broken jar.

Anyway long story short, I thought that if I could show that you could replace the jar and not recompile that would illustrate (at least in part) how interfaces work. I have emailed links to this post, the duplicate and Mik378's included link in the hopes that it will finally sink in...

Answer 1

Here are the rules concerning the Java Binary compatibility.

From there, you can keep your code unchanged ONLY if the changes (in the Jar) concern:

Reimplementing existing methods, constructors, and initializers to improve performance.

Changing methods or constructors to return values on inputs for which they previously either threw exceptions that normally should not occur or failed by going into an infinite loop or causing a deadlock.

Adding new fields, methods, or constructors to an existing class or interface.

Deleting private fields, methods, or constructors of a class.

When an entire package is updated, deleting default (package-only) access fields, methods, or constructors of classes and interfaces in the package.

Reordering the fields, methods, or constructors in an existing type declaration.

Moving a method upward in the class hierarchy.

Reordering the list of direct superinterfaces of a class or interface.

Inserting new class or interface types in the type hierarchy.

For all other cases, you have to alter your code to benefit (without weird surprises) from the new Jar.