Что такое ад пути к классам и действительно ли это было проблемой для Java?

Здесь много хороших вещей http://mindprod.com/jgloss/classpath.html и http://java.sun.com/javase/6/docs/technotes/tools/windows/classpath.html

У меня были проблемы с путями к классам только тогда, когда я не устанавливаю, использую ли я -cp. Попытка выяснить, как стороннее программное обеспечение устанавливает свои пути к классам, временами может быть проблемой.

Ад пути к классам - досадное следствие динамического связывания типа того, что выполняет Java.

Ваша программа - это не фиксированная сущность, а точный набор классов, загружаемых JVM в конкретном экземпляре.

Очень возможно оказаться в ситуациях, когда одна и та же командная строка на разных платформах или даже на одной и той же приведет к совершенно разным результатам из-за правил разрешения.

Могут быть различия в стандартных библиотеках (очень часто). Библиотеки могут быть скрыты друг от друга (можно даже использовать более старую версию вместо новой). Структура каталогов может испортить разрешение. Другая версия одного и того же класса может появиться в нескольких библиотеках, и будет использоваться первая встречающаяся и т. д. Поскольку Java, согласно спецификации, использует политику, обнаруженную впервые, неизвестные зависимости упорядочения могут привести к проблемам. Конечно, поскольку это командная строка и часть спецификации, реальных предупреждений нет.

Это все еще большая проблема. Например, в Mac OS ужасная поддержка Apple означает, что на вашем компьютере оказывается несколько JVM и несколько JRE, и вы никогда не сможете легко перемещать вещи с места на место. Если у вас есть несколько библиотек, которые были скомпилированы для конкретных, но разных версий других библиотек, у вас могут возникнуть проблемы и т. д.

Однако эта проблема не присуща Java. Я помню свою долю адских ситуаций с DLL при программировании окон в 90-х годах. Любая ситуация, когда вам нужно рассчитывать на что-то в файловой системе для сборки вашей программы, вместо того, чтобы иметь один четко определенный исполняемый файл, является проблемой.

Однако преимущества этой модели по-прежнему велики, так что я готов терпеть этот ад. На стороне Солнца тоже есть шаги в правильном направлении. Например, Java6 позволяет вам просто указать каталог с jar-файлами, а не перечислять их.

Кстати: пути к классам также являются проблемой, если вы используете среду, в которой используется загрузчик классов не по умолчанию. Например, у меня было много проблем с запуском таких вещей, как Hibernate или Digester в Eclipse, потому что загрузчики классов были несовместимы.

Я думаю, что «ад пути к классам» относится к тому времени, когда путь к классам приложения Java можно было установить только с помощью переменной среды CLASSPATH. Это привело к тому, что многие приложения потребовали изменения глобальной конфигурации системы (разной для каждой ОС), конфликтов версий между приложениями и общей путаницы.

В пути к классам / jar-hell есть пара аварийных люков, если они имеют смысл для вашего проекта:

• OSGi
• JarJarLinks
• Модульная система NetBeans - Не уверен, можно ли использовать вне NetBeans
• Другие?

Это несколько более конкретный пример:

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.

Возьмите добычу в http://en.wikipedia.org/wiki/Java_Classloader#JAR_hell, чтобы увидеть больше примеров.