什么是类路径地狱，是/它真的是Java的问题吗？
什么是类路径地狱，是/它真的是Java的问题吗？
Classpath hell是Java执行的动态链接的一个不幸后果。
您的程序不是固定实体，而是由特定实例中的JVM加载的确切类集。
由于分辨率规则，很可能在不同平台上甚至同一命令行上的相同命令行会导致完全不同的结果。
标准库可能存在差异（非常常见）。 库可以彼此隐藏（甚至可以使用旧版本而不是新版本）。 目录结构可能会破坏解决方案。 同一类的不同版本可能出现在多个库中，并且将使用遇到的第一个类，等等。由于Java，根据规范，使用第一次遇到的策略，未知的顺序依赖性可能导致问题。 当然，由于这是命令行，并且它是规范的一部分，因此没有真正的警告。
这仍然是一个问题。 例如在Mac OS上，来自Apple的可怕支持意味着你的机器最终会有几个JVM和几个JRE，你永远不能轻易地将东西放到一个地方。 如果您有多个库，这些库是针对特定但不同版本的其他库编译的，那么您可能会遇到问题，等等。
但是，这个问题并不是Java所固有的。 在90年代编程窗口时，我记得我对DLL地狱情况的分享。 任何情况下你必须指望文件系统中的某些东西来组装你的程序而不是一个定义良好的可执行文件是一个问题。
然而，这种模式的好处仍然很大，所以我愿意容忍这种地狱。 在太阳一侧的正确方向上也有一些步骤。 例如，Java6允许您只使用jar指定目录，而不必枚举它们。
顺便说一句：如果您使用的是使用非默认类加载器的环境，则类路径也是一个问题。 例如，我在Eclipse下运行Hibernate或Digester等问题时遇到了很多问题，因为类加载器是不兼容的。
Classpath / jar-hell有几个逃生舱，如果它们对你的项目有意义：
- OSGi的
- JarJarLinks
- NetBeans模块系统 – 不确定它是否可在NetBeans之外使用
- 其他？
我认为“classpath hell”是指只能使用CLASSPATH环境变量设置Java应用程序的类路径的时间。 这导致许多应用程序需要更改全局系统配置（每个操作系统不同），应用程序之间的版本冲突以及一般混淆。
这是一个更具体的例子：
当两个库（或库和应用程序）需要相同第三个库的不同版本时。 如果第三个库的两个版本使用相同的类名，则无法使用相同的类加载器加载第三个库的两个版本。
有关更多示例，请访问http://en.wikipedia.org/wiki/Java_Classloader#JAR_hell获取战利品。
这里有很多好东西http://mindprod.com/jgloss/classpath.html和http://java.sun.com/javase/6/docs/technotes/tools/windows/classpath.html
当我没有设置时，我只有类路径的问题是我自己使用-cp。 试图弄清楚你的第三方软件如何设置他们的类路径有时会很痛苦。