The IT industry loves a good "Holy War". One of the latest has been the highly visible and at times down right nasty forking of the Hudson Continuous Integration server into the Jenkins Continuous Integration Server.  More recently Oracle has announced an intention to release Hudson to the Eclipse Foundation, raising some interesting questions about whether all of this could have been avoided in the first place.  

With the situation changing so rapidly, how does a development team, or company make the right choice?  After following the evolution of both of these servers, I can safely say that it doesn't matter.

A few years ago Bruce Tate and Justin Gehtland wrote a book entitled Better, Faster, Lighter Java.  In this book they argue that sometimes a simpler solution is the right answer.   As developers we often become attached to our "Golden Hammer" and try to use it for every purpose.  Large Java EE containers such as Weblogic, JBoss and WebSphere have a place in our toolbox, but sometimes what you need is a simple container which starts quickly and has a small footprint. 

Recently I stumbled onto JMockit and have been pretty impressed with the flexibility of the approach it takes.

Many mocking frameworks seem to take an elitist attitude toward testable code, not attempting to solve certain problems in favor of guiding one toward a more testable design. It appears JMockit is a response to this.

As of JUnit 4.4, if you happen to peek into the distributed JAR you'll notice something a little off: in addition to the org.junit.* packages there is this a funny-looking org.hamcrest.* package sticking out like a sore thumb.  You may have seen other projects pick up a dependency on Hamcrest lately as well, and I bet you're wondering what it is.  Let's get to the bottom of it.