什么是类路径地狱？它真的是 Java 的一个问题吗？
什么是类路径地狱？它真的是 Java 的一个问题吗？
What is classpath hell and is/was it really a problem for Java?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
什么是类路径地狱？它真的是 Java 的一个问题吗？
What is classpath hell and is/was it really a problem for Java?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（5）
这是一个更具体的例子：
在 http://en.wikipedia.org/wiki/Java_Classloader#JAR_hell 获取战利品了解更多示例。
This is a somewhat more concrete example:
Take a loot at http://en.wikipedia.org/wiki/Java_Classloader#JAR_hell for more examples.
这里有很多好东西 http://mindprod.com/jgloss/classpath.html 和http://java.sun.com/javase/ 6/docs/technotes/tools/windows/classpath.html
当我自己没有使用 -cp 时，我只遇到了类路径问题。 尝试弄清楚第三方软件如何设置其类路径有时可能会很痛苦。
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.
Classpath/jar-hell 有几个逃生舱口（如果它们对您的项目有意义的话）：
Classpath/jar-hell has a couple of escape hatches if they make sense for your project:
我认为“类路径地狱”指的是Java应用程序的类路径只能通过使用CLASSPATH环境变量来设置的时候。 这导致许多应用程序需要更改全局系统配置（每个操作系统都不同）、应用程序之间的版本冲突以及普遍的混乱。
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.
类路径地狱是 Java 执行的动态链接的不幸后果。
您的程序不是一个固定的实体，而是由 JVM 在特定实例中加载的一组确切的类。
由于解析规则的原因，不同平台甚至同一平台上的相同命令行很可能会导致完全不同的结果。
标准库可能存在差异（很常见）。 库可以相互隐藏（甚至可以使用旧版本而不是新版本）。 目录结构可能会扰乱分辨率。 同一类的不同版本可能会出现在多个库中，并且将使用第一个遇到的版本，等等。由于按照规范，Java 使用首次遇到的策略，因此未知的排序依赖关系可能会导致问题。 当然，由于这是命令行并且是规范的一部分，因此没有真正的警告。
这仍然是一个问题。 例如，在 Mac OS 上，Apple 的糟糕支持意味着您的机器最终会拥有多个 JVM 和多个 JRE，并且您永远无法轻松地将东西从一个地方转移到另一个地方。 如果您有多个针对特定但不同版本的其他库进行编译的库，则可能会遇到问题等。
但是，这个问题并不是 Java 固有的。 我记得我在 90 年代对 Windows 进行编程时遇到过 DLL 地狱的情况。 如果您必须依靠文件系统中的某些内容来组装程序而不是使用单个定义良好的可执行文件，那么任何情况都会出现问题。
不过这个模式的好处还是很大的，所以我愿意忍受这个地狱。 Sun这边也有正确方向的台阶。 例如，Java6 允许您简单地指定包含 jar 的目录，而不必枚举它们。
顺便说一句：如果您使用的环境使用非默认类加载器，则类路径也是一个问题。 例如，我在 Eclipse 下运行 Hibernate 或 Digester 之类的东西时遇到了很多问题，因为类加载器不兼容。
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.