[room] java devel

[room] java devel

[Eugene Prokopiev]

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 это полное уродство.

Но помимо инфраструктуры для запуска, которая всегда относительно
проста, есть еще и внутренние паттерны для чего-то среднего между
прикладными и системными решениями, которые иногда достигают
реюзабельного состояния. Вот они как раз и были бы мне интересны ;)

Пример своих я в блоге публиковал, если у тебя что похожее накопится -
не прячь :)

-- 
С уважением,
Прокопьев Евгений

Re: [room] java devel

[Денис Смирнов]

On Fri, Feb 20, 2009 at 02:55:29PM +0300, Eugene Prokopiev wrote:

EP> Спасибо, познавательно. Хотя мне до сих пор не требовалась компиляция
EP> в нативный код (и у меня есть сомнения в том, что она всегда корректно
EP> будет работать) и обфускатор. 

Что меня удивило -- даже reflections работают. С asterisk-java пока все
гладко. Jetty пока не компилировал, но сегодня-завтра буду :)

EP> Я вполне доволен jakarta commons daemon.
EP> Мне именно этот вариант видится самым прямым, хотя большинство
EP> проектов стартуют с использованием /usr/bin/java, а останавливаются
EP> так: слушают некий порт, и, если с локалхоста пришел соответствующий
EP> пакет, тушат свет и выходят. Собственно под эту схему пишутся и
EP> инитскрипты. Но в сравнении с jsvc это полное уродство.

Ужас-ужас. А в java SIGTERM/SIGHUP и т.д. никак ловить нельзя?

EP> Но помимо инфраструктуры для запуска, которая всегда относительно
EP> проста, есть еще и внутренние паттерны для чего-то среднего между
EP> прикладными и системными решениями, которые иногда достигают
EP> реюзабельного состояния. Вот они как раз и были бы мне интересны ;)
EP> Пример своих я в блоге публиковал, если у тебя что похожее накопится -
EP> не прячь :)

Ну, у меня пока нет готового ничего. Скорее всего скоро будут готовы
proguard-шаблоны для отдельных библиотек, их наверное буду выкладывать.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

Re: [room] java devel

[Eugene Prokopiev]

21.02.09, Денис Смирнов написал(а):
> On Fri, Feb 20, 2009 at 02:55:29PM +0300, Eugene Prokopiev wrote:
>
>  EP> Спасибо, познавательно. Хотя мне до сих пор не требовалась компиляция
>  EP> в нативный код (и у меня есть сомнения в том, что она всегда корректно
>  EP> будет работать) и обфускатор.
>
>  Что меня удивило -- даже reflections работают.

Как я понимаю, это означает, что компилятор там не совсем честный ;)

>  С asterisk-java пока все
>  гладко. Jetty пока не компилировал, но сегодня-завтра буду :)

А ты не используешь ничего, что умело бы генерить байт-код на лету?
Неужто и оно не сломается? ;)

>  EP> Я вполне доволен jakarta commons daemon.
>  EP> Мне именно этот вариант видится самым прямым, хотя большинство
>  EP> проектов стартуют с использованием /usr/bin/java, а останавливаются
>  EP> так: слушают некий порт, и, если с локалхоста пришел соответствующий
>  EP> пакет, тушат свет и выходят. Собственно под эту схему пишутся и
>  EP> инитскрипты. Но в сравнении с jsvc это полное уродство.
>
>  Ужас-ужас. А в java SIGTERM/SIGHUP и т.д. никак ловить нельзя?

Ну так именно этим jsvc (бинарник, написанный на С) и занимается: при
старте поднимает JVM и вызывает метод start() класса, реализующего
интерфейс Daemon, повторяет эту процедуру в случае падения JVM, при
получении сигнала вызывает метод stop() реализации того же интерфейса.
Инитскрипт под эту схему выглядит вполне прилично. При желании можно
дописать поддержку любых сигналов, но это сломает совместимость с
аналогичным бинарником для винды, где, насколько я понимаю, для
сервисов не предусмотрены события, отличные от start/stop.

>  EP> Но помимо инфраструктуры для запуска, которая всегда относительно
>  EP> проста, есть еще и внутренние паттерны для чего-то среднего между
>  EP> прикладными и системными решениями, которые иногда достигают
>  EP> реюзабельного состояния. Вот они как раз и были бы мне интересны ;)
>  EP> Пример своих я в блоге публиковал, если у тебя что похожее накопится -
>  EP> не прячь :)
>
>  Ну, у меня пока нет готового ничего. Скорее всего скоро будут готовы
>  proguard-шаблоны для отдельных библиотек, их наверное буду выкладывать.

Может вернуть апстриму? ;)

-- 
С уважением,
Прокопьев Евгений

Re: [room] java devel

[Денис Смирнов]

On Tue, Feb 24, 2009 at 08:02:12AM +0300, Eugene Prokopiev wrote:
>  EP>> Спасибо, познавательно. Хотя мне до сих пор не требовалась компиляция
>  EP>> в нативный код (и у меня есть сомнения в том, что она всегда корректно
>  EP>> будет работать) и обфускатор.
>>  Что меня удивило -- даже reflections работают.
EP> Как я понимаю, это означает, что компилятор там не совсем честный ;)

Для Java нельзя сделать _совсем_ честный компилятор ;) Но, главное, вся
математика компилируется.

>>  С asterisk-java пока все
>>  гладко. Jetty пока не компилировал, но сегодня-завтра буду :)
EP> А ты не используешь ничего, что умело бы генерить байт-код на лету?

Нет, а что это может быть, например?

EP> Неужто и оно не сломается? ;)

Думаю сломается :)

>>  Ужас-ужас. А в java SIGTERM/SIGHUP и т.д. никак ловить нельзя?
EP> Ну так именно этим jsvc (бинарник, написанный на С) и занимается: при
EP> старте поднимает JVM и вызывает метод start() класса, реализующего
EP> интерфейс Daemon, повторяет эту процедуру в случае падения JVM, при
EP> получении сигнала вызывает метод stop() реализации того же интерфейса.
EP> Инитскрипт под эту схему выглядит вполне прилично. При желании можно
EP> дописать поддержку любых сигналов, но это сломает совместимость с
EP> аналогичным бинарником для винды, где, насколько я понимаю, для
EP> сервисов не предусмотрены события, отличные от start/stop.

Разве не логично, что версия под UNIX просто может обрабатывать больше
сигналов, а тот же бинарник под виндой просто не сможет обработать те
события которые система ему не предоставит?

Мне непонятно почему отрезают функционал который UNIX-only. Как и с UNIX
sockets которые чем-то санкам не нравятся :(

>>  Ну, у меня пока нет готового ничего. Скорее всего скоро будут готовы
>>  proguard-шаблоны для отдельных библиотек, их наверное буду выкладывать.
EP> Может вернуть апстриму? ;)

Апстрим насколько я вижу не занимается коллекционированием таковых. Потому
как дело это очень индивидуальное -- мне вот ряд классов в log4j не нужны
и я их отрежу. А кому-то -- нужны. Я вон из всего log4j только логгинг в
файлы и использую, могу для себя все остальное отрезать. Не все поступят
также :)

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

Re: [room] java devel

[Eugene Prokopiev]

> EP> А ты не используешь ничего, что умело бы генерить байт-код на лету?
>
>  Нет, а что это может быть, например?

ORM-фреймворки активно такое практикуют, AOP-фреймворки, наверное, тоже

>  EP> Неужто и оно не сломается? ;)
>
>  Думаю сломается :)

Ну в общем, я даже пробовать, наверное, не буду ;)

>  >>  Ужас-ужас. А в java SIGTERM/SIGHUP и т.д. никак ловить нельзя?
>
> EP> Ну так именно этим jsvc (бинарник, написанный на С) и занимается: при
>  EP> старте поднимает JVM и вызывает метод start() класса, реализующего
>  EP> интерфейс Daemon, повторяет эту процедуру в случае падения JVM, при
>  EP> получении сигнала вызывает метод stop() реализации того же интерфейса.
>  EP> Инитскрипт под эту схему выглядит вполне прилично. При желании можно
>  EP> дописать поддержку любых сигналов, но это сломает совместимость с
>  EP> аналогичным бинарником для винды, где, насколько я понимаю, для
>  EP> сервисов не предусмотрены события, отличные от start/stop.
>
>  Разве не логично, что версия под UNIX просто может обрабатывать больше
>  сигналов, а тот же бинарник под виндой просто не сможет обработать те
>  события которые система ему не предоставит?

Система, запущенная в винде будет иметь ограничения по функционалу, а
это в корне противоречит идее кроссплатформенности. Т.е. лучше уж
пусть те, кому сильно надо, изобретут свои переносимые велосипеды, не
связанные со спецификой UNIX.

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

А еще код commons daemon достаточно компактный и читаемый, чтоб при
большом желании все-таки прострелить себе ногу ... ;)

>  Мне непонятно почему отрезают функционал который UNIX-only. Как и с UNIX
>  sockets которые чем-то санкам не нравятся :(

А вот тут можно было бы иметь идентичный интерфейс для всех платформ +
дополнительную семантику для UNIX - ущерба винде не было бы, так что
тут я санкам оправдания найти не могу

>  >>  Ну, у меня пока нет готового ничего. Скорее всего скоро будут готовы
>  >>  proguard-шаблоны для отдельных библиотек, их наверное буду выкладывать.
>
> EP> Может вернуть апстриму? ;)
>
>  Апстрим насколько я вижу не занимается коллекционированием таковых. Потому
>  как дело это очень индивидуальное -- мне вот ряд классов в log4j не нужны
>  и я их отрежу. А кому-то -- нужны. Я вон из всего log4j только логгинг в
>  файлы и использую, могу для себя все остальное отрезать. Не все поступят
>  также :)

Угу, понятно ...

-- 
С уважением,
Прокопьев Евгений

Re: [room] java devel

[Денис Смирнов]

On Thu, Feb 26, 2009 at 09:14:01AM +0300, Eugene Prokopiev wrote:

EP> Система, запущенная в винде будет иметь ограничения по функционалу, а
EP> это в корне противоречит идее кроссплатформенности. Т.е. лучше уж
EP> пусть те, кому сильно надо, изобретут свои переносимые велосипеды, не
EP> связанные со спецификой UNIX.

Гм. Еще раз:

В винде обрабатываются только start/stop, потому что другого там нет. Но
если интерфейс будет также позволять реализовать, например, обработку
sighup -- это будет означать только то, что на винде этим воспользоваться
не получится, не более того. Просто сервис запущеный под UNIX будет иметь
дополнительный функционал.

Кто мешает?

EP> Кстати, штатный способ управления уже запущенным сервисом (перечитать
EP> конфиг, записать/прочитать некие переменные и т.д.) - JMX, так что
EP> проблема не особенно актуальна. В качестве клиента JMX и не только
EP> см., например, OpenNMS - его у нас даже пакетили

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

EP> А еще код commons daemon достаточно компактный и читаемый, чтоб при
EP> большом желании все-таки прострелить себе ногу ... ;)

Ох... :)

>>  Мне непонятно почему отрезают функционал который UNIX-only. Как и с UNIX
>>  sockets которые чем-то санкам не нравятся :(
EP> А вот тут можно было бы иметь идентичный интерфейс для всех платформ +
EP> дополнительную семантику для UNIX - ущерба винде не было бы, так что
EP> тут я санкам оправдания найти не могу

Ну почему же одинаковым -- параметры при создания сокета совсем другие.
При _работе с ним_ -- да, все Ok. Но приложение которое попытается на
винде открыть UNIX socket получит соответствующий exception, например.
Вполне логично, не правда ли?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

Re: [room] java devel

[Eugene Prokopiev]

Вот тебе еще в копилку ужасов (может пригодиться в качестве соломки) -
http://rsdn.ru/forum/message/3307616.flat.aspx#3307616

-- 
С уважением,
Прокопьев Евгений

Re: [room] java devel

[Денис Смирнов]

On Fri, Feb 27, 2009 at 07:55:13PM +0300, Eugene Prokopiev wrote:

EP> Вот тебе еще в копилку ужасов (может пригодиться в качестве соломки) -
EP> http://rsdn.ru/forum/message/3307616.flat.aspx#3307616

Ужас-ужас-ужас.
С датой/временем вообще почти везде какие-нибудь сложности :)

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

Re: [room] java devel

[Eugene Prokopiev]

28.02.09, Денис Смирнов написал(а):
> On Fri, Feb 27, 2009 at 07:55:13PM +0300, Eugene Prokopiev wrote:
>
>  EP> Вот тебе еще в копилку ужасов (может пригодиться в качестве соломки) -
>  EP> http://rsdn.ru/forum/message/3307616.flat.aspx#3307616
>
>  Ужас-ужас-ужас.
>  С датой/временем вообще почти везде какие-нибудь сложности :)

Виноват-таки оказался линукс: после apt-get install glibc-timezones
поведение нормализовалось :) Странно, что time работал ...

-- 
С уважением,
Прокопьев Евгений

Re: [room] java devel

[Денис Смирнов]

On Sun, Mar 01, 2009 at 04:44:46PM +0300, Eugene Prokopiev wrote:

>>  Ужас-ужас-ужас.
>>  С датой/временем вообще почти везде какие-нибудь сложности :)
EP> Виноват-таки оказался линукс: после apt-get install glibc-timezones
EP> поведение нормализовалось :) Странно, что time работал ...

apt-get install appliance-base-glibc избавит от многих таких странностей.
В том числе и с i18n :)

Вообще рекомендую ознакомиться с appliance-*. Mithraen хоть и ламер, но
сделал их совсем не зря ;)

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------