Каковы различия между различными плагинами Java для перезагрузки горячего класса и какой из них наиболее интуитивно понятен?

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

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

Плагины Java, которые я нашел, которые, как я думаю, могут выполнять эту работу:

Значит, кто-нибудь знает, какие различия между плагинами? А также какой плагин наиболее интуитивно понятен?

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

Ответ 1

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

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

Решения для модуляции, такие как OSGi или Модули JBoss, обеспечивают преимущества, если вы будете следовать правильному пути и модулизировать свое приложение. В противном случае, если вы развертываете один комплект силоса, это в основном означает, что вы перезапускаете/перераспределяете все приложение, тем самым уменьшая любые преимущества, получаемые от этого подхода.

Play Framework представляет собой полнофункциональную инфраструктуру с возможностями "горячего развертывания". Эти возможности различаются в зависимости от версии используемой структуры. Но опять же, такая же история, как и с модулярностью - структура обеспечивает определенную модель программирования.

Apache Commons JCI на самом деле не является решением для горячего обновления кода. AFAIK, он просто компилирует и загружает класс через новый загрузчик классов. Это также связано с изменением кода приложения, как в случаях, упомянутых выше. Я не уверен, хорошо это или плохо. Недостатком является то, что вы вряд ли можете сделать какую-либо широкую интеграцию с экосистемой таким образом. Такой подход является вполне осуществимым для самодельной структуры, которая использовала бы эту функцию. Я бы предпочел использовать язык сценариев, например, Groovy, JRuby или JavaScript для достижения того же. Например, this, например.

JRebel, Fakereplace и DCEVM - эти ребята не заботятся о модели программирования. Но разница довольно большая:

DCEVM исправляет JVM, и его целью является предоставление полного решения hotswap, которое оно делает.

JRebel - это java-агент (подключенный с аргументом -javaagent VM), который обрабатывает код приложения и загружает новые версии классов путем их версии. Основное значение JRebel заключается в том, что он обеспечивает гибкую конфигурацию наряду с огромным объемом интеграции с каркасом, так что вы можете сделать намного больше, чем просто hotswap классов java. Например, добавьте и запустите autowire новый beans в контексте приложения Spring, добавьте новые EJB на лету, а также новые действия Struts и т.д.

Fakereplace также является инструментальным агентом, например JRebel, но он намного меньше поддерживает изменения кода Java (я полагаю), и число поддерживаемых фреймворков не является как впечатляет.

Feenix может делать столько, сколько позволяет API Java Instrumentation API. Что в основном означает, что на самом деле это не добавляет ценности поверх стандартного HotSwap JVM. То же самое для AgentSmith

ОБНОВЛЕНИЕ: этот ответ побудил автора Feenix придумать новую версию - Feenix 2.0, которая похожа на то, как JRebel работает с классами. Но, как говорит сам автор, Феникс все еще значительно уступает Джеребу. Существует также несколько аналогичных решений, таких как HotswapAgent и Spring Загруженные. Эти инструменты также предоставляют аналогичную функциональность, но ограничены по-своему.

Теперь немного по вашей конкретной проблеме, как это можно решить с помощью JRebel:

Каждый модуль приложения должен иметь свой собственный конфигурационный файл, rebel.xml. Под модулем мы подразумеваем либо EAR, WAR, либо любую из JAR-зависимостей в WEB-INF/lib (например, в вашем случае) или серверных библиотек. Файл конфигурации с указанием каталога, в котором скомпилированы классы, и JRebel будет загружать классы непосредственно из этого местоположения. Все это означает, что вы не должны собрать весь JAR после внесения изменений в класс Java. Вместо вы делаете изменения и компилируете исходный код (используйте IDE вместо сборки script). Скомпилированный класс будет перезагружен JRebel после вызова класса в коде приложения.

Ответ 2

В блоке появился новый ребенок, RelProxy, он с открытым исходным кодом, не настолько продвинут, как JRebel, но его можно использовать свободно изменять подмножество вашего кода во время выполнения и перезагружать его практически без потери производительности и не нуждаться в перегрузке контекста (без потери сеанса) в разработке и производстве, если вы хотите.