tags:

views:

144

answers:

5

I have a java application that uses some third party API. The third party jar files change fairly frequently because of all kinds of patches, but the API itself does not change that often.

Do I have to recompile my application every time the third party jar changes?

+3  A: 

No, you only need to recompile code you change.

Fabian Steeg
+5  A: 

If the API changes, you should recompile even if you don't need to make any changes in your source code. If the API hasn't changed, you don't need to recompile.

The reason for the "even if you don't need to make any changes" is that some source-compatible changes may not be binary compatible. For instance, suppose you are currently calling:

public void foo(String x)

and in a later version this is changed to:

public void foo(Object x)

Obviously your code will still compile, but the method it resolves the call to will change.

This is a bit of an edge case, of course. Basically, so long as you know when the API changes, you should be okay.

Jon Skeet
I've been bit before on constant values changing. If the *value* of a constant (public static final) changes, you will need to recompile even if the name of the constant (a.k.a. the API) did not change. Java inlines constant values at compilation time.
Alex B
+1  A: 

java is not C++: when you use a library you don't import a single line of code. You just load the library on request and use that. For this reason you don't need to recompile your code :)

happy_emi
with the exception of constants (public static final). These are inlined into your compiled code.
Alex B
+2  A: 

Generally no, if the third party is well designed.

However, in the (horrible) case where the API change a method signature, or remove a method / class, then you will need a modification and a recompilation of your own code.

For example, if you have doSomething(String value); that became doSomething(int value); (or String doSomething() becoming int doSomething()) then the code of your application that calls doSomething(...) will not work anymore. So a modification of your code is required (and then a recompilation).

However, you have to know that this case is extremely rare (except if you are using a pre-alpha dependency for example). Generally, to ensure backwards compatibility, APIs never remove classes or methods. The @Deprecated annotation is used instead, to force developer to use another method / class...

romaintaz
+4  A: 

Another case where a recompilation is theoretically necessary is constants. The value of a constant is literally compiled into the bytecode of classes that use it. If the value is changed in a new version of the API, anything compiled against the old version will continue using the old value, which may lead to different behaviour and very difficult to diagnose bugs.

Of course, no API designer with an ounce of brain will change the values of public constants if he can avoid it, but there may be cases where it is necessary.

Michael Borgwardt