Нам необходимо уметь корректировать поведение во время запуска, предоставляя нужные классы, которые будут создаваться различными фабриками внутри нашего приложения (чтобы избежать жесткого связывания оператора «new»).
Мне известно, что это обеспечивается несколькими крупными платформами, но я искал что-то, что могло бы легко использоваться автономным приложением Java, не будучи гигантским.
Есть предложения?
Редактировать: По моему опыту, фреймворки имеют тенденцию расти как часть зрелости (и тоже сложные). Мне нужно, чтобы это можно было перенастроить в унаследованное приложение как часть основного рефакторинга (технического долга), поэтому для используемых библиотек важна простота. Я не возражаю против того, чтобы в нашем приложении было немного кодирования, но должно быть очень хорошо видно, что происходит. У АОП есть тенденция убирать вещи с дороги, и это может усложнить поддержку приложения.
Редактировать: Теперь мы достигли точки, когда нам действительно нужно принять решение. Приложение, вероятно, будет жить в течение десятилетий, поэтому нам нужно принять обратимое решение с помощью структуры, которая будет сохраняться, как мы надеемся, так долго. Мне действительно нравится статическая проверка типов, доступная в Guice, но не то, чтобы аннотации явно привязывались к Guice, а не были внешними, как в Spring. Мне также нравится, что этот код выглядит более лаконичным при использовании Guice, а не Spring. Нам нужно что-то надежное и полезное. Нам не нужно больше, чем просто DI на данный момент. Есть ли прецедент, в котором однозначно написано «пойти на один из них?»
Редактировать 2011-07-27: Окончательное решение состояло в том, чтобы использовать API JSR-330 в коде и выбирать для каждого проекта, использовать ли Spring, Guice или Weld. Для автономных приложений Guice хорошо работал до реализации JSR-330.