Проблема версии класса в classpath - PullRequest
2 голосов
/ 06 января 2011

Представьте, что я разрабатываю модуль A с двумя зависимостями для B и C. Что если B зависит от модуля D версии 2.0, а C - от версии D 3.0. Что еще хуже, пусть D-3.0 не обратно совместим с D-2.0 (например, были изменены интерфейсы), и B не поддерживается, и нет новой версии B, которая могла бы работать с новой версией D.

Есть ли способ запустить A с зависимостями B и C? Есть ли способ, чтобы некоторые классные версии были правильно загружены и использованы из classpath?

Спасибо за идеи.

Ответы [ 3 ]

4 голосов
/ 06 января 2011

OSGi это путь.:) Я все еще учусь этому, но по крайней мере это решает эту проблему, известную как Jar Hell .Смотрите здесь http://www.osgi.org/About/WhyOSGi

Управление версиями - технология OSGi решает ад JAR.Проблема JAR в том, что библиотека A работает с библиотекой B, версия = 2, но библиотека C может работать только с B, версия = 3.В стандартной Java вам не повезло.В среде OSGi все пакеты тщательно версионированы, и только те пакеты, которые могут сотрудничать, соединяются вместе в одном пространстве классов.Это позволяет как пакетам A и C функционировать со своей собственной библиотекой.Хотя не рекомендуется проектировать системы с этой проблемой управления версиями, в некоторых случаях это может быть спасением.

2 голосов
/ 06 января 2011

Этот инструмент для переупаковки может оказаться полезным. http://code.google.com/p/jarjar/ Это позволяет переименовать пакет. (Предполагая, что несовместимые библиотеки имеют одинаковые пакеты) После того, как вы переименовали один или оба пакета, вы можете использовать другое имя, чтобы определить, какой пакет / библиотеку вы хотите использовать.

Я видел, как это использовалось для создания библиотеки, в которой пять разных версий xerces, выбираемых по пакетам. : P

ПРИМЕЧАНИЕ. JRE помещает встроенные пакеты в com.sun. * С такими пакетами, как com.sun.org.apache. *

0 голосов
/ 06 января 2011

Возможность решения этой проблемы зависит от типа зависимостей, которые у вас есть. Если они являются прямыми зависимостями времени компиляции, то у вас большая проблема, и вам, возможно, придется сделать редизайн.

OSGi может помочь, но только если зависимости находятся во время выполнения и доступны через интерфейсы как службы OSGi. Таким образом, каждый используемый сервис создается с использованием своих собственных определенных зависимостей (и версий) и предоставляется пользователю только через интерфейс. Потребитель будет зависеть только от этого интерфейса. Таким образом, в вашем случае, если у вас есть только ссылки на классы в B и C, которые не имеют прямых ссылок на D, вы сможете использовать OSGi.

С другой стороны, если вы ссылаетесь на классы из B и C, которые имеют прямые ссылки на классы из D, это не решит вашу проблему, так как ваш модуль будет вынужден импортировать пакеты с соответствующими версиями, и ваш конфликт все еще будет существовать .

...