Является ли механизм принудительного управления версиями наиболее необходимой функцией Java?

Question

Как разработчик, меня часто интересует новая языковая функция, которая может сделать вашу жизнь проще. Например, java 5 привнес язык и аннотации к языку, функции, которые определенно могут повысить вашу производительность.

Однако, оглядываясь назад на почти десятилетие работы над Java-платформой, я обнаружил, что проблемы, связанные с управлением версиями, являются основной причиной непродуктивных и излишне затраченных усилий. Часами и часами искали правильную версию jar, пытались разрешить конфликт версий, обновляли зависимые библиотеки и т. Д. Когда я начал работать в java, все было не так сложно, у вас было бы несколько сторонних библиотек, и все , Сегодня ваше типичное веб-приложение может легко использоваться: Spring Framework, Hibernate, Struts, как вы его называете. Все они содержат ряд зависимых сторонних библиотек. Сегодня мои ушные архивы обычно включают около 40 или более сторонних библиотек. Настоящий кувшин, черт возьми!

С аннотациями мне не нужно, например, управлять файлами конфигурации для Hibernate. Хорошая функция, но я не видел, чтобы многие проблемы возникали из-за того, что я держу свои дескрипторы в отдельном файле. Что касается дженериков, то я избавлен от написания операторов приведения, но во всем своем программном обеспечении я не могу вспомнить ни одной ошибки, которую можно было бы предотвратить, используя безопасный для типов контейнер. Разве решение проблем управления версиями не было бы гораздо более ценным?

Все эти проблемы привели к появлению ряда инструментов, таких как Maven , ivy , One Jar , Jar Jar Links (не шучу !), даже с соответствующим названием Jar Hell и т. д. Даже если вы используете некоторые из этих инструментов, вы далеко не застрахованы от этой проблемы. Я использую Maven 2, и это мне очень помогло. Тем не менее, это мир для себя. Начинающему программисту может понадобиться время, чтобы выучить его. Перенос ваших старых проектов в структуру Maven также является проблемой.

Похоже, что в .Net они усвоили урок с dll hell, и управление сборками .Net намного проще.

Кажется, есть планы решить эту проблему для платформы Java и альтернатив, таких как OSGI. Я думаю, что какой-то базовый и принудительный механизм управления версиями крайне необходим

Answer 1

Я также использую Java уже более десяти лет, но должен сказать, что вообще не нашел много проблем JAR hell (даже используя все сторонние инструменты, о которых вы упомянули)! Я обнаружил, что Maven ужасный инструмент, поэтому создайте все с помощью ant.

В нашей компании у нас есть специальная задача разрешения зависимостей ant, основанная на простом (небольшом) файле зависимостей для каждого проекта, вместе с определением каждого проекта как app или lib (вы должны только всегда зависеть от lib; никогда не app). Работает просто отлично.

У нас также есть задачи ant для изменения наших файлов eclipse .classpath и IDEA .iml для создания графиков зависимостей для наших IDE.

Answer 2

Посмотрите на OSGi - он очень хорошо справляется с управлением версиями и пакетами (jars).

ТАКЖЕ: Eclipse (который построен поверх OSGi) имеет несколько относительно новых инструментов API, которые могут помочь вам сравнить ваш API с предыдущей базовой линией и определить, как правильно выразить следующий номер версии ваших пакетов.

Общая схема управления версиями затмения:

v.m.n.q

, где

v: высокоуровневая версия - изменения, представленные здесь, представляют собой, как правило, серьезные изменения в API

м: основные изменения - новый функционал, новый API

n: незначительные изменения - тот же API, закулисные изменения

q: квалификатор - полезно для пометки сборок, альфа / бета и т. Д.

OSGi определяет зависимости версии, используя диапазоны. Например

Require-Bundle: com.javadude.foo;bundle-version="[1.2.0,2.0.0)"

в вашем файле MANIFEST.MF указывает, что для пакета требуется версия 1.2.0 или более поздняя версия пакета com.javadude.foo, вплоть до (но не включая) версии 2.0.0.

Вместо этого вы также можете указать зависимости на уровне пакета.

Answer 3

Я столкнулся с этой проблемой на сайте, на котором работал: построил инструмент для работы с файлами JAR, находящимися на веб-сервере, и поиска всех вложенных копий файлов JAR - и разных файлов с одинаковыми именами (например, версии log4j.jar). Это был ужасный беспорядок, включая одну ВОЙНУ, в которой был jar WebLogic внутри it.

Не уверен, что решение.

Дело в том, что java имеет вещи для управления этим - штампованные файлы jar с версиями пакетов. И особенно: веб-старт. Возможно, нам нужен какой-то загрузчик классов, который делает что-то вроде веб-старта.

Как насчет: в манифесте JAR вы указываете библиотечные зависимости , используя известные имена и версии. Загрузчик классов, предоставляемый контейнером или средой выполнения, будет отвечать за получение нужных вам версий.

Существует множество систем (например, самого Maven) для управления хорошо известными местами для загрузки библиотек, а также для fink и прочего.

Answer 4

.NET поддерживает параллельные сборки, поэтому вы можете иметь несколько версий одного и того же приложения. GAC похож на разделяемые библиотеки DLL, но все же вы можете зарегистрировать несколько версий одной и той же сборки в GAC, и другая сборка может запросить определенную версию или версию с большей или большей версией, если я хорошо помню. В JavaEE, кстати, у вас есть несколько уровней загрузчика классов, и вы можете сделать несколько трюков, имитирующих аналогичное управление версиями

Answer 5

Преимущество .NET по сравнению с Java заключается в том, что библиотеки более тесно связаны с ОС. Тот факт, что библиотеки фреймворков, если они установлены, легко размещаются в GAC, упрощает работу, но вы также в значительной степени ограничены Windows. Лучшее сравнение было бы с Mono, но у меня там нет опыта.

Управление конфигурацией, по крайней мере для меня, всегда было большой болью при разработке программного обеспечения. Чем больше вы пытаетесь воспользоваться существующим кодом, тем хуже это кажется. Сама проблема не уникальна для Java, но количество версий, количество времени работы платформы и количество поддерживаемых платформ, похоже, только усугубляют ситуацию. Я только что проверил, и у меня есть 3 версии JRE прямо сейчас - и я даже не активный Java-разработчик.

Что касается вашего вопроса, я не уверен, что это наиболее актуальная функция. Лично я хотел бы видеть лучшую поддержку веб-сервисов, особенно тех, которые требуют заголовки аутентификации. В последний раз, когда я пытался заставить Java взаимодействовать с одним из моих веб-сервисов .NET, я чуть не вырвал свои волосы. Используя LINQ с C # /. Net, я также могу сказать, что это было бы довольно классным дополнением к Java с возможно большим увеличением производительности.