JAR Hell


Dino posts an amusing story about “JAR Hell” and battling with 7 copies of the log4j.jar library…

Comments (2)

  1. There are some interesting efforts such as Gump from Apache to try and battle this problem. Gump will retrieve the latest source code for your program and your dependencies, try to compile and run it all, and complain to the place where interfaces or whatever changed to cause the breakage. I think it is similar to tinderbox that Mozilla uses to continually build their products to ensure no breakage but extends to all of the dependent libraries as well to make sure they don’t break their interfaces.

  2. Simon says:

    Am I also right in thinking that IBM have a tool for searching JAR files for a Class? There’s nothing more annoying that a ClassNotFoundException at runtime and then having to dig through the JAR files to find out which one to put on the classpath…