igor_suhorukov Dec 22 2015 at 17:06

Java вместо Groovy

6 min

17K

Website development*Programming*Java*Groovy & Grails*

+12

Comments 28

xGromMx Dec 22 2015 at 19:04

Гляньте на kotlinlang.org

igor_suhorukov Dec 22 2015 at 19:12

Спасибо, уже смотрел! Как Kotlin может помочь в проектах с унаследованным кодом при запрете использовать что-либо кроме java?

xGromMx Dec 22 2015 at 19:28

Это же JVM) он также работает с Java как и Scala или Groovy

igor_suhorukov Dec 22 2015 at 19:36

Groovy/Scala тоже JVM. Ограничение относится к гомогенности разработки — запрету на добавление новых языков в проект.

andrewsch Dec 22 2015 at 22:00

А не возникает проблем с каким-нибудь мусором от класс-лоадера в случае, если такие скрипты массово запускаются по расписанию, и соответственно постоянно перекомпилируются?

igor_suhorukov Dec 22 2015 at 22:13

С таким вариантом использования не сталкивался. Но если нет утечек классов и класслоадеры не создаются миллиардами в короткий интервал времени, то не вижу проблем с выгрузкой классов при GC

andrewsch Dec 22 2015 at 22:17

мы активно используем Groovy скрипты для всяких нестандартных задач (импортов или расчетов), запускаемых по расписанию. Так мы их сознательно запускаем в режиме интерпретатора, без компиляции. Но это сделано на основе теоретических опасений, так сказать, во избежание. Интересно, насколько проблема нами выдумана…

igor_suhorukov Dec 22 2015 at 22:31

Из практики все утечки классов в jvm которые я видел были связаны с ошибками в ПО и лишь один раз точно помню Алексей Рагозин на проекте рассказывал, что утечку памяти в тестах, которую я обнаружил в наших тестах на vicluster-coherence (ныне nanocloud), это не утечка — а особенность сборщика мусора при UseConcMarkSweepGC и большой интенсивности создания новых загрузчиков. Тогда поверил на слово и не стал вгрызаться в детали

igor_suhorukov Dec 22 2015 at 22:40

Раньше был PermGen, теперь MetaSpace… Но суть утечек классов одна — ошибки в ПО и ссылки на классы или их загрузчики. Вот несколько примеров как их избежать в веб приложении

Morj Dec 23 2015 at 01:32

Если интересно, посмотрите библиотеку Javassist. github.com/jboss-javassist/javassist jboss-javassist.github.io/javassist
Стабильная, LGPL, существует с 1999. Умеет полноценно компилировать сорцы в памяти. Наследовать существующие классы, с импортами, например.

igor_suhorukov Dec 23 2015 at 08:48

Спасибо за совет! Есть разница в удобстве работы между компилятором ecj и javassist, о чем я уже писал «Модификация программы и что лучше менять: исполняемый код или AST программы?». Также есть библиотеки
ASM, javassist, BCEL, CGLIB

Morj Dec 23 2015 at 11:22

Я посмотрел вашу статью, в ней нет прямых указаний, чем ecj удобнее именно для геренации новых классов на рантайме. Одним из очевидных недостатков высокоуровнего API javassist является отсутствие поддержки generics, но насколько это важно?

igor_suhorukov Dec 23 2015 at 11:37

Отредактировать исходный код в любом редакторе удобнее и компиляция на лету, с полной поддержкой конструкций языка удобнее чем, чем манипуляции с API для генерации байткода. У javassist/asm своя ниша, где ими удобнее решать задачи: модификация существующего байткода без исходников

-1

Morj Dec 23 2015 at 11:54

Я согласен, но всё-таки для скриптинга скорее пригодится не загрузка класса из файла целиком, а только части. Если речь идёт о замене хотсвапа, то тогда ваше решение, конечно, лучше. Интересно, в вашем проекте вот эти файлы, которые потом динамически грузятся, они лежат под source control?

igor_suhorukov Dec 23 2015 at 12:03

Нет, в файловой системе или на веб. Хотя в планах хранить в git скрипты

Morj Dec 23 2015 at 12:05

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

igor_suhorukov Dec 23 2015 at 12:58

В том числе и динамического расширения функциональности. OSGI вполне решил бы большую часть динамизма системы и модулей

igor_suhorukov Dec 23 2015 at 11:43

Каждой задаче надо подбирать свой более подходящий инструмент (учитывая все ограничения задачи и инструмента, стоимость эксплуатации)

Agb Dec 23 2015 at 08:18

Думаю, вам так же будет интересен такой подход habrahabr.ru/company/haulmont/blog/248981

igor_suhorukov Dec 23 2015 at 09:00

Спасибо, это тот же JSR 199 (Java 1.6 — ToolProvider.getSystemJavaCompiler ). Без уже установленного tools.jar в этом подходе реализацию компилятора не найти. По хорошему надо носить с собой компилятор и искать его как-то так (CompilerUtil):

ServiceLoader<JavaCompiler> javaCompilers = ServiceLoader.load(JavaCompiler.class);
for (JavaCompiler javaCompiler : javaCompilers) {
     return javaCompiler;
}

и только после этого

ToolProvider.getSystemJavaCompiler();

>>Как еще можно быстро доставить изменения на сервер -> «Второй способ — Hot Deploy»
сюда же можно добавить OSGI

gurinderu Dec 23 2015 at 10:29

igor_suhorukov
Зачем использовать вместо, когда можно использовать вместе ?)

igor_suhorukov Dec 23 2015 at 10:37

Причины в статье и в коментариях. Вместе конечно лучше

tinhol Dec 23 2015 at 15:06

Как автор похожего решения хотел бы задать вам несколько вопросов.

1. Как реализована совместная компиляция и обновление зависимостей? Например я компилирую класс, от которого зависят другие динамически скомпилированные классы?
2. Есть ли кэш классов, и где он хранится (если есть)?
3. Не пробовали ли вы подружить вашу загрузку классов со Spring, или чем-то похожим?

igor_suhorukov Dec 23 2015 at 17:58

Это ваше решение? Молодцы!
А как вы живете с тем, что компилятор нельзя включать в свое решение и надо надеяться на tools.jar?

1. Не реализовано. Это удел систем типа JRebel или динамических систем типа OSGI. Мое мнение, что пока не будет реализовано в JVM JEP 159: Enhanced Class Redefinition. Каждая реализация такого механизма самостоятельно — очень сложная задача.
2. Классы кешируются в загрузчике org.codehaus.commons.compiler.jdk.JavaFileManagerClassLoader.
3. Не пробовал

tinhol Dec 23 2015 at 19:53

Спасибо за ответ.

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

igor_suhorukov Dec 23 2015 at 20:21

Интересный опыт!

UFO just landed and posted this here

igor_suhorukov Dec 29 2015 at 21:18

MVEL2 тоже похож на java, но не java и тоже менее навороченный

Show the best of all time