A bit on classloader

At first glance, I thought java could face the same problem as dll was (dll hell). But then classloader scoping comes to the rescue. And by the way, I won't explain the theory of classloading here. By having classloader scope set to the application, it will allow each application to bring their own libraries without worrying of library conflict.

For example, I built a library of common utilities and there are already 2 versions of it. And 2 of my web applications are using the library, however each with a different versions from the other. If the flat classloading is used, only one of the 2 versions of the library will be used and the impact is the web application which used the version not loaded will have strange errors such as ClassCastException, IllegalAccessErrors and possibly many others. Having classloader scoping will allow each of my web application to use its respective library.

One thing cross my mind, how could I have a smaller deployment size for a web application and still having the classloader scoping. Smaller deployment size here refers to my classes only without the whole bunch of libraries. Usually when people delivers a patch for the web application, all is packed in war file which size is quite large. On my case, the library size are around 80% of the war file size. Up to now, all I can do is to deploy the application as exploded. Thus allowing me to deploy patches by replacing the content/libraries. Not an elegant solution but still a viable one, until I can find a nicer solution.....