It seems like some of the problems that plagued the windows environment have followed into the Java world, im talking about JAR hell. If one has worked in the windows environment, they would be familiar with the DLL hell problem.
What is DLL Hell?
Unlike Hell, DLL Hell is reserved for Microsoft software users, bad ones and good ones. DLL Hell is what happens, when your computer or software stops operating because you’ve tried to install some new software, so the old software stops working or the new software fails to work.
I see a similar problem happening with jars in java. With the amount of open source components(jars) being created and distributed the problem is bound to affect everyone. The problem only worsens when you have software supporting multiple solutions to a similar problem. For instance, a software supporting both castor & hibernate. Im not even going down the Class Loading lane!
What is Jar Hell?
JAR-hell occurs when software is deployed into a runtime environment which is unsuitable, but nothing other than full integration testing would detect this. Having multiple software packages dependent upon the same piece of software, with unpredictable incompatibilities, is pure hell. Ensuring the compatibility of a variety of dependent packages is duanting, doing it amongst the variety supported by a hierarchy of complex class loaders, is inhuman. Jar Hell also occurs when you try to build/compile software that is dependent on other components.
Im not saying component development is bad, Im just saying that there needs to be a solution to this problem. A side effect to component development is having programmers who just understand syntax and have no clue about concepts! Im digressing! Anyways, unless one has been extremely careful with the components that they have been downloading and using, they are bound to find multiple copies of the same jars files floating around (Apache Commons is fine example) and they problem is going to alleiviate with multiple versions. A good test to see if you have unknowingly have the problem, trying search your hard drive for the ant installation to see how many associated jars you have.
A classic example that I know off is Roller, the number of jars file on the client(web app) side is 50 and on the server side is 72! Its only a matter of time before one realises that the number of classes in your application are going to be less than the jars that you would need to include! Heck, thats true if you write a hello world struts application! (9 jars & 6 classes including one JSP)
Im beginning to wonder, if creating a Package distribution of jar is good idea? But then linux has about 100+ distributions. A quick peek @ JSR’s does not reveal any requests for component deployment. I did however find one for Application deployment, which caters to J2EE server deployment. One solution that I can think of is as follows
Have a file like Manifest file that describes the dependencies(list of jars and versions) and the compiler/Class loader checks against this file or one could atleast have an Ant task that does the verification before it compiles the sources. It would be even cooler if this architecture was extensible so that someone can write a component which allow the jar file to be downloaded if it cannot be found 😉
What do you think?
I did find a project that is trying to address the problem with class loaders http://www.krysalis.org/version/ . Are there other solutions or works in progress around? Is the community already addressing this problem?