Действительно ли возможно упаковать все зависимости от банки в одной большой банке?

Я использовал плагин сборки maven с дескриптором jar-with-dependencies

Используя старый добрый Ant:

• Вы можете распаковывать файлы и перепаковывать их с помощью командной строки

• Вы можете использовать [uberjar]

• Вы можете использовать fatjar

Eclipse 3.4 и выше позволяет вам это делать. Щелкните проект правой кнопкой мыши, выберите «Извлечь» и перейдите к параметру «Runnable Jar». Выберите "Далее". Выберите подходящие настройки и начните работу. Также я, кажется, припоминаю, что эта функциональность достигается с использованием тех же или подобных библиотек, которые использует FatJar (упомянутый выше).

Just for completeness, ProGuard will do this for you, as well as optionally obfuscating and shrinking JARs. The latter function is especially useful for creating final deployment JARs.

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

If you want to do this there is a tool called Jar Jar Links which will do this for you. Never used it but it is hard to forget the name.

Часто можно, но иногда есть необычные юридические или технические причины не делать этого.

• Юридические: Например, мы обнаружил, что в то время, когда мы хотели, мы не могли объединить jar-файлы JavaMail в один большой пакет с остальной частью нашего приложения, но в лицензионном соглашении говорилось, что мы должны хранить их отдельно.

• Технические: Другой Проблема может заключаться в том, что пользовательские загрузчики классов ищут определенные ресурсы или классы внутри определенных файлов jar. Это часто случается в контексте контейнеров для серверов приложений или ESB.

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

Я считаю, что называть работу One-Jar ужасной и плохой - несправедливо. Для приложения среднего размера можно ожидать, что запуск займет на пару секунд больше (что не влияет на экран-заставку JVM). Накладные расходы на память в десятки мегабайт незначительны для большинства сред, за исключением, возможно, встроенных систем. Кроме того, One-Jar может автоматически извлекать некоторые файлы в файловую систему, что избавляет от необходимости разрабатывать установщик в моем случае.

Ниже представлена ​​попытка количественно оценить влияние One-Jar на производительность моего приложения на производительность. Это приложение с графическим интерфейсом на основе Swing, состоящее из 352 классов, запутанных с помощью ProGuard 4.5b2. One-Jar 0.96 используется для объединения результирующих классов с библиотеками объемом 12 МБ (ODFDOM, Saxon HE, Xerces, Jaxen, VLDocking, Apache Commons и т. Д.). Я сравнил производительность обфусцированного jar-файла с таким же jar-файлом, обработанным One-Jar.

• От начала JVM до начала метода main (): 0,5 с без One-Jar и 1,7 с с One-Jar. От запуска JVM до появления окна приложения на экране: 2,3 с без One-Jar и 3,4 с с One-Jar. Таким образом, One-Jar увеличивает время запуска на 1,1 с.
• One-Jar не увеличивает задержку между запуском JVM и появлением на экране заставки (если реализовано через манифест jar), поэтому увеличение времени запуска не слишком раздражает для интерактивных приложений.
• Мы говорим о загрузчике классов, поэтому он не должен влиять на скорость выполнения кода, если только вы не широко используете динамическую загрузку классов.
• Просмотр статистики JVM (через jconsole) показывает, что версия One-Jar'red требует больше памяти кучи.Для моего приложения накладные расходы составляют порядка десятков МБ. Я видел такие цифры, как 16 МБ против 40 МБ, 306 МБ против 346 МБ, 131 МБ против 138 МБ, в зависимости от того, сколько пользовательских данных обрабатывает приложение, и теперь уже давно был запущен сборщик мусора.

Указанное выше время было получено путем получения метки времени непосредственно перед запуском JVM из оболочки Linux, в начале метода main () и в обработчике событий windowOpened () окна моего приложения. Измерения проводились на не очень быстром ноутбуке D820 с двухъядерным процессором 1 ГГц и 2 ГБ или оперативной памятью под управлением Ubuntu 8.04.

Надеюсь, это поможет.

One-JAR загружает все jar-файлы зависимостей в память при запуске. Это может показаться ужасно неэффективным, но никто не жаловался мне на это с момента его выпуска в 2004 году. Вероятным эффектом предварительной загрузки является общее ускорение загрузки классов для приложения, поскольку загрузчик классов не должен многократно сканировать путь к классам. для ресурсов и классов во время работы приложения: все хэшируется.

Довольно просто создать ленивый загрузчик, который будет загружаться по запросу: но я из школы, которая говорит: «Постройте, измерьте, улучшите, если необходимо», и до сих пор в этом не было необходимости чтобы улучшить это.

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