ClassLoader Hell?
My team is developing a complex project that depends on lots of third party jars. Some new colleagues come to this project recently. So they have to set up a new environment to share in our work. It’s so surprised that nobody could set up this environment without my help. So my colleagues fell so sadly about it: ”what a notorious classloader hell!”.
So I ask myself the classloader is really notorious? My answer is no. I give some briefly introduction our developing environment here: We put all third party jars in a shared network directory that sounds like a MAVEN style repository and there are some IDES in our team such as Intellj IDEA, Eclipse and JBuilder. So there is no way to share a common project file among the team (I know this may be a bad manner, but it’s the fact in our team). Everyone have to set the classpath in different IDES with a manifest of third party jars. Everyone’s environment is ok in compiling phase and fails in runtime phase. So I checked their environment one by one: they all add some other jars that are not used in the project and they do not really get the difference between runtime phase and compiling phase. The compliers in IDES may facilitate the system level classpath to compile our source code. So we all put the third party jars in the system level classloader. But there is a big difference in runtime phase. Different application server may have different classloader with different mechanisms. The tomcat server that our project utilize has sever classloader:
bootstrap<-> extension<->system<->common<->catalina<->shared<->web
and different classloader may take different responsibilities. For example the common classloader is shared by tomcat and web applications that deployed in this tomcat. So we MUST have a good knowledge about classloader too, otherwise we may get an unwanted result. A typical error occurred in our colleagues is ClassNotFoundException. They all like to put all third party jars in the system classlaoder and some jars in system classloader may depend on some servlet APIS. But the common classloader takes the responsibility to load the servlet jars. If we do not really get idea of classloader in tomcat, so we may not resolve this problem quickly.
(TBC...)
