Мы направляемся в jar hell на платформе java, похожей на dll hell?

Question

Прошлой ночью я пытался написать простое руководство по созданию приложения с использованием стека - Spring (2.5) + JPA (1.0) + Hibernate (загрузка происходит впервые, поэтому я не знал, какую версию использовать). К сожалению, я не хотел использовать Maven, поскольку целевые участники были на сборке ANT. Как обычно, попал в поисковую систему и получил шаги в appcontext, persistence.xml и в классах java. В тот момент, когда я начал получать необходимые библиотеки, я потерял в аду JAR. К счастью, на стороне Spring нет особых проблем, так как все зависимые файлы JAR упакованы вместе для моего Spring 2.5.6.

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

Наконец-то я все заработал, но выглядит страшно снова войти в этот JAR-ад, если меня не заберут через небеса Мавена.

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

Прав ли я в мыслительном процессе?

Answer 1

При использовании Ant вы все еще можете управлять зависимостями, используйте Ivy .Смотрите подробное руководство здесь , чтобы более или менее точно определить, какой стек вы хотите использовать.(Не включает Hibernate, но я думаю, вы можете найти, как добавить это довольно быстро)

И еще одна вещь, если вы ссылаетесь на spring.jar, который имеет полный пакет Spring 2.5.6, яНастоятельно рекомендуем не использовать его, вам, вероятно, потребуется не более 20% библиотек, входящих в него.(Потратьте время, чтобы выяснить, какие именно библиотеки вам нужны, и выберите только те.)

Кроме того, рассмотрите возможность использования Spring 3, если вы можете, и Hibernate, если вы можете выбрать версию, я 'буду идти за последним.

Answer 2

Ранее я использовал другие реализации JPA, но впервые в этом году я использовал Hibernate. Конечно, это более сложно, чем другие, в отношении jar-зависимостей, но в Руководстве по началу работы , в главе 1 , в разделе Получение Hibernate я нашел подробности, по которым баночки мне нужны и зачем.

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

Я думаю, что на данный момент это реальность, и такие инструменты, как Maven или фреймворки, такие как OSGi, пытаются решить эту проблему.

Возможно, самая большая надежда, которую мы имеем, - это Project Jigsaw , которая должна стать частью JDK 8 в будущем и которая пытается решить проблемы модульности Java, которые у нас есть в настоящее время. Он будет похож на OSGi со стероидами и встроен в сам JDK.

Но прежде чем это произойдет, все, что я могу вам сказать, это знаменитая цитата Уистона Черчилля

Если вы идете через ад, продолжайте собирается

Answer 3

Это одна из проблем, которые Grails решает - объединяя определенный набор jar-файлов (Spring, Hibernate и т. Д.), Которые работают вместе, и обновляя эти jar-файлы по мере развития Grails.