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

artgonchА по-моему, циклические зависимости ни при какой архитектуре не должны появляться
чёйто! не должны появляться - а появляются. вообще это особенно заметно в сложных структурах данных

VetalНу ладно, с циклическими зависимостями между пакетами я понял: это плохо... А что скажете насчет взаимозависимостей между jar-файлами? Нормально ли это?

смотря какая у вас задача? может вы моделируете какой нибудь изощренный способ реализации интервальных деревьев, где каждый узел ссылается на родителя а родитель является контейнером узлов..

опишите приблизительно задачи которые вы решаете

Vetal unicornmirageопишите приблизительно задачи которые вы решаете

Есть объекты, которые представляют собой сущности бизнес-логики и отображаются на сайте. Эти объекты подчитываются из базы данных. Они находятся в первом пакете.

Второй пакет - это Utils, который содержит утилиты, в том числе утилиты работы с url-ами.

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

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

ну если у вас бизнес-сущности (бины ваши) ссылаются на некие утилитарные методы в других пакетах, тоесли они объявлены как final, либо как интерфейсы то ничего страшного наверное нет...

Vetal
А какая разница, final они или нет?

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

Jozic unicornmirageну если у вас бизнес-сущности (бины ваши) ссылаются на некие утилитарные методы в других пакетах, тоесли они объявлены как final, либо как интерфейсы то ничего страшного наверное нет...А если утилиты ссылаюцца на пакеты бизнес-логики, то много страшного наверное есть :)
Чесно говоря, утилитами их назвать язык не поворачиваецца :)

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

кстати насчет этой схемы
авторЕсть объекты, которые представляют собой сущности бизнес-логики и отображаются на сайте. Эти объекты подчитываются из базы данных. Они находятся в первом пакете.

Второй пакет - это Utils, который содержит утилиты, в том числе утилиты работы с url-ами.

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

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

лучше в бинах не хранить методы работы с ними а вынести в отдельные обработчики.

еще раз: чтобы грамотно провести рефакторинг - нужно построить модель существующей архитектуры которую вы ходите переделать. модель должна состоять из двух под-моделей:
1) автоматная - которая иллюстрирует состояние вашей системы и условия перехода, а также иллюстрирует структуру вашей системы и топологию.
2) модель поведения и последовательностей - как в динамике ведет ваша система

на базе этой модели можно проанализирвоать все зависимости и переделать архитектуру
(я так понимаю, сторонники этого подхода - Дейкстра, Кнут и пр...) - тоесть постоянное сопровождение проектирвоания и моделей. Кстати этот подход перекликается с существущей концепцией MDA (Model Driven Architecture)

Второй подход - рефакторинг- постепенное изменение кода...
Выбирать вам.