Java custom class loader

[Don Cherry]

Мой Java class loader с простым кодом
public class MyClassLoader(...) extends ClassLoader
{
...
defineClass(...)
}
не проверяет был ли класс загружен раньше, и работает "правильно",
т.е. я обновляю mycode.java , компилирую, mycode.class обновлён, каждый раз загружается заново, и я вижу результат моих обновлений.
Удобно для development, не надо перезагружать server или application, делать deployment после каждого изменения кода.

Подскажите, что происходит с mycode.class ми которые уже были загружены ранее?
Похоже они накапливаются в heap и размер памяти используемый моим application растёт, или JVM всё-таки без меня как-то сама проверяет это перед загрузкой новой копии mycode.class ?

Спасибо.

[helg]

Сказанное работает некорректно. При изменении mycode надлежит перегружать все классы, которые знают про mycode: могут содержать его экземпляры, вызовы его методов и обращения к их данным. Ну и далее, по дереву зависимостей всё надо перегрузить или вычистить.

Кроме некорректной работы, есть и утечка памяти. Старый байткод класса остаётся в памяти, поскольку из других классов на него остались ссылки.

[Don Cherry]

Сказанное работает некорректно. При изменении mycode надлежит перегружать все классы, которые знают про mycode: могут содержать его экземпляры, вызовы его методов и обращения к их данным. Ну и далее, по дереву зависимостей всё надо перегрузить или вычистить.

Кроме некорректной работы, есть и утечка памяти. Старый байткод класса остаётся в памяти, поскольку из других классов на него остались ссылки.

Ответ понятен, спасибо.
The default system class loader ведёт дерево зависимостей, проверяет, чистит, перезагружает...
Если писать свой class loader, надо всё это делать самому...
Проще сделать redeploy [application or server restart], но требуется время. Если app большое, и в зависимости от мощности компьютера, то может требываться 1-3 минуты. Эта причина по которой я написал этот пост, developers меняют код, делают redeploy, ждут 2 минуты ничего не делая, только после этого видят результат своих изменений.
Даже меняя код на .html, .xhtml, .property ... files приходится делать redeploy. Я бы сказал это бред так работать.

Есть ли какое-нибудь "умное" решение для этого?
Например, можно ли заменить default system class loader [for development only, on each local work station], т.е. избегать deployment step ?
code change -> compile -> run
instead of
code change -> compile -> deploy/app/server restart -> run

Спасибо.

[helg]

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

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

[Don Cherry]

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

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

Как-то не верится,
что единтсвенный путь - оптимизация приложения,
что все Java [Tomcat, JBoss, WebSphere, Oracle] девелоперы in the world нажимают Save code, и потом app/server restart, и ждут "определённое время" чтобы увидеть/проверить результат своих обновлений кода.

Может есть возможность для development only:
Step 1 - Использовать custom class loader [with "always" load .class], instead of default system one
Step 2 - Компилировать outside of Eclipse or NetBeans [т.е. в cmd.exe] и копировать .class files в server folder
например Tomcat ...\webapps\myapp\WEB-INF\classes\...

В моём случае compile and copy занимает - 2 секунды, restart app/server - 2 минуты.
Разница 60 раз, ~80% времени программисты ждут ничего не делая.

Может кто-то об этом думал и что-то придумал?
В Oracle и Apache об этом не думают?
За такую оптимизацию труда могут предложить должность VP of Engineering.

[John Smith]

JRebel ?

[Aleksey Kudinov]

JRebel ?

+1
есть у него заморочки, но в большинстве случаев вполне работает as promised

[Palych]

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

Если пойти еще более радикальным путем - можно обвешать систему unit testами (причем unit не обязательно суть class) и писать/запускать вообще без контейнера...
А в контейнере пущать уже более-менее готовый код.

[helg]

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

[Sergunka]

Вам следует ознакомится с концепцией OSGi контейнера.

https://en.wikipedia.org/wiki/OSGi" onclick="window.open(this.href);return false;

там сервис можно подцеплять влет на горячем сервере. И как правильно заметил helg большинство IDE просто могут делать изменения во время отладки. Понятно что если целый бандл то прийдется перезапустить бандл.

[helg]

Вдогонку.

Поставьте приложение в эклипс на томкат и в настройках веб-сервера в эклипсе поставьте галочку "serve modules without publishing". Иногда чтобы заработало надо ещё в нужных местах путей дописать и добавить маппинга в конфигурацию томката.

Это сэкономит время на упаковку-распаковку war-архива. Для многомегабайтного war это как раз и будет требуемый выигрыш с 2 минут до 2 секунд, если меняется java код. А для статики (html/js/css) и динамически компилируемых модулей (jsp) даже 2 секунд не надо: меняем в редакторе, записываем - и сразу видим в навигаторе.

[fruit6]

JRebel ?

+1
есть у него заморочки, но в большинстве случаев вполне работает as promised

я предпочитаю DCE VM