[room] java devel
Eugene Prokopiev
=?iso-8859-1?q?enp_=CE=C1_altlinux=2Eorg?=
Пт Фев 20 14:55:29 MSK 2009
20.02.09, Денис Смирнов написал(а):
> On Fri, Feb 20, 2009 at 01:12:28PM +0300, Eugene Prokopiev wrote:
>
> >> Но, увы, у меня используется просто множество своих костылей, вместо уже
> >> существующий в java-мире. Каждый псих изобретает свои костыли, и _это_ в
> >> мире java мне категорически не нравится.
> EP> Ты бы, кстати, как-нибудь описал свои костыли - может еще кому
> EP> захочется на них встать ;)
>
> А что тут описывать?
>
> Берется jar с тем что нужно (скажем какой-нибудь log4j). С помощью
> proguard из него вырезается все ненужное, отрабатывает оптимизатор
> proguard'а, возможно еще и обфускатор -- получается log4j для моих задач.
> И так с каждым jar'ом.
>
> Потом результат объединяется тем же proguard с собственно приложением.
> Далее опять отрабатывает оптимизатор (он удаляет неиспользуемые классы),
> и, если надо, обфускатор.
>
> Результирующий jar или готов к использованию, или сначала по нему еще
> проходится gcc-java.
>
> В результате не надо думать о том что "а вот с другой версией того jar'а
> ничего не заработает" или "а вот что будет если этого jar не окажется в
> системе?". Кроме того получается относительно компактное нечто (хотя и
> менее компактное чем jar -- у меня обычно бинарники в несколько мегабайт
> получаются). Ну и время запуска при использовании gcc-java доли секунды,
> ибо не надо поднимать тяжелую VM, компилировать байт-код, и прочей фигней
> заниматься.
>
> Запускаю я то что написал обычно с помощью daemontools. Никакие сервлет
> контейнеры и прочее не используется, ибо Jetty -- rulez :)
>
> Этап обрезания ненужного с помощью proguard -- самый емкий по времени.
> Писать конфиг что отрезать а что не стоит, то еще удовольствие. Зато
> результат получается компактный и шустрый. Ну и с некоторыми клиентами
> обфускатор бывает не лишним :)
Спасибо, познавательно. Хотя мне до сих пор не требовалась компиляция
в нативный код (и у меня есть сомнения в том, что она всегда корректно
будет работать) и обфускатор. Я вполне доволен jakarta commons daemon.
Мне именно этот вариант видится самым прямым, хотя большинство
проектов стартуют с использованием /usr/bin/java, а останавливаются
так: слушают некий порт, и, если с локалхоста пришел соответствующий
пакет, тушат свет и выходят. Собственно под эту схему пишутся и
инитскрипты. Но в сравнении с jsvc это полное уродство.
Но помимо инфраструктуры для запуска, которая всегда относительно
проста, есть еще и внутренние паттерны для чего-то среднего между
прикладными и системными решениями, которые иногда достигают
реюзабельного состояния. Вот они как раз и были бы мне интересны ;)
Пример своих я в блоге публиковал, если у тебя что похожее накопится -
не прячь :)
--
С уважением,
Прокопьев Евгений
Подробная информация о списке рассылки smoke-room