Compare JAR files content; decompiling class files

When I was recently working on a large restructuring and refactoring where I also replaced Ant by Maven, it was really necessary to compare the complete content of two¬†different JAR files. It was required to know that the result of the restructuring and refactoring hadn’t changed the artifacts, thus the JAR files.
In the JAR files were different Class files present. When I compared the content of the two JAR files (with a binary compare) all the content was radically changed. This was partly because the compiler compiled the Class files at a different timestamp.

Since I wanted the best possible comparison between the two JAR files I needed to compare all Class files in the JAR by decompiling and comparing. This should give me a clearer and more honest picture of the differences. For this action I used Beyond Compare. By using an additional File Format (Java Class to Source) I was able to completely compare the decompiled Class files of the two JARS.

If you ever need to compare JAR, WAR or EAR files and need to compare the Class files inside; don’t try to unpack to a folder, decompile to a different folder and finally folder compare. You should use Beyond Compare and save time on comparing. The Beyond Compare license will pay itself off.

Tasty Test Tip: Using ArgumentCaptor for generic collections with Mockito

Mockito has a very nice feature that allows you to verify what parameters were used when a method was executed.

For example:

However, when using generic typed objects, some problems rise up.
For example, the following won’t work:

This is obviously not a Mockito problem, but a generics problem.

To solve this, follow these two steps:

1. use the @Captor annotation.

2. initialize the Mockito annotations in your initialization method (add one if you don’t have one).

And presto! You can now capture the parameters that were used when a to be verified method was executed.