Определение, какие минимальные банки необходимы для функции
Как Вы определяете, какие банки необходимы для такой и такая функция платформы? Например, какие банки были бы необходимы из всех доступные для Spring для поддержки только внедрения зависимости?
3 ответа
Существуют инструменты, которые создают минимальные JAR, выясняя, какие классы действительно используются в приложении путем статического анализа кода, а затем создавая новый JAR, содержащий только эти классы. (Я помню, что использовал для этого Zelix Classmaster, но есть много альтернатив).
Проблема с использованием этих инструментов для DI-фреймворка, такого как Spring, заключается в следующем:
Существующие инструменты отслеживают только статические зависимости. Если вы динамически загружаете классы, вам придется специально сообщать анализатору о каждом из них. DI-фреймворки в целом и Spring в частности изобилуют динамической загрузкой, включая динамическую загрузку, непрозрачную для кода приложения.
Существующие инструменты работают, создавая новый выходной JAR, а не сообщая вам, какие из входных JAR не используются. Хотя переупаковка JAR'ов - это нормально, если вы создаете приложение в сжатой упаковке из закрытой кодовой базы, это нежелательно в целом и потенциально проблематично с некоторыми лицензиями на открытый исходный код. Конечно, вы не захотите делать этого с Spring.
Теоретически, кто-то может написать инструмент для помощи. На практике, инструмент должен (например) знать, как извлекать динамические зависимости классов из конфигураций Spring, выраженных в аннотациях, XML и из дескрипторов бобов, созданных во время выполнения из конфигурации более высокого порядка (SpringSecurity делает это, например). Это большая просьба. И даже тогда возникает проблема, что "небольшое" изменение в схеме, сделанное на платформе установки, может не сработать из-за того, что нужный JARs был исключен процессом обрезки JAR.
На мой взгляд, более практичными альтернативами являются:
- Если вы используете Maven / Ivy для управления зависимостями, посмотрите на графы зависимостей, удалите зависимости, которые кажутся больше не нужными ... и тестируйте, тестируйте, тестируйте.
- Вручную удалите JAR, которые кажутся неиспользуемыми... и тестируйте, тестируйте, тестируйте.
- Не беспокойтесь об этом. Умеренный уровень неиспользуемых JAR может добавить секунду или три к времени развертывания и запуска веб-приложения, но это обычно не имеет значения. (Но если имеет... см. выше.)
Вот почему некоторые старые проекты Java содержат 600 Jar-файлов и 200-мегабайтный war-файл для приложения на 10 000 строк. Ужасно, если вы не справитесь с этим осторожно ...
Вам действительно следует спросить поставщика инфраструктуры или прочитать документацию. Статического анализа того, какие jar-файлы требуются, в некоторых случаях может быть недостаточно (динамическая загрузка), а иногда может получиться слишком много jar-файлов.
Однажды я сделал несколько вспомогательных файлов ftp для своего рода «служебной» библиотеки. Это зависело от какой-то apache ftp jar. Если вы никогда не использовали возможности ftp в библиотеке, вам не понадобится ftp jar, но статический анализ кода может сказать, что он вам нужен. Это то, что вы должны документировать.