Question

I have a scenario where I have code written against version 1 of a library but I want to ship version 2 of the library instead. The code has shipped and is therefore not changeable. I’m concerned that it might try to access classes or members of the library that existed in v1 but have been removed in v2.

I figured it would be possible to write a tool to do a simple check to see if the code will link against the newer version of the library. I appreciate that the code may still be very broken even if the code links. I am thinking about this from the other side – if the code won’t link then I can be sure there is a problem.

As far as I can see, I need to run through the bytecode checking for references, method calls and field accesses to library classes then use reflection to check whether the class/member exists.

I have three-fold question:

(1) Does such a tool exist already?

(2) I have a niggling feeling it is much more complicated that I imagine and that I have missed something major – is that the case?

(3) Do you know of a handy library that would allow me to inspect the bytecode such that I can find the method calls, references etc.?

Thanks!

Answer 1

I think that Clirr – a binary compatibility checker – can help here:

Clirr is a tool that checks Java libraries for binary and source compatibility with older releases. Basically you give it two sets of jar files and Clirr dumps out a list of changes in the public api. The Clirr Ant task can be configured to break the build if it detects incompatible api changes. In a continuous integration process Clirr can automatically prevent accidental introduction of binary or source compatibility problems.