Classpath Hell

One big need for OsGi / JavaModuleSystem? (JSR 277) functionality is to fix the ClasspathHell problem:

My application uses libraries "B" and "C", both of which use library "D".
But "B" and "C" require different versions of "D".
There's no version of "D" I can put on the CLASSPATH that will satisfy both "B" and "C".
Thus, I'm in "ClasspathHell" -- there's no "standard Java way" to fix the problem.

MurphysLaw of the Java CLASSPATH: "If any part of your distributed Java application can go wrong, the classpath will."

After you survive the classpath disaster, here it comes the allmighty classloader.

Does it bother anyone else how much effort you have to put into clearing up classpath problems when dealing with things like J2EE servers, SOAP servers and the like? The glossys all say that these architectures make integration "easy", but you spend more time chasing stupid little things like crap that's in your classpath and shouldn't be. Or (good) crap that you'd think would be in a custom classpath for a Tomcat servlet (because you put it under web-inf like a good boy/girl), but for some undocumented reason appears not to be.

Conclusion: Classpath must be an invention of higher Consciousness. Consider all "C" words harmful until further notice, with one glaringly obvious Exception (and apologies to the host).

Semi-consciousness, maybe. classpath looks a lot like a half-baked attempt to make Java into an image based language, rather than a file based one.

Launch your Java programs from a script that wipes the existing classpath and sets up the classpath required by the program. You need to write such scripts anyway to make Java applications look "native" on each platform.

You do not need to go to ClasspathHell. Just use a proper ClassLoader, The JavaVm? has a clear concept of different versions of the same class. Actually the two equally named classes are only equal if they are loaded by the same ClassLoader. Thus at least conceptually this is a non-issue. The problem really is that too many people fall for the simple approach of putting things into the classpath. You do not need to. Just look at your plain old webapp. Each webapp is loaded by its own classloader so you can have multiple versions of the same library in different webapps - even though they are run by the same application server. Most application servers even provide functionality to configure your own ClassLoader (e.g. Jetty: http://docs.codehaus.org/display/JETTY/Classloading).

But all ApplicationServers? leak memory each time you deploy and undeploy an application:

Sure way to crash any JavaEnterpriseEdition ApplicationServer: undeploy and redeploy until memory leaks kill the JavaVirtualMachine: Solutions?
- OsGi (property implemented ClassLoading?, not the crap included by default) or..
- MultitaskingVirtualMachine (one day in a the far future), or...
- multiple JavaVirtualMachine instances (one for each application, big memory waste)

Another solution: drop Java, switch to DotNet, COM had it own ClasspathHell ( DllHell ). So, DotNet has had good a ModuleSystem since version 1.0: Assemblies (they have versioning and everything, even a central repository known as GlobalAssemblyCache for cases when they are shared between applications... far less error prone than JavaClasspath? )

Compare: DllHell, ModuleDependencyProblem