What is classpath hell and is/was it really a prob

问题:

What is classpath hell and is/was it really a problem for Java?

回答1:

Classpath hell is an unfortunate consequence of dynamic linking of the kind carried out by Java.

Your program is not a fixed entity but rather the exact set of classes loaded by a JVM in a particular instance.

It is very possible to be in situations where the same command line on different platforms or even on the same one would result in completely different results because of the resolution rules.

There could be differences in standard libraries (very common). Libraries could be hidden by one another (an an older version may even be used instead of a newer one). The directory structure could mess resolution. A different version of the same class may appear in multiple libraries and the first one encountered will be used, etc. Since Java, by specification, uses a first-encountered policy, unknown ordering dependencies can lead to problems. Of course, since this is the command line and it is part of the spec, there are no real warnings.

It is very much still a problem. For example on Mac OS the horrible support from Apple means that you machine ends up with several JVMs and several JREs, and you can never easily poart things from place to place. If you have multiple libraries that were compiled against specific but different versions of other libraries, you coulld have problems, etc.

However, this problem is not inherent in Java. I remember my share of DLL hell situations while programming windows in the 90s. Any situation where you have to count on something in the file system to assemble your program rather than having a single well defined executable is a problem.

However, the benefits of this model are still great, so I'm willing to tolerate this hell. There are also steps in the right direction on the side of Sun. For example, Java6 allows you to simply specify a directory with jars rather than have to enumerate them.

BTW: Classpaths are also a problem if you are using an environment that uses a non-default classloader. For example, I have had a lot of problems running things like Hibernate or Digester under Eclipse because the classloaders were incompatible.

回答2:

Classpath/jar-hell has a couple of escape hatches if they make sense for your project:

• OSGi
• JarJarLinks
• NetBeans Module System - Not sure if this is usable outside of NetBeans
• Others?

回答3:

I think "classpath hell" refers to the time when the classpath of a Java app could only be set by using the CLASSPATH environment variable. This led to many applications requiring changes to the global system configuration (different for each OS), version conflicts between applications, and general confusion.

回答4:

This is a somewhat more concrete example:

When two libraries (or a library and the application) require different versions of the same third library. If both versions of the third library use the same class names, there is no way to load both versions of the third library with the same classloader.

Take a loot at http://en.wikipedia.org/wiki/Java_Classloader#JAR_hell for more examples.

回答5:

There's lot of good stuff here http://mindprod.com/jgloss/classpath.html and http://java.sun.com/javase/6/docs/technotes/tools/windows/classpath.html

I've only had issues with classpaths when I am not setting is myself using -cp. Trying to figure out how your third-party software sets their classpaths can be a pain at times.