Аналог System.Reflection.Emit в Java

был BCEL, но он с 2006 года не развивается.

Спасибо за инфу. Жалко что не развивается. Прочитав мануал с сайта апачи я понял что оно только классы умеет генерить, а упаковать их в jar можно только внешними средствами? (тупо запустив jar)

jar - это простой zip-архив. Паковать можно чем душе угодно.

Т.е. грубо говоря, заюзать java.util.zip, так?

java.lang.reflect.Proxy, не?

Не. Из прокси ты максимум что получишь - аналог C# делегата, тут речь идет именно о средствах генерации MSIL на лету и упаковки их в сборку (для жавы соответсвенно генерация жавовских байткодов и упаковки этого в банку jar).

http://asm.ow2.org/ ?

http://www.csg.is.titech.ac.jp/~chiba/javassist/

> System.Reflection.Emit

Почему не http://msdn.microsoft.com/en-us/library/system.codedom.compiler.aspx

http://asm.ow2.org/, http://cglib.sf.net. Только зачем классы, созданные на лету, паковать в JAR?

http://www.jboss.org/javassist/ Вроде бы так правильнее.

[Last Updated: March 12, 2004]

>> Почему не http://msdn.microsoft.com/en-us/library/system.codedom.compiler.aspx

Потому, что это компилятор, а нужно на лету создавать сборки, а не компилировать исходники.

>> http://asm.ow2.org/, http://cglib.sf.net. Только зачем классы, созданные на лету, паковать в JAR?

Спасибо за ссылки.

Зачем паковать в jar - вопрос отдельный. Есть задача из описания некоторого бизнес-процесса в виде, грубо говоря, блок-схем с набором примитивов генерить соответсвующий код и встроть его в некую workflow management system в виде плагина. Сама система самописная поэтому приходится вот так изголяться. Кокретно, хочется, чтобы при разработке плагинов свести труд программера к минимуму и отдать все на откуп всяческим менеджерам и бизнесам. Большая часть уже готова (генерация юзерских интерфейсов из описания процесса, генерация необходимых таблиц/видов/процедур в БД, сама система проектирования процессов), осталось дел за малым. Конечно можно и не паковать в JAR, а по имеющемуся описанию сгенерить необходимый код и оставить его висеть в памяти, однако также хочется, чтобы готовый код можно было использовать еще где-то (в частности, к системе имеется и тонкий и толстый клиент, готовые плагины должны цепляться к толстому клиенту) и при необходимости иметь возможность править его руками. Вот как-то так.

может лучше тогда заюзать скриптовый язык типа groovy?

Такой вапиант тоже рассматривается, но пока как резервный.

> это компилятор > нужно на лету создавать сборки, а не компилировать исходники.

Поделил на 0. Подсовываешь ему на лету сгенеренные исходники - он возвращает тебе сборку, разница с emit одна - вместо мозгоёбства с msil ты работаешь с чистыми сорцами. Удобнее же подсовывать сорцы чем ассемблерные полотна, правда?

Ну в принципе тоже вариант...