Real-time Java, первая часть серии статей IBM developerWorks, описывающая реализацию систем реального времени средствами Java.

>Deterministic garbage collection,

ну положим Deterministic gc полезен и без РТ

http://portal.acm.org/citation.cfm?id=604155

>>Deterministic garbage collection,

>ну положим Deterministic gc полезен и без РТ

а кто спорит? вопрос в другом зачем java в обработке RT?

А зачем вообще приносить технологию A в нишу B, где ее раньше не было?

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

> Почему б не попробовать притащить эти достоинства в рилтаймовые системы?

Потому что то, что туда притащат, уже не будет той Java, к которой все привыкли. Это как Java для смарт-карт: от Java только синтаксис и название.

>А зачем вообще приносить технологию A в нишу B, где ее раньше не было?

как это не было?

http://javolution.org/

http://java.sun.com/javase/technologies/realtime.jsp

http://www-306.ibm.com/software/webservers/realtime/

http://www.rtjcom.com/main.php?p=home

>А зачем вообще приносить технологию A в нишу B, где ее раньше не было?

не надо обобщать ;)

иначе получается, что надо все технологии засунуть во все ниши? фи ;)))

>Почему б не попробовать притащить эти достоинства в рилтаймовые системы?

чтобы создать новые проблемы, которых там не было?

>Потому что то, что туда притащат, уже не будет той Java, к которой все привыкли. Это как Java для смарт-карт: от Java только синтаксис и название.

так главное TM.

> Это как Java для смарт-карт: от Java только синтаксис и название.

Синтакс - это уже немало. А еще жабка для смарт карт хороша стандартизацией интерфейсов - приложение перестает (в идеале) зависеть от того, кто и как сделал смарт карту. Разве это не прекрасно? Идея WORA - хотя бы с точностью до класса задач (разумеется, никто на смарт карту не запихает eclipse или tomcat).

>> Это как Java для смарт-карт: от Java только синтаксис и название.

> Синтакс - это уже немало.

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

> А еще жабка для смарт карт хороша стандартизацией интерфейсов

Стандартизация интерфейсов - это ни разу не монополия Java. Этого можно достичь и без нее.

> иначе получается, что надо все технологии засунуть во все ниши? фи ;)))

Я не знаю, что такое "надо" в данном случае. В идеале - да, каждая технология хотела бы занять все ниши. Но когда технология пытается сунуться туда, где ей делать нечего - ее быстро оттуда выкидывают. Естественный эволюционный процесс. Обычно технологии просто не лезут туда, где совершенно точно им делать нечего - просто чтоб не тратить время разработчиков впустую. В данном же случае, очевидно, авторы считают, что для жабки есть место в мире рилтайма. Их право так считать. Никаких фундаментальных причин, почему бы им не попробовать - нет (лично я не вижу). Если получится - рилтаймеры получат еще один инструмент (ну и жабщики получат еще одну нишу).

> чтобы создать новые проблемы, которых там не было?

А вот это как раз вопрос, который решится со временем. Если достоинства жабки не смогут окупить те проблемы, которые могут при этом возникнуть (и эти проблемы не смогут быть решены) - тады просто технология умрет. В этой нише, я имею в виду.

ты не веришь в силу маркетинга?

что-то мне подсказывает что будут через N лет реалтаймщики давитя, плакать но кодить на жаве.

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

Дык и пишите, как на нормальной. Просто набор библиотек другой, не j2seшный. Ну и про жизненный цикл объектов надо думать другим способом..

> Стандартизация интерфейсов - это ни разу не монополия Java. Этого можно достичь и без нее

Места о стандартизации интерфейсов намного древнее жабы, это точно. Но почему-то мало у кого это получалось. Иначе Шлюмбержеры не стали бы работать над переносом жабки на смарт карты. "Можно достичь" не есть "достигли".

Да, я верю в силу маркетинга! В хорошем смысле. А еще я верю в то, что раскрученная платформа лучше нераскрученной - а чисто технологическое преимущество мало чего стоит, если платформой пользуются два человека.

Если реалтаймовую жабку как следует раскрутят - давиться и плакать придется очень недолго, пока соотв. средства разработки, библиотеки и пр. и пр. не достигнут состояния зрелости. Нынешние разработчики j2se & j2ee совсем не давятся и не плачут. Точнее, делают это не слишком часто, в пределах разумного...

> про жизненный цикл объектов надо думать другим способом..

ИМХО почти полное отсуствие головной боли в выделении/освобождении памяти - главный плюс Java. А тут об этом придется думать.

> Иначе Шлюмбержеры не стали бы работать над переносом жабки на смарт карты.

Маркетинг...

> "Можно достичь" не есть "достигли".

POSIX для realtime - существует и работает. Это не WORAS, правда.

> А тут об этом придется думать.

Насколько я знаю, в смарткартовской жабке вообще рекомендуется все объекты создавать (и память выделять) на этапе инициализации. А потом об этом можно не думать;)

> Маркетинг...

Лошадь позади телеги, мне кажется. Сначала смарткартовскую жабку сделали (С. и Ш.), а потом начали продвигать. Вряд ли Ш. такой дурак, что купился на маркетинг обычной жабки и сломя голову начал делать смарткартовскую - только из-за маркетинга.

>Если реалтаймовую жабку как следует раскрутят - давиться и плакать придется очень недолго,

ага, придется вешаться.

>Нынешние разработчики j2se & j2ee совсем не давятся и не плачут. Точнее, делают это не слишком часто, в пределах разумного...

вот-вот... я так и думал...

>Да, я верю в силу маркетинга! В хорошем смысле. А еще я верю в то, что раскрученная платформа лучше нераскрученной - а чисто технологическое преимущество мало чего стоит, если платформой пользуются два человека.

речь была слегка не о том. правильный маркетинг может победить эволюцию и тогда слова "Но когда технология пытается сунуться туда, где ей делать нечего - ее быстро оттуда выкидывают. Естественный эволюционный процесс." - not true with Travelocity (c) curious gnome ;)

>Нынешние разработчики j2se & j2ee совсем не давятся и не плачут.

а они и не должны - чего там плохо?

> ага, придется вешаться.

Как же обычные-то жабщики не вешаются?

> вот-вот... я так и думал...

А кто не давится и не плачет? Идеальных технологий не бывает;)

>Как же обычные-то жабщики не вешаются?

обычные жабщики не знают слова реалтайм.

>А кто не давится и не плачет? Идеальных технологий не бывает;)

а как же Лисп? правда насчет реалтайма в нем я не знаю.

> правильный маркетинг может победить эволюцию

Нет, правильный маркетинг может СУЩЕСТВЕННО ПОВЛИЯТЬ на эволюцию.

> обычные жабщики не знают слова реалтайм.

Узнают. Делов-то!;)

> а как же Лисп?

А он разве идеальный? Который из них?;)

> вопрос в другом зачем java в обработке RT?

А что в RT прогах отсутствуют проблемы которую призвана решать жаба?

> А что в RT прогах отсутствуют проблемы которую призвана решать жаба?

А какие проблемы призвана решать Java (кроме привлечения к программированию широких масс неквалифицированных рабочих)? o_O

>Этого можно достичь и без нее.

Ключевой саунд этой фразы - потенциальность. См про лисп: http://www.lorquotes.ru/quotes-autor.php?id=190

>что-то мне подсказывает что будут через N лет реалтаймщики давитя, плакать но кодить на жаве.

Только не говори что при этом они будут мечтать о C (и не дай бог с крестами).

>> Этого можно достичь и без нее.

> Ключевой саунд этой фразы - потенциальность.

"POSIX для realtime - существует и работает. Это не WORAS, правда.

tailgunner * (*) (11.04.2007 13:41:07)"

> обычные жабщики не знают слова реалтайм.

"обычные" жабщики и про писание под спецжелезо раньше не знали - например телефоны. А теперь это индустрия. И дальше что? Народ вон на блю-реи хочет менюхи переделать на жабу. Еще одна отрасль появится.

Вы не туда смотрите. Если там не будет жабы - там будет .NET. Без других вариантов.

>А какие проблемы призвана решать Java (кроме привлечения к программированию широких масс неквалифицированных рабочих)? o_O

Избавление квалифицированных рабочих от изобретения велосипедов и предоставления им большой горы стандартизированного кода. Например безопасное исполнение кода.

>А что в RT прогах отсутствуют проблемы которую призвана решать жаба?

а зачем усугублять?

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

М-да... как представлю разбор XML или JDBC/ORM в реальном времени - так просто не знаю, плакать или смеятся.

Скажи, ты по жизни с задачами РВ сталкивался? Назвови, пожалуйста, библиотеки Java, полезные при работе в РВ.

> что-то мне подсказывает что будут через N лет реалтаймщики давитя, плакать но кодить на жаве.

C РТ непосредственно не сталкивался, но за процессом разработки наблюдал - не будет там явы.

> Вы не туда смотрите. Если там не будет жабы - там будет .NET. Без других вариантов.

А почему не PHP ? 8O Почему не питон, удав или ипонские паровозы на рельсах ?

>POSIX для realtime - существует и работает.

ну пусть работает. Тут встает то, что он на C и умеет достаточно мало.

Опять же POSIX - это интерфейс к операционке, изменяется и развивается трудно - сильно много народу надо дружить, которые друг-друга не любят. Сан поступает проще - его стратегия в том, что они не пытаются подружить вендоров операционок - они пытаются выйти на рынок с инструментом, который предоставит все те возможности, о которых вендоры железа и осок договорится не могут. Если инструмент покажется рынку привлектаельным - он его захватит, а остальные, пользуясь старым армейским выражением, "проебали" свой шанс. Игрухи для мобилок тоже можно было и на нативе писать - только рынок этот был в зачаточном состоянии. И рынок выбрал J2ME и .NET Compact, вместо того, чтобы жать пока вендоры родят "MOSIX". И привет. Не расшевелятся стандартизирующие комитеты с развитием POSIX с просто околосяшого стандарта до Modern Industrial Development Platform - и останется POSIX в качестве backend для различного рода виртуальных машин - перейдет в страну ассемблера.

>а зачем усугублять?

А кто сказал что они усугубятся?

>как представлю разбор XML или JDBC/ORM в реальном времени - так просто не знаю, плакать или смеятся.

Представь реализации тредов и синхронизации их средствами языка для платформы, набор стандартных реалтаймовых пулов и т.д.

>Назвови, пожалуйста, библиотеки Java, полезные при работе в РВ.

jvm сама по себе полезна в РВ.

> jvm сама по себе полезна в РВ.

Смишной... в первом ключевое слово Real во втором Virtual

>> POSIX для realtime - существует и работает.

> ну пусть работает. Тут встает то, что он на C и умеет достаточно мало.

o_O

Так ты сталкивался с РВ? У меня такое впечатление, что нет.

> Игрухи для мобилок тоже можно было и на нативе писать - только рынок этот был в зачаточном состоянии. И рынок выбрал J2ME и .NET Compact

Пример - зашибись: игрушки для мобилок - и РВ. Доказательства по аналогии рулят?

> Не расшевелятся стандартизирующие комитеты с развитием POSIX с просто околосяшого стандарта до Modern Industrial Development Platform

Повторю вопрос - какие именно из обширных библиотек Java полезны для приложений РВ?

>> Вы не туда смотрите. Если там не будет жабы - там будет .NET. Без других вариантов.

> А почему не PHP ?

Ты, блин, накаркаешь :D

>C РТ непосредственно не сталкивался, но за процессом разработки наблюдал - не будет там явы.

Будет. Не ява - так что либо подобное. Вон венда уже в кластерные системы вылезла где доминирует линукс.

Поймите простую вещь - всех уже за%#бало трахаться с mallocом. Дело не в сорости кода, а в скорости девелопмента. Многие космические технологии на которые тратили миллиарды долларов военка и государство переходят в бытовуху где таких денег нет, есть меньшие, но больше желающих - в малый бизнес. И они там востребованы. И им нужно чтобы цена и время доставки решения на рынок не была порядка запуска нового шатла на орбиту. И потому убыстряющие и удешевляющи разработку технологии будут рулить. Потому что процессор стоит 5баксов. А программист несколько тысяч в месяц. А время - бесценно.

> Ты, блин, накаркаешь :D

А чё ? Представь PHPшника у чекистов на допросе - почему рванул нефтепровод ? Почему дренаж не сработал ? - Этанияааааа эта апаааааач ?

>А почему не PHP ? 8O Почему не питон, удав или ипонские паровозы на рельсах ?

Потому что это не индустриальные платформы. Я бы к .NET и Java еще причислил Qt в разрезе платформы для Desktop.

> Поймите простую вещь - всех уже за%#бало трахаться с mallocом.

Тех кого зае... е... с mallocom открывают бары и рестораны...

> а в скорости девелопмента.

Друк мой РТ != скорость девеломента. РТ == газ, нефть, атомная энергетика, там ошибка == техногенная катастрофа, там не шустрят и производители железа и софта оооооочень вежливо и тесно общаются...

> И потому убыстряющие и удешевляющи разработку технологии будут рулить.

В кассовых апаратах - да. А вот в более узких направлениях - нет.

> Не ява - так что либо подобное.

Ну да... там _уже_ предлагается нечто не очень похожее на Java.

> Поймите простую вещь - всех уже за%#бало трахаться с mallocом.

Ты по ссылке сходил? "immortal area" видел?

> всех уже за%#бало трахаться с mallocом
Что-то мне подсказывает, что в почти идеально грамотном коде потерять malloc ооочень трудно.
Жаль, такого кощда не бывает.

>РТ == газ, нефть, атомная энергетика, там ошибка == техногенная катастрофа

Эээ, по количеству написанного кода всё же РТ -- преимущественно измерительные приборы, аудио-видео аппаратура, радиосвязь включая сотовую.

>> а в скорости девелопмента.

>Друк мой РТ != скорость девеломента. РТ == газ, нефть, атомная энергетика, там ошибка == техногенная катастрофа, там не шустрят и производители железа и софта оооооочень вежливо и тесно общаются...

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

и жабка по твоему эталон простоты? не смеши мои тапочки, это кривой до невозможности язык, на нём простое автоматически очень длинным
ну а скорость - для ОСРВ она очень важна, опишу типичную задачу стоящую перед ней:
1) есть распилочная линия с огромными пилами
2) не дай бог кто-нибудь засунет туда руку
3) если всё-таки кто-то засунул туда руку, датчик это зафиксировал, то линия должна быть остановлена немедленно, в то же самое мгновение. Но в этот момент работу начал сборщик мусора....

Первым требованием перед ОСРВ стоит - все алгоритмы должны отрабатывать за чётко определённый промежуток времени. Никаких быстрых сортировок и пр. Только алгоритмы с чётко определённым временем работы. А из-за сборщика мусора про жабку точно ничего сказать нельзя, именно поэтому ей и не место на СРВ.

> преимущественно измерительные приборы

А надежность

>> газ, нефть, атомная энергетика

И обеспечивается надежностью контрольно измерительных комплексов.

>Вы не туда смотрите. Если там не будет жабы - там будет .NET. Без других вариантов.

думаешь МС осилит пропихнуть CLR? я сомневаюсь.

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

В упор не понял причем тут скорость и дефектность

> на дефектоустойчивой тулзе собрать надежную систему быстрее,

Да например если говорю (такой нелюбимый вами) malloc - происходит malloc. Если я говорю new String - х#й поймеш сколько там происходит malloc'ов dealloc'ов и realloc'ов. И этого никто гарантированно не скажет так как заипцо какая умная виртуальная машина подсознательно видать чует куда ее сунули в тетрис на мобильнике или в жерло АЭС... ага..

> чем на чем-то невменяемом.

Это С-шник то невменяемый ? Куда уже вменяемее ?

Отличная идея сделать Real Time Java!

Контора где я сейчас работаю собралась выходить на рынок измерительных систем и использование Java позволит убить двух зайцев и продукт быстро выпустить и позиционировать его в нише Real Time :)

> быстро выпустить и позиционировать его в нише Real Time :)

И очень быстро оказаться там откуда не выпускают и где нет-нет позиционируют...

Только я не понял скачать эту Real Time Java где нить можно или платная? Если платная сколько стоит?

А изначально жаба вообще под embedded создавалась:)

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

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

>И очень быстро оказаться там откуда не выпускают и где нет-нет позиционируют...

У нас продукт НЕ для жёсткого real time процесса, а как soft real time будет вполне, imho

>В упор не понял причем тут скорость и дефектность

А ты имеешь в виду что на скорость разработки ПО для жнергетики влияют какие-либо другие причины кроме поиска дефектов? чем меньше дефектов при производстве тем выше скорость производства и быстрее введение в эксплуатацию.

>Это С-шник то невменяемый ? Куда уже вменяемее ?

где тебе голоса из астрала сказали? или твое подсознательное мнение о Сишниках? я про сишников ничего не говорил, я вообще так общетеоретически, далек я от этих сфер на практике.

> У нас продукт НЕ для жёсткого real time процесса, а как soft real time будет вполне, imho

soft real time - деревянная железка ?

песец. вроде седня не первое апреля.

это тормозное гавно для систем реального времени ???

я обоссался прямо на стуле.

> жаба - неудобный язык

Вызывающе неверная.

> вровень с тем же паскалём.

Объективизируем субъективное. Быстро. Недорого.

> утверждения про удобство венгерской нотации,

Откуда в жабке венгерская нотация??? В огороде бузина?

> soft real time - деревянная железка ?

Бывает такая фигня - когда пропуск директивного срока не критичен.

>soft real time - деревянная железка ?

Хм, ты в курсе, что есть деление по времени отклика на жёсткий (АЭС и т.п.) и мягкий real time?

> А ты имеешь в виду что на скорость разработки ПО для жнергетики влияют какие-либо другие причины кроме поиска дефектов?

+поиска _возможных_ дефектов. И именно поиска, а не гадания на кофейной гуще типа откуда тормоза из jvm или кривых ручек разрабов.

> я про сишников ничего не говорил, я вообще так общетеоретически

Ну тут как бы товарищ вверху выдал про надоевшее выделение памяти.

>Игрухи для мобилок тоже можно было и на нативе писать - только рынок этот был в зачаточном состоянии. И рынок выбрал J2ME и .NET Compact, вместо того, чтобы жать пока вендоры родят "MOSIX".

Ты хоть видел эти "игрухи"? Для почти каждой трубы своя версия нужна, иначе не запустится, либо криво идти будет, либо вылетать. Про скорость уже молчу - любая менюшка тормозит. Какие жабе системы реального времени, если даже интерфейс пользователя нарисовать, без заметных глазу тормозов, не может?

>И рынок выбрал J2ME и .NET Compact

Не аргумент, также рынок выбрал и винду. Вообще позиция жабистов предельно ясна: впариваем тупому быдлу всякую хрень, как это делал наш кумир билли.

Ссылка по теме:

http://blogs.sun.com/vmrobot/entry/%D0%BA%D1%80%D0%B0%D1%82%D0%BA%D0%B8%D0%B9...

>Не аргумент, также рынок выбрал и винду. Вообще позиция жабистов предельно ясна: впариваем тупому быдлу всякую хрень, как это делал наш кумир билли.

+2

>Ты хоть видел эти "игрухи"? Для почти каждой трубы своя версия нужна, иначе не запустится, либо криво идти будет, либо вылетать.

+5

>1) есть распилочная линия с огромными пилами 2) не дай бог кто-нибудь засунет туда руку 3) если всё-таки кто-то засунул туда руку, датчик это зафиксировал, то линия должна быть остановлена немедленно, в то же самое мгновение. Но в этот момент работу начал сборщик мусора....

Не удачный какой-то пример. Лучше вспомним Томми...

>+поиска _возможных_ дефектов. И именно поиска, а не гадания на кофейной гуще типа откуда тормоза из jvm или кривых ручек разрабов.

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

Пусть сначала онанимусы узнает что есть real-time, и что к скорости работы отношения это не имеет. Главное - гарантия, что система ответит за определённое время. В том же QNX, который весь из себя real-time, тормозит графический интерфейс.

> что есть деление по времени отклика

В курсе вот только кажется не по времени а только по кол-ву пропущенных циклов планировщика... Что в принципе делает всю эту затею обыкновенной событийной моделью разработки (), но позволяет лепить гордый лэйбл "RT"

нпрод!!! все работаем в ОСРВ !!!

Вообще то оне реалтайм на усолвиях которые нвозможно выполнить. А графический интерфейс вообще сбоку и к реалтайм отношения не имеет.

Вообще то он(QNX) реалтайм на усолвиях которые нвозможно выполнить. А графический интерфейс вообще сбоку и к реалтайм отношения не имеет.

>Пусть сначала онанимусы узнает что есть real-time, и что к скорости работы отношения это не имеет.

Знаем.

>Главное - гарантия, что система ответит за определённое время.

Нет. Главное достичь адекватной реакции Всей системы на событие за заданное время.

>Главное - гарантия, что система ответит за определённое время.

Жаба ответит: "думаю", а самолёт, пока оно думает, сорвётся в штопор.

>Жаба ответит: "думаю", а самолёт, пока оно думает, сорвётся в штопор.

а там еще должен быть автопилот на Си - жаба отвечает думаю - тут же врубается запасной этот автопилот и рулит пока жаба думает.

Тихо и шепотом - в жаве, не смотря на отсутствие malloc и его аналогов есть утечки памяти!

>Тихо и шепотом - в жаве, не смотря на отсутствие malloc и его аналогов есть утечки памяти!

Тихо и шёпотом - виртуальная машина Java от Bea умеет разрешать циклические ссылки и удалять не используемые объекты.

>Вообще позиция жабистов предельно ясна: впариваем тупому быдлу всякую хрень, как это делал наш кумир билли.

+4

> >Тихо и шепотом - в жаве, не смотря на отсутствие malloc и его аналогов есть утечки памяти!

>Тихо и шёпотом - виртуальная машина Java от Bea умеет разрешать >циклические ссылки и удалять не используемые объекты.

Шопотом. Не только от Bea, но и от Sun. Только в oldgen. Но если какие-то кретины хранят в static поле в коллекции кучу ссылок на объекты, то им уже ничего не поможет. Реальные пацаны в этом случае хотябы WeakReference или SoftReference используют :)

>>Тихо и шепотом - в жаве, не смотря на отсутствие malloc и его аналогов есть утечки памяти!

>Тихо и шёпотом - виртуальная машина Java от Bea умеет разрешать циклические ссылки и удалять не используемые объекты.

Сколько звеньев в циклических ссылках, которые она разруливает может быть? Как часто это делается? Можно ли контролировать моменты когда это деалется?

>> что-то мне подсказывает что будут через N лет реалтаймщики давитя, плакать но кодить на жаве.

>C РТ непосредственно не сталкивался, но за процессом разработки наблюдал - не будет там явы.

я писал и пишу для RT на С.

от жабы не отказался бы, честно-честно.

> я писал и пишу для RT на С.

> от жабы не отказался бы, честно-честно.

Причем именно от такой, которая по ссылке?

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

>> я писал и пишу для RT на С. от жабы не отказался бы, честно-честно.

>Причем именно от такой, которая по ссылке?

по ссылкам я на ЛОРе не хожу, традиция, понимаешь.

Но, скажу по секрету, жаба уже давно если не в RT то в embedded. Правда дороговата пока. Но такие киты как WindRiver, например, ее предлагают уже н помню сколько лет.

Кстати, господа, malloc'и в RT - моветон, так что не ломайте копья. И ссылку на javolution.org вообще-то полезно поглядеть, хоть мы и на ЛОРе ;-)

> по ссылкам я на ЛОРе не хожу

Жаль

> Кстати, господа, malloc'и в RT - моветон

Не придирайся к словам. malloc или самописанный pool_alloc - неизбежны.

>malloc или самописанный pool_alloc - неизбежны. Существует много случаев, когда можно 1 раз при старте память откусить ( с запасом ), а потом забыть, что существует куча :)

>> malloc или самописанный pool_alloc - неизбежны.

> Существует много случаев, когда можно 1 раз при старте память откусить ( с запасом ), а потом забыть, что существует куча :)

ОК, пусть "неизбежны в сложных приложениях".

Во, с этого места можно поподробнее:

1. Почему не отказались бы?

2. От какой именно жабы? Той, которая по ссылке - или той, которая обычная j2se-шного разлива?

РТ система - это простая система. Жаба таковой не является.

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

>>> malloc или самописанный pool_alloc - неизбежны.

>> Существует много случаев, когда можно 1 раз при старте память откусить ( с запасом ), а потом забыть, что существует куча :)

>ОК, пусть "неизбежны в сложных приложениях".

Шо есть, то есть. Только не стоит забывать, что в РТ програмист должен занть к чему приведет каждый вызов менеджера кучи, а в жаве с этой стороны полная неопределенность :(.

Нет, я не против gc, но помоему в РТ, он будет больше мешать, чем помогать.

> Нет, я не против gc, но помоему в РТ, он будет больше мешать, чем помогать.

Народ, приучайтесь ходить по ссылкам :) Там написано, как они собираются решать проблему - и эти способы решения делают из Java что-то другое. И лично мне из статьи осталось непонятно, как realtime часть приложения будет взаимодействовать с не-realtime частью в рамках одной JVM. А если они должны быть разнесены по разным JVM - зачем тогда огород городить? Сделать критичное на Си/Си++, а остальное - на чем угодно в другом процессе.

Сходил. ВМ там помоему одна. А вот в управление памятью до конца не вьехал. malloca не видать, про недостатки gc расказывают, но получается, что его же и юзают. :~

>>> malloc или самописанный pool_alloc - неизбежны.

>> Существует много случаев, когда можно 1 раз при старте память откусить ( с запасом ), а потом забыть, что существует куча :)

>ОК, пусть "неизбежны в сложных приложениях".

да неправда это, OSEK-like OS + специализированные сетевые стеки + управление NVRAM + таймеры + специализированноe run-time environment + ...

и ни одного malloc, XXXalloc и т.п. одна статика (но с жуткой динамикой на этапе конфигурации системы, никаким __alloc'ам не снилось)

проектировать надо уметь ;-)

>Во, с этого места можно поподробнее:

>1. Почему не отказались бы?

навскидку

A) недостижимая для С абстракция от платформы (железо, компилятор, модели памяти). в С полностью абстрагироваться можно только препроцессором, а это отвратительная гадость...

Б) очень хорошие возможности для моделирования - практически любой модуль можно тестировать отдельно

B) переносимость, пусть не идеальная, но гораздо лучше чем в С.

можно еще чего вспомнить, лень просто

>2. От какой именно жабы? Той, которая по ссылке - или той, которая обычная j2se-шного разлива?

j2se исключается конечно, по ссылкам некогда ходить, звиняйте.

сборка мусора честно говоря не очень-то и нужна, javolution хороший пример (но не единственный)

>>ОК, пусть "неизбежны в сложных приложениях".

>да неправда это, OSEK-like OS

С OSEK не знаком. А вообще не надо доводить до маразма - всегда можно захватить всех ресурсов по максимуму, и не пользоваться malloc. Но вот ресурсов на это может не хватить.

> A) недостижимая для С абстракция от платформы (железо, компилятор, модели памяти). в С полностью абстрагироваться можно только препроцессором, а это отвратительная гадость...

Согласен. Доп. вопрос: использование более осмысленных препроцессоров не помогает? Стандартный препроцессор действительно туп до невозможности.

>С OSEK не знаком. А вообще не надо доводить до маразма - всегда можно захватить всех ресурсов по максимуму, и не пользоваться malloc. Но вот ресурсов на это может не хватить.

на самом деле в embedded система всегда конфигурируется до runtime, там и ресурсы распределяются как надо, это конечно сложная штука, но жутко интересная, в OS общего назначения не встречается, поэтому мало кому известна

> всегда конфигурируется до runtime

Как я понял, на этом и играет java на смарт картах - объявляется, что gc не является узким местом, потому что "garbage" как такового нет by design. Если, конечно, design правильный;)

> Согласен. Доп. вопрос: использование более осмысленных препроцессоров не помогает? Стандартный препроцессор действительно туп до невозможности.

да, частично эту проблему можно решить доп-средствами, и на самом деле так и делается, но это не панацея к сожалению. Универсальных доп-средств нет, кроме ANSI-С препроцессора со всеми последствиями.

> на самом деле в embedded система всегда конфигурируется до runtime

embedded-системы бывают сильно разные.

> в OS общего назначения не встречается, поэтому мало кому известна

очень даже встречается

>> на самом деле в embedded система всегда конфигурируется до runtime

>embedded-системы бывают сильно разные.

я согласен, сейчас и linux в embedded прет со страшной силой, но я имел в виду нормальные технические решения, а демпинг на бесплатности не очень интересен, потому как перспективы у него сомнительнейшие (тут кстати j2se даже больше надежд вызывает)

> я имел в виду нормальные технические решения

Во всех системах для RT/embedded, которые я знаю, есть malloc. Использование malloc является признаком "ненормального" технического решения?

> демпинг на бесплатности

o_O

>Во всех системах для RT/embedded, которые я знаю, есть malloc. Использование malloc является признаком "ненормального" технического решения?

Oh, Yes! Windriver прямо не советует использовать кучу для RT, хотя malloc в VxWorks изначально.

>> демпинг на бесплатности

>o_O

ага, коммерчески linux умопомрачительно выгоден, но как только пойдет жесткая конкуренция и большие тиражи он не справится с footprint'ом

впрочем для industrial (если его не путать с embedded) уже похоже нет альтернативы linux, QNX на этом похоже и загнется.

> Windriver прямо не советует использовать кучу для RT, хотя malloc в VxWorks изначально.

в критических участках - наверное. а вообще, пулы с фиксированными накладными расходами на malloc строить.

> linux умопомрачительно выгоден, но как только пойдет жесткая конкуренция и большие тиражи он не справится с footprint'ом

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

> для industrial (если его не путать с embedded)

я бы сказал, что они частично перекрываются :)

> QNX на этом похоже и загнется.

Охх... Жаль будет. Все-таки технически это очень интересная система.

а чем она интересна?

Много ли микроядерных систем справились стать коммерческим явлением? winnt & macosх просьба не беспокоиться - первая перестала быть мироядерной еще в нт4, вторая и не была никогда - там bsd было запихано в ядро с самого начала.

>> QNX на этом похоже и загнется.

> Охх... Жаль будет. Все-таки технически это очень интересная система.

только в узкой области - в ядре, в плане полноценного решения (обвязки, протоколы, средства разработки, спектр поддержки платформ) она всегда была достаточно убога и отставала от Windriver и GHS, на чем и погорела, хороший промышленный UNIX и только.

> вопрос в другом зачем java в обработке RT?

Чтобы Томми больше не убивался.

Там денег просют вроде. Здесь (http://www.research.ibm.com/people/d/dfb/papers/Bacon03Realtime.pdf) - свободно.

> A) недостижимая для С абстракция от платформы

Эээээ а зачем абстрагироваться при разработке embedded ?

> очень хорошие возможности для моделирования - практически любой модуль можно тестировать отдельно

Ну с моделированием ясно... когда надо "хочу прям щас"

> переносимость, пусть не идеальная, но гораздо лучше чем в С.

Опять же РТ и embedded тут никаким боком...

PS: Хотя конечно если некеому R&D не захотелось позагорать лишь под конец проекта находя в себе силы рожать одноглазых буратин в косметике...

> и ни одного malloc, XXXalloc и т.п. одна статика (но с жуткой динамикой на этапе конфигурации системы, никаким __alloc'ам не снилось)

А) Про динамическую масштабируемость можно забыть

Б) От интеграции заранее отбиваться руками и ногами (ну не поймет клиент зачем ему вразрезы таких фиговин лепить отдельные сервера в качестве лоадбалансеров)

>> A) недостижимая для С абстракция от платформы

>Эээээ а зачем абстрагироваться при разработке embedded ?

очень просто - в embedded железо имеет свойство сменяться со страшной скоростью, а если железо не меняется меняются компиляторы, а если компиляторы не меняются меняются модели памяти, свичи, и т.д. и т.п.

вот у меня пример был когда один и тот же модуль надо одновременно на 16-ти платформах тянуть. бр-р-р. А один компилятор хочет чтобы ему "far int *a;" писали, а другой чтобы обязательно "int * far a;" и др. веселые картинки. Ну про линкеры на ночь глядя не буду ничего писать...

>А) Про динамическую масштабируемость можно забыть

не совсем так, если нужна динамика, то она с лихвой покрывается дискретным набором конфигураций

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

про сервера не понял, но интеграция делается на ура. клиенту кроме target софта поставляется среда конфигурирования, проектирования, опимизирования конфигураций и т.п. и реально возможно стыковать модули разных производителей.

> и т.д. и т.п.

Хммм... прям настолько быстро ? (кроме шуток, в пределах одного брэнда железо меняется достаточно редко).

> А один компилятор хочет чтобы ему

#ifdef + хороший RCS

Хотя каждому свой терем ближе...

> то она с лихвой покрывается дискретным набором конфигураций

А стоимость ?

> про сервера не понял

Имелось ввиду ситуации когда железка становится "узким местом". Cкорости растут быстрее чем развивается оборудование и железки масштабирующиеся путем количественного наращивания очень быстро вытесняются. Учитывая, что большинство целевой аудитории таких комплексов помешано на резервировании.

>Хммм... прям настолько быстро ? (кроме шуток, в пределах одного брэнда железо меняется достаточно редко).

по разному бывает, иногда контора производит и продает только софт

>> А один компилятор хочет чтобы ему

>#ifdef + хороший RCS

ну да, но только таких мелочей много набегает, и С код лишается даже убогого контроля ANSI-компилятора

>> то она с лихвой покрывается дискретным набором конфигураций

>А стоимость ?

а их клиент под себя генерирует, так что затраты его. впрочем и они небольшие, если генерирующие среды хорошо сделаны.

Ява в обработке RT (или, как в моем случае, квази-RT) нужна ровно по тем же причинам, что и везде -- для переносимости и для удобства. Удобства для программиста и для пользователя: одна система, один гуй, одни и те же кнопки и никаких левых библиотек не надо тащить за собой каждый раз -- только JRE надо для работы.


в нашем случае реально мы своей разработкой заменили монстра (написанного на це/це++, кстати), работающего (не ползающего) на двухядерном серваке, с 2 гигами памяти, с базой данных и прочей enterprise-мутью на маленькую прогу (ну сравнительно маленькую: 300K собственных классов - это не так уж и мало) на яве. так вот наше полностью кроет этого монстра по функциональности и работает при этом даже на ноуте 5-ти летней давности (p3-128Mb ram). Повторяюсь - работает оно, даже на таком Г. Собирает данные с десятка сейсмических станций в квази-реалтайм (каждая станция льет данные по UDP серваку с некоторыми интервалами), раздает эти данные клиентам на обработку и никаких проблем мы не имеем.


А монстр на це/це++ даже жить на таком железе отказывается, не то что работу делать. :)

>Ява в обработке RT (или, как в моем случае, квази-RT) нужна ровно по тем же причинам, что и везде -- для переносимости и для удобства...

Какую Java использовали, J2SE или Real Time Java?

> Ява в обработке RT (или, как в моем случае, квази-RT) нужна ровно по тем же причинам, что и везде

То есть у тебя была не RT-задача - ну и тогда к чему ты это?

> так вот наше полностью кроет этого монстра по функциональности и работает при этом даже на ноуте 5-ти летней давности (p3-128Mb ram).

Конечно, бывают фантастически плохо написанные программы на Си++, но почему-то я тебе не верю... или ты не всё рассказал.

сразу на оба вопроса ответ.

использовалась Java 5.0 SE

задача таки RT. просто счет идет не на миллисекунды отклика, но данные пропускать таки нельзя, иначе не хватит пропускной способности сети на лишние перепосылки (там 1/10 Mbit по WiFi в плохих условиях приема), да и буфер у сейсмостанций небольшой..

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

подробностей не будет, из-за комм. тайны (они еще и партнеры) и анти-рекламы делать нельзя. Но факт остается фактом - на яве можно делать промышленные пакеты. можно делать лучше, чем на це++. причем не хуже и за более короткий срок, нежели срок устранения единичной ошибки в старом >1M строк це++ проекте.

не хотел ввязываться в эти дебаты, да пришлось. не хочу терпеть, когда быдлокодером называют. це++ я тоже умею, когда надо.

А какая либа использовалась для взаимодействия Java и WiFi?

> задача таки RT. просто счет идет не на миллисекунды отклика

Если время реакции - порядка секунд, то всё равно, на чем писать :)

> бывают не просто плохо написанные це++ программы. бывают монстры, разрабатывающиеся на протяжении 20 лет

> можно делать лучше, чем на це++.

ИМХО, пример, мягко говоря, нетипичный - переписывание корявого монстра возрастом 20 лет в условиях РВ с очень мягкими директивными сроками.

> факт остается фактом - на яве можно делать промышленные пакеты.

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

Как Java с WiFi связали???

> Как Java с WiFi связали???

Средствами ОС, наверное :)

В стандартной Java нет средств работы с com портами, WiFi и т.д. нужно скачивать нативную библиотеку. Вот я и спрашиваю, какую заюзали стороннюю нативную библиотеку?

>Тихо и шёпотом - виртуальная машина Java от Bea умеет разрешать циклические ссылки и удалять не используемые объекты.

Еще тише и так же шопотом - только вот платформ эта машина поддерживает совсем немного :(

Про com порты есть javacomm. Про wifi - да, нет ничего в стандарте. Но судя по описанию задачи, там нет ничего wifi-специфичного, обычные сетевые средства жабки должны быть достаточны. Либо java.net, либо java.nio.

по порядку.

1) wifi карточки у нас в варианте outdoor (иначе нельзя в наших условиях) -- то есть они умеют работать "за бортом" при -20C, подключены непосредтвенно к сейсмостанциям (у котрых свой Ethernet). все они умеют работать в режиме моста ("точка-точка" как с куста). это отдельные девайсы, работающие в нашем случае как некий "хаб". для работы с девайсом пользуются java.net и java.nio. я принципиально уже против нативных библиотек через JNI -- они медленнее, чем родные (проверено неоднократно) и проблем, как понимаете, с нативными библиотеками больше.

2) время реакции таки не секунды. а порядка 50-100 миллисекунд. протрахать момент ну никак нельзя - для этого кольцевые буфера на данные каждой станции и многопоточная обработка данных с этих кольцевых буферов (ну очевидно, что цикл приема-передачи данных должен быть один, ибо UDP, а вот обрабатывать данные надо где-то "сбоку". вне этого цикла).

3) пример более, чем типичный. по крайней мере для меня и моего коллеги, который обсчитывает 3d-сейсмику и отрисовывает ее на Java3D. уже года 3 как прочно сидим на этой платформе и делаем заказы для "нефтянки". программку на це++, написанную на борландятине и токма под винды (а я наотрез отказался портировать ее под kylix) с использованием opengl - выкинули начисто. заменили софтиной на Java3D. и она даже лучше получилась.

4) для "жесткого" реалтайма не годится не только платформа Java. для этого не годится платформа PC в принципе. слишком плохая. даже полудохлый qnx - и тот никуда негоден, из-за платформы. хотя, если прочитать определение RT в комментируемой статье, то у меня все программки подходят -- уж никак не больше 100ms я трачу на обработку "нажатия клавиши мышки", ибо все в отдельный тред передается ВСЕГДА и цикл обработки событий AWT свободен "почти сразу" для дальнейшей работы. ;)

5) еще тише шепотом - сановские gc тоже умеют циклические ссылки удалять с "кучи". если bea вас убеждает в обратном - при случае "плюнте в рожу".

p.s. для связи: 0--@mail.ru

> время реакции таки не секунды. а порядка 50-100 миллисекунд. протрахать момент ну никак нельзя

50-100мс? Вроде в Java 1.5 сборщик мусора класса @stop-the-world", не особо верю, что на нем можно добится 50мс. ИМХО, вас спасает буферизация в ядре :)

> для "жесткого" реалтайма не годится не только платформа Java. для этого не годится платформа PC в принципе

Насчет PC - слишком сильное утверждение, ИМХО. От многих вещей зависит.

> для работы с девайсом пользуются java.net и java.nio. я принципиально уже против нативных библиотек через JNI -- они медленнее, чем родные (проверено неоднократно) и проблем, как понимаете, с нативными библиотеками больше.

Вы мудры.

> обсчитывает 3d-сейсмику и отрисовывает ее на Java3D

Если не очень сложно и нет проблем с NDA и пр. - запостите скриншот? Посмотреть как оно выглядит охота.

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

1) там их 3 штуки, этих gc :) в конечном счете нас спасают кольцевые буфера в static хранилище.

2) Вот именно, что от "многих вещей зависит".

на 0--@mail.ru черкни письмецо.

отмылю и свои и коллеги скрины.

вообще, с java3d я первый тут у нас в конторе начал играться, а он потом продолжил (а я на реалтайм прием/обработку переключился). шагнул он гораздо дальше %)

> там их 3 штуки, этих gc :)

Но все с паузами... хотя для 100мс "Concurrent Low Pause Collector" выглядит вполне подходящим.

> и надо отвечать всяким кликушам, гонящим на тормозную да быдлокодерскую жабку

Ну и ? UDP коллектор и что ? Кури в сторону syslog - ооот тем же самым занимается. JRE не требует. C сетью работает напрямую с ОС нативнее только паяльник.

ЗЫ: Пример абсолютно ничего не меняет.

> Кури в сторону syslog. JRE не требует

При чем тут сислог? Кто и где сказал, что прямой код можно делать ТОЛЬКО на жабе?

> Пример абсолютно ничего не меняет

Действительно он ничего не _меняет_ - потому что оно так было и до примера, и будет после него: в прямых руках жабка работает так, как надо. А пример это просто _показывает_.

Ок, черкну. Хотя показательнее (если политика конторы дозволяет) было бы выложить это в галерею скриншотов.

> в прямых руках

В прямых руках и ... балалайка

> А пример это просто _показывает_.

Необъективно - вот нафаршированная явой солярка вот это пример так сказать от "отцов"... наталкивающий на совершенно противопложные мысли о качестве явы....

> При чем тут сислог?

При том, что выполняет те же задачи и уже мноооооого лет.

> вот нафаршированная явой солярка

Честно скажу - не пробовал, сказать ничего не могу.

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

> При том, что выполняет те же задачи и уже мноооооого лет.

А где можно скачать 3Д визуализатор для сислога?;)

Еще раз - никто не говорит, что ТОЛЬКО на жабке можно делать хорошие вещи. Никто не говорит, что на жабке нельзя делать плохие вещи. Исходное утверждение в этом минитреде - на жабке можно делать хорошие вещи.

>> При том, что выполняет те же задачи и уже мноооооого лет.

>А где можно скачать 3Д визуализатор для сислога?;)

>Еще раз - никто не говорит, что ТОЛЬКО на жабке можно делать хорошие вещи. Никто не говорит, что на жабке нельзя делать плохие вещи. Исходное утверждение в этом минитреде - на жабке можно делать хорошие вещи.

Я так понимаю, что имелось ввиду, что задача решена неверно и то, что задача элементарна. То есть жаба там только лишний расход ресурсов и денег на разработку программы которая не нужна. 3d визуализатор - да можно нарисовать и на жабе. Вопрос только выгодно ли это или выгоднее применить другое решение? Учитывая фактор, что переносимость не нужна.

> А где можно скачать 3Д визуализатор для сислога?;)

уууу cофта для визуализации хушь попой ешь... кажись gnuplot 3D умеет (2D точно), библиотек визуализации примитивов куча, а если вообще не лохматить бабушку - небольшой конвертер и скрамливать данные в povray будет вообще все с любой стороны хоть с прозрачностями хоть с текстурами .

По ходу сейчас глянул - точно gnuplot умеет 3D причем достаточно качественно http://t16web.lanl.gov/Kawano/gnuplot/plotpm3d-e.html

povray не нужен.

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

А где у gnuplot антиалайзинг бикубический?

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

Ага. Лучше было наклепать на коленке решение из полудюжины компонент (сислог, поврей, gnuplot, кто там еще?) и молиться на единственного гуру, способного поддерживать это в рабочем состоянии. И тогда сразу вспоминаем, что разработка - это небольшая часть стоимости проекта, а вот поддержка и развитие - довольно дороги, если компонентов в решении много.

Не говоря о том, что есть сомнения в том, что формат данных с "железки" прям так изначально годился на скармливание сислогу.

> А где у gnuplot антиалайзинг бикубический?

А хай бери povray да ?

> бери точи под себя,

Вот-вот. Вместо нормально продуманной расширяемой архитектуры - куча доработанных напильником компонент. unix way, великий и ужасный.

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

>Ага. Лучше было наклепать на коленке решение из полудюжины компонент (сислог, поврей, gnuplot, кто там еще?) и молиться на единственного гуру, способного поддерживать это в рабочем состоянии. И тогда сразу вспоминаем, что разработка - это небольшая часть стоимости проекта, а вот поддержка и развитие - довольно дороги, если компонентов в решении много.

>Не говоря о том, что есть сомнения в том, что формат данных с "железки" прям так изначально годился на скармливание сислогу.

Вообще то имелось ввиду что там поддерживать почти нечего ибо просто нечего:)

>> бери точи под себя,

>Вот-вот. Вместо нормально продуманной расширяемой архитектуры - куча доработанных напильником компонент. unix way, великий и ужасный.

А где это решение становится не расширяемым? покажи.

Стебаешься?

> Вообще то имелось ввиду что там поддерживать почти нечего ибо просто нечего:)

А скрипты и файлы конфигурации, обеспечивающие связку всего этого воедино - будут поддерживать себя сами? И самомодифицироваться при апгрейде железа, обновлениях и пр. и пр.?

>> Вообще то имелось ввиду что там поддерживать почти нечего ибо просто нечего:)

>А скрипты и файлы конфигурации, обеспечивающие связку всего этого воедино - будут поддерживать себя сами? И самомодифицироваться при апгрейде железа, обновлениях и пр. и пр.?

Точно стебаешься, блин, а я повелся. :)

> А где это решение становится не расширяемым? покажи.

Как Вы будете обеспечивать расширяемость относительно форматов и способов сбора исходных данных (если завтра Вас попросят брать данные из serial, а послезавтра - из firewire)? Я вообще не понимаю - если исходные данные не годятся для сислога, что Вы собираетесь делать, ваять тысяча первый скрипт для конвертации (который и сожрет весь выигрыш по производительности)? С результирующими форматами тоже хорошо - если Вас попросят автоматически раз месяц готовить красивенький pdf с отчетом, Вы присобачите еще одну тулзовину? Вы понимаете, что результирующий винегрет сможет поддерживать только тот, кто владеет ВСЕМИ вовлеченными микрокомпонентами?

Вы, наверное, очень хотите стать бессмертным сотрудником конторы - чтобы начальство даже представить не могло Вашего ухода и зарплату поставило раз в 5 выше среднерыночной.

Отнюдь.

У unix way есть границы примененимости в реальной жизни.

Ага. Лучше было наклепать на коленке решение из полудюжины компонент (сислог, поврей, gnuplot, кто там еще?) и молиться на единственного гуру, способного поддерживать это в рабочем состоянии.

Нет достаточно просто уметь читать мануалы

> Не говоря о том, что есть сомнения в том, что формат данных с "железки" прям так изначально годился на скармливание сислогу.

А вообще никто не предлагал сидеть и сращивать все это, предлагалось взглянуть на то что существует с мохнатых годов в свете чего и 100ms на пакет + 300k кода - это даже не "неплохо". И на пример производительности ну ниразу ни тянет. Сислог привел в пример только по той простой причине что он как раз является вылизанным по самое немогу UDP коллектором.

> А скрипты и файлы конфигурации, обеспечивающие связку всего этого воедино - будут поддерживать себя сами?

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

> Нет достаточно просто уметь читать мануалы

Ага. Мануалы по полудюжине компонет. И еще гуглить в процессе прохождения по граблям, которые встретятся на пути. Причем у каждой тулзы - свой набор граблей.

> в свете чего и 100ms на пакет + 300k кода - это даже не "неплохо"

Сами по себе эти параметры наверняка далеки от блеска. А вот как параметры целостного _решения_ (а не отдельного узла) - возможно, совсем неплохи. Особенно если брать в расчет TCO.

> Сислог привел в пример только по той простой причине что он как раз является вылизанным по самое немогу UDP коллектором.

Сислог прекрасен, спору нет. И что делать, если нужен свой собственный коллектор? Брать код сислога и курочить? Сразу потеряв всю "вылизанность"?

> У unix way есть границы примененимости в реальной жизни.

А вот это ИМХО соооовсем неверно. Ну и как всегда под флеймик - аргументики можно ?

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

> И что делать, если нужен свой собственный коллектор?

Брать и писать свой коллектор - если это предполагает задача. Да и AFAIK там только чуть-чуть перепахать функцию разбора пакета и если сильно надо прикрутить к ней любую легковесную БД - тот же беркли навскидку.

Целый тред аргументиков. Вкратце:

1. Нужно хорошо владеть ВСЕМИ компонентами, вовлеченными в связку. Что делает поддержку дорогой. Поддержка и развитие однородных решений может оказаться дешевле. Что, разумеется, не перечеркивает идею модульности - но все-таки более tightly coupled, чем в случае множества независимых тулзовин.

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

Шикарно. Начинаем кодить на С. Что сразу взвинчивает цену отладки (не говоря уж про потери в периносимости и пр. и пр.). В принципе, можно действительно добиться впечатляющих результатов в производительности - вопрос лишь в цене.

> тот компонент (или интерфейс, т.е. несколько компонет), где оно случилось, потом понять, как оно работает - и как его чинить.

Чего в жабе впринципе невозможно. Точнее можно узнать где все свалилось, но установить где потери производительности - ХЗ.

> 1. Нужно хорошо владеть ВСЕМИ компонентами, вовлеченными в связку.

Ровно в той же степени, что и в Java. В сборке из готовых компонент у Java только одно преимущество - что компонент МНОГО.

>Отнюдь.

>У unix way есть границы примененимости в реальной жизни.

Ууууу... Это сразу в морг. Диагноз - фанат.

> Нужно хорошо владеть ВСЕМИ компонентами, вовлеченными в связку.

Это только при единоличной поддержке. Что в примере от сейсмолога вообще смысла не имеет, производитель не удовлетворил - выкрутились сами.

> Поддержка и развитие однородных решений может оказаться дешевле.

Ниразу монолитные решения чаще всего страдают при масштабировании и резервировании.

> Многочисленные интерфейсы при неаккуратном применении могут сожрать все преимущества по производительности, которые давают отдельные компоненты.

Ну тут мы уйдем в рекурсивный флейм простота vs профессионализм.

> Точнее можно узнать где все свалилось, но установить где потери производительности - ХЗ.

В этом случае жабка ничем не отличается от unix way - unit testing уже давно считается обязательным. Так что насчет "невозможности" - это перебор.

> Диагноз - фанат.

Замечательно. Считать, что unix way способен решать ВСЕ проблемы - это НЕ фанатство. А считать, что у каждого подхода есть границы применимости - это фанатство. И где тут логика?

> Ниразу монолитные решения чаще всего страдают при масштабировании и резервировании.

Кто сказал "монолитные"? Модульные, безусловно! Но не настолько loosely coupled & heterogeneous, как принято в классическом unix way.

> Ну тут мы уйдем в рекурсивный флейм простота vs профессионализм.

Настоящий профессионал всегда помнит про принцип KISS. Так что никакого "vs" ;)

> Шикарно. Начинаем кодить на С.

А почему нет ? Подготовка кодера на C и Java по скорости и времени - одинакова. Тут уже вопрос подхода обучаемого кадра.

> Что сразу взвинчивает цену отладки

Так жабодевелоперы же дороже ? (это был подкол, просто многие утверждают о некоторой разнице в ЗП в пользу java).

> (не говоря уж про потери в периносимости и пр. и пр.).

Да действительно! Под большинство аппаратных платформ идет API на С, а jvm есть не под все... А если еще вспомнить что jvm и набор классов ею поддерживаемых весьма разный и платформозависимый - увы те же грабли.

> Так жабодевелоперы же дороже ? (это был подкол, просто многие утверждают о некоторой разнице в ЗП в пользу java).

Ну, я точно не среди этих некоторых. Хороший сишник действительно дорог (хотя и жабщик недешев). А вот время отладки кода на С (за счет того, что память приходится менеджить ручками) - точно больше. Сильно больше. Соотв. дороже.

Соббсно я не против С. Я его глубоко уважаю. Но ИМХО в коммерческом проекте надо ОЧЕНЬ сильно подумать, прежде чем начать что-то делать на С. И если есть возможность НЕ делать это на С - надо сделать на чем-то более высокоуровневом.

> Под большинство аппаратных платформ идет API на С

Ага. По одному API на платформу;) И на каждой платформе свой компилятор, свое кол-во и порядок байтов в слове и пр. интересные вещи, над которыми так увлекательно поработать вечерами и в выходные...

> а jvm есть не под все...

Зато уж если есть - там есть все обещанные API. И никакого разнобоя. А кол-во платформ, где нет jvm - непрерывно уменьшается...

> Замечательно. Считать, что unix way способен решать ВСЕ проблемы - это НЕ фанатство. А считать, что у каждого подхода есть границы применимости - это фанатство. И где тут логика?

Так ЛОР же ... тут если в одном треде ктото когото не назвал фанатом,быдлокодером,пионером,виндузятником - тему можно считать неудавшейся.

Вечно я забываю, где нахожусь! Склероз;)

> Хороший сишник действительно дорог (хотя и жабщик недешев).

Да в принципе как и любой другой хороший представитель любой профессии.

> Соббсно я не против С

Да и я как бы не против явы как RAD-средства. В том же самом технологическом моделировании где скорость и ресурсы лишь вопрос денег очень даже ничего.

> Но ИМХО в коммерческом проекте надо ОЧЕНЬ сильно подумать, прежде чем начать что-то делать на С.

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

>>> Вообще то имелось ввиду что там поддерживать почти нечего ибо просто нечего:)

>>А скрипты и файлы конфигурации, обеспечивающие связку всего этого воедино - будут поддерживать себя сами? И самомодифицироваться при апгрейде железа, обновлениях и пр. и пр.?

>Точно стебаешься, блин, а я повелся. :)

Вот на это ты овтетил что ты не стебаешься.

Извини, но поддерживать срипты или яву. Разницы никакой. Мои слова что ты фанат исходили из того что ты видищь эту разницу, а не из того что ты видишь ограничения идеологии юникс.

> Извини, но поддерживать срипты или яву. Разницы никакой.

Да, я вижу. Потому что предлагаемое решение на скриптах (как оно предлагалось) - было винегретом из серии "с миру по нитке". Тогда как разработчики на жабке как правило сначала строют нормальную продуманную архитектуру. Если разницы между ad hoc scripting и архитектурой Вы не видите - считайте меня фанатом.

>Так ты сталкивался с РВ? У меня такое впечатление, что нет.

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

>Пример - зашибись: игрушки для мобилок - и РВ. Доказательства по аналогии рулят?

Типа того. А что тебе не нравится? И там и там критичные девайсы. Скажи 10 лет назад что жаба будет в мобильных телефонах - ржали бы не меньше "океаны памяти", "виртуальная машина", "жуткий тормоз" и т.д. А сейчас она даже в пластиковых картах. Почему ей не быть в реалтайм? Объективные причины назвать можешь?

>Повторю вопрос - какие именно из обширных библиотек Java полезны для приложений РВ?

Какие из страшно обширных поделок жава были полезхны для мобил пока не было ME? RT это же не просто ярлык это характеристика софта. Ты какой сейчас софт конкретно имеешь ввиду?

>и жабка по твоему эталон простоты?

Жабка по моему Industrial Platform.

>Но в этот момент работу начал сборщик мусора....

Еще детские приколы будут?

>все алгоритмы должны отрабатывать за чётко определённый промежуток времени.

Система должна иметь _гарантированное время отклика_. http://en.wikipedia.org/wiki/Realtime

>А из-за сборщика мусора про жабку точно ничего сказать нельзя,

А время требуемое для деструкции дерева объектов в C++ ты назвать можешь? А методу подсчета не подскажешь? Шутник.

> ещё раз отвечу, что жаба - неудобный язык, вровень с тем же паскалём. эти крики, про сборщик мусора, отсутствие маллоков, просто смешны

Смейся смейся. Уже викинул свою карту visa? А то ведь там весьма вероятно тоже жаба.

>> Так ты сталкивался с РВ? У меня такое впечатление, что нет.

> А это что - отменяет убогость посикса в плоскости, которую я упомянул?

Назвать POSIX "убогим" в области РВ может только человек некомпетентный.

>>Пример - зашибись: игрушки для мобилок - и РВ. Доказательства по аналогии рулят?

>Типа того. А что тебе не нравится?

Мне не нравятся доказательства по аналогии.

> И там и там критичные девайсы.

Мобильник - это не совсем "критичный" девайс. Ладно, а какие программы для мобильников написаны на Java, кроме игр? То, что в мобилах требует РВ, пишется отнюдь не на Java.

> Скажи 10 лет назад что жаба будет в мобильных телефонах - ржали бы не меньше

Если ты забыл - изначально Java разрабатывался и позиционировался как язык разработки для встраиваемых устройств.

>>Повторю вопрос - какие именно из обширных библиотек Java полезны для приложений РВ?

>Какие из страшно обширных поделок жава были полезхны для мобил пока не было ME?

Отвечать вопросом на вопрос - это хорошая тактика. Я не стану так делать и отвечу нормально - обширные библиотеки Java бесполезны для ME. Применение Java в мобилах - это отчасти для удешевления разработки, а отчасти для обеспечения переносимости (но последнее всё равно не достигнуто).

>а без этих особенностей Java - не Java, а что-то другое. После чего встает вопрос - а нужно ли?

Что другое? Некоторая модификация? JavaCard тоже нечто другое. И что - от этого она проигрывает plain C? Или вам куда не запихивай - должна быть javaSE со всем рантаймом "иначе нессчитается"? Вон в дотнете наже "standard edition" нечто другое в каждой версии.

> А то ведь там весьма вероятно тоже жаба.

Там проц нативно поддерживающий жаба-байткод с таким же успехом ее можно назвать perl-карточкой если пое###цо хорошенько и написать компилятор с перловки в байт-код.

> JavaCard тоже нечто другое.

JavaCard - это, ИМХО, и не Java вовсе.

> И что - от этого она проигрывает plain C?

Свои задачи выполняет - и ладно. Но там РВ не нужно, так что аналогия не прокатывает.

> Или вам куда не запихивай - должна быть javaSE со всем рантаймом "иначе нессчитается"?

Ты прочитал памятку "10 эффективных способов вести дискуссию"? Не надо приписывать мне придуманных тобой слов.

> Жабка по моему Industrial Platform.

Это по твоему - industrial так не думает. Увы я тебя разочарую но если бы не засовывание Санками жабы во все и вся - не знал бы ее никто...

> JavaCard - это, ИМХО, и не Java вовсе.

Ниразу не java. Там API c жаба синтаксисом кастрированный чуть-ли не до ассемблерных инструкций.

>Назвать POSIX "убогим" в области РВ может только человек некомпетентный.

Раскажи некомпетентному человеку про платформы POSIX.1b compliant и возможность достижения на них realtime. NT ядро совместимо? Windows Vista - realtime платформа?

>Ладно, а какие программы для мобильников написаны на Java, кроме игр? То, что в мобилах требует РВ, пишется отнюдь не на Java.

Всякая вигня пользовательская. В стером SiemensM55 был даже midi редактор.

Я не имею ввиду сейчас критичность с токски зрения RT, а по той же памяти и процессору. Вон тут народ любит плакать что у них жабские проги на PC с гигагерцами и гигабайтами тормозят, и в то же время на телефонах где не гигабайтов не гигагерцов - работает. Парадокс?

>Я не стану так делать и отвечу нормально - обширные библиотеки Java бесполезны для ME

А вот стандартизированная платформа стандарт которой постоянно расширяется - еще как полезна.

>Применение Java в мобилах - это отчасти для удешевления разработки, а отчасти для обеспечения переносимости

Совершенно бесполезные фичи для RT. Особенно удешевление разработки.

>Там проц нативно поддерживающий жаба-байткод с таким же успехом ее можно назвать perl-карточкой если пое###цо хорошенько и написать компилятор с перловки в байт-код.

А ты что - язык имеешь ввиду? RT проблемы не в языке же, а в VM. В смысле языка - хоть на Bigloo Scheme.

>JavaCard - это, ИМХО, и не Java вовсе.

Зависит от того что ты считаешь ключевыми свойствами.

>Не надо приписывать мне придуманных тобой слов.

Я не приписываю - ты сказал: JavaCard - это, ИМХО, и не Java вовсе.

Назови тогда что считается джавой.

>Увы я тебя разочарую но если бы не засовывание Санками жабы во все и вся - не знал бы ее никто...

Это я тебя разочарую:) Индастриал думает именно так.

> RT проблемы не в языке же, а в VM

Вот поэтому и нечего жабе делать в RT.

> Это я тебя разочарую:) Индастриал думает именно так.

Например ?

> Зависит от того что ты считаешь ключевыми свойствами.

Не увиливай. Ключевыми свойствами жабы является объектно-ориентированная парадигма с эвристическими (по словам дяди Гослинга) моделями работы с памятью не поддающимися контролю со стороны разработчика.

> Раскажи некомпетентному человеку про платформы POSIX.1b compliant и возможность достижения на них realtime.

Ты уже и сам нашел стандарт. Что еще тебя интересует?

> NT ядро совместимо? Windows Vista - realtime платформа?

Мне, веришь ли, без разницы. А ты, наверное, и сам знаешь ответ.

> Вон тут народ любит плакать что у них жабские проги на PC с гигагерцами и гигабайтами тормозят, и в то же время на телефонах где не гигабайтов не гигагерцов - работает.

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

>>Применение Java в мобилах - это отчасти для удешевления разработки, а отчасти для обеспечения переносимости

> Совершенно бесполезные фичи для RT. Особенно удешевление разработки.

Я не сказал, что они бесполезны. Но 1) переносимость не достигнута 2) оправдает ли урезанная Java накладные расходы и так ли уж удобно (== быстро) будет под нее разрабатывать - неизвестно. Берешься предсказать? С обоснованием.

> Назови тогда что считается джавой.

Что, я прямо всю Java Language Specification привести должен?

>> Извини, но поддерживать срипты или яву. Разницы никакой.

>Да, я вижу. Потому что предлагаемое решение на скриптах (как оно предлагалось) - было винегретом из серии "с миру по нитке". Тогда как разработчики на жабке как правило сначала строют нормальную продуманную архитектуру. Если разницы между ad hoc scripting и архитектурой Вы не видите - считайте меня фанатом.

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

> Забавно, значит разбиение на различные модули и библиотеки по функциональности - это винигрет?

Разницу между top-to-bottom проектированием и bottom-to-top понимаете? Жабский метод - первый. Бессистемное скриптование готовых компонент - второй.

> Разницу между top-to-bottom проектированием и bottom-to-top понимаете? Жабский метод - первый. Бессистемное скриптование готовых компонент - второй.

Может быть и ровно наоборот - зависит от того, известны ли условия задачи полностью до начала проектирования, или выясняются по ходу.

Согласен. В условиях, когда слишком много неизвестно с самого начала - жабку применять опасно. Конечно, можно дать запас по гибкости - но слишком велик риск промахнуться. Жабка может хорошо работать, когда большая часть ТЗ более-менее определена.

>> Забавно, значит разбиение на различные модули и библиотеки по функциональности - это винигрет?

> Разницу между top-to-bottom проектированием и bottom-to-top понимаете? Жабский метод - первый. Бессистемное скриптование готовых компонент - второй.

Ага, презабавненько!

Занчит, если скриптование - то бессистемное. И обязательно уже готовых компонентов. Типа брать за образец готовые и делать аналог для своих нужд или просто делать маленькую утилиту под конкретную задачу - табу запрещает. И обязательно все обвязывать нечитабельными скриптами, которые никто поддерживать не сможет.

А вот если жаба - то все обязательно строго, архитектурно правильно и обложено со всех сторон юнит-тестами, которые, оказывается, кроме того что ошибки отлавливают еще и производительность мерят. И совсем роли не играет, что это не производительность на таргете, а не производительность на хосте. Типа жаба везде одинакова и разницы платформ - не в счет. А те отличия которые есть - их как бы нет. Вот нет и все! И везде поддерживается полная спецификация жабы. А там где она не поддерживается она не поддерживается настолько незначительно, что считай поддерживается. И десятков различных вариантов одной жабо-программы для разных типов мобильников не существует. И то что вы видите на сайте их разработчиков - это или ваши глюки или глюки разработчиков.

Умиляет меня все это.

> Занчит, если скриптование - то бессистемное

А как вы собираетесь вводить систему в скриптование столь различных компонент как сислог и поврей?

> И обязательно уже готовых компонентов.

Идея про сислог, поврей и гнуплот - не моя. Обсуждается именно она.

> просто делать маленькую утилиту под конкретную задачу - табу запрещает.

А потом еще одну маленькую. И еще одну. И потом спрашивать про бессистемность.

> А вот если жаба - то все обязательно строго, архитектурно правильно

Обсуждалась именно правильная жаба. Кому ж интересно обсуждать неправильную? Что на жабе можно накосячить - это уже обговаривалось выше.

> И везде поддерживается полная спецификация жабы.

В данном случае обсуждался проект на j2se, которая поддерживается полностью - или просто не является j2se (несертифицированные поделки в виде gcj & kaffe не рассматриваются). Не надо сводить тему к j2me, которая разделяется по профилям - это совсем другая область.

> Умиляет меня все это.

Рад за Вас

> Согласен. В условиях, когда слишком много неизвестно с самого начала - жабку применять опасно. Конечно, можно дать запас по гибкости - но слишком велик риск промахнуться. Жабка может хорошо работать, когда большая часть ТЗ более-менее определена.

Что я слышу, да как вы посмели усомниться в жабе, оставив ей ниши: 1) переписывания уже готовых программ 2) написание программ для себя по своему собственному ТЗ 3) наколенных поделий пишущихся за пол часа

От вас ли мы это слышим или вас подменили?

"Фигассе басенку сократили" (с). Высосать из моих слов того, чего там не было...

>> просто делать маленькую утилиту под конкретную задачу - табу запрещает.

> А потом еще одну маленькую. И еще одну. И потом спрашивать про бессистемность.

Точно - табу. Именно табу запрещает СДДЕЛАТЬ ПРОЕКТ из утилит разбитых по функциональности, а ПОТОМ или подобрать уже готовые и скорректировать проект для них, или написать свои.

>> И везде поддерживается полная спецификация жабы.

> В данном случае обсуждался проект на j2se, которая поддерживается полностью - или просто не является j2se (несертифицированные поделки в виде gcj & kaffe не рассматриваются). Не надо сводить тему к j2me, которая разделяется по профилям - это совсем другая область.

То есть как только речь перестает вестись о силе явы и начинается про переносимость мы аккуратно сужаем круг рассматриваемых вещей.

Гениально!

> "Фигассе басенку сократили" (с). Высосать из моих слов того, чего там не было...

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

PS: Что то у меня сразу настроение упало.

> А как вы собираетесь вводить систему в скриптование столь различных компонент как сислог и поврей?

Вообще-то там и gnuplot был предложен, который как бы и предназначен для визуализации потоковых данных. Но просто чуть позже чудику антиалиазинга захотелось.... А так и это уже есть:

http://gdea.informatik.uni-koeln.de/archive/00000480/

И уж чем-чем а над 3D визуализацией в реальном времени репу чесала не одна лаборатория и не один год. И пытаться изобрести велосипед... глупо.

Не удержусь и сам себя прокомментирую:

>> Согласен. В условиях, когда слишком много неизвестно с самого начала - жабку применять опасно. Конечно, можно дать запас по гибкости - но слишком велик риск промахнуться. Жабка может хорошо работать, когда большая часть ТЗ более-менее определена.

> Что я слышу, да как вы посмели усомниться в жабе, оставив ей ниши: 1) переписывания уже готовых программ 2) написание программ для себя по своему собственному ТЗ 3) наколенных поделий пишущихся за пол часа

> От вас ли мы это слышим или вас подменили?

Только что заметил, что приведенный выше пример полностью попадал в ниши 1 и 2 и частично в нишу 3.

В этом что-то есть... Ж)

> Покажите мне заказчика который на начальных этапах разработки скажет что он действительно хочет и не сменит потом свое хотение.

Читайте собеседника внимательно, когда спорите. Я не сказал "все". Я сказал "большая часть". Обычно на это заказчика хватает. И при правильном планировании последующие капризы заказчика, как правило, укладываются в изначальный дизайн. Да, всему есть предел.

ЗЫ Если уж совсем плохо пришлось - в жабке всегда есть рефакторинг. И вообще самые смелые XP применяют. Но это совсем другая история.

> Именно табу запрещает СДДЕЛАТЬ ПРОЕКТ из утилит разбитых по функциональности, а ПОТОМ или подобрать уже готовые и скорректировать проект для них, или написать свои.

То, о чем Вы говорите - ни разу не совпадает с изначально предложенным. Никакого "ПОТОМ подобрать" там не было. Потрудитесь оставаться в рамках обсуждаемого изначально.

> То есть как только речь перестает вестись о силе явы и начинается про переносимость

Речь не про жабку, а про банальную манеру вести дискуссию. Если изначально речь шла про проект j2se, давайте говорить про j2se. Не уходите от темы.

ЗЫ Переносимости между j2se и j2me, как и внутри разных профилей j2me никто не обещал. Но это НЕ ОТНОСИТСЯ к теме обсуждения.

> Речь не про жабку, а про банальную манеру вести дискуссию. Если изначально речь шла про проект j2se, давайте говорить про j2se. Не уходите от темы.

Какая может быть дискусиия с фанатом не признающим факты и их игнорирующим?

Мнение фанатов можно учитывать только в областях не касающихся их фанатизма. Если говорить о вас, том с вами можно обсуждать все кроме жабы. Вот например с Луговским лучше было не обсуждать языки и типы программирования. С санычем лучше не обсуждать санки. Со мной... со мной лучше не обсуждать хохлушек. :)

Что прикажете делать с фактами, не относящимися к обсуждаемому? Только игнорировать.

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

>Например ?

Например посмотри на рынок заказных систем.

>Ключевыми свойствами жабы является объектно-ориентированная парадигма с эвристическими (по словам дяди Гослинга) моделями работы с памятью не поддающимися контролю со стороны разработчика.

Бред.

>Мне, веришь ли, без разницы. А ты, наверное, и сам знаешь ответ.

Который подтверждает мое утверждение о том что как стандарт POSIX - беден. Потому что даже те кто типа его реализуют - не реалтайм. Венда например убивается поцарапанным диском в сидюке. Реализация для галочки.

>"Тормозят" - это понятие относительное.

И я о том же. Как и фактический показатель гарантированного времени отклика. Подумай еще о такой мелочи, предположим реалтайм упирается в сборку мусора. 10 лет назад жаба была? Была. Процессоры какие были? 100MHz, теперь процессоры какие? правильно 4Ghz, то есть с тех пор сборка мусора в гигагерцах стала в 40 раз быстрее. Следовательно в таких примитивных характеристиках достич реалтайма можно. Если не будет успевать - процессоры разгоним. Или 2 поставим для ConcurrentGC.

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

Ну и что? И где они эти нативные приложения? Скорость работы - не ключевой фактор. Как я уже говорил если бы этим все определялось - так офисную машину еще 10 лет назад придумали - ей тоже не гигагерцы не гигабайты не нужны. Все летало на 386.

> Но 1) переносимость не достигнута

Достигнута. Все кто делает бизнес на жабских играх по баксу с тобой не согласятся.

>Берешься предсказать? С обоснованием.

Да я уже 20 раз это показывал на примере близкой области - разработка под спецдевайсы - телефоны. И частоты не те и памяти мало и архитектура другая - а вот подиж ты - работает. JavaCard вообще апофигей.

>Что, я прямо всю Java Language Specification привести должен?

То есть ты тоже считаешь джавой _язык_?

> Например посмотри на рынок заказных систем.

Чуть-чуть конкретизируй, а то и нотепад написанный на зазказ заказная система.

> Ну и что? И где они эти нативные приложения?

Тебе невдомек почему вообще существуют такия понятия как смартфон и коммуникатор ? А то тоже дооолго пели песню про киллер фъюче жабомобайл ?

> разработка под спецдевайсы - телефоны. И частоты не те и памяти мало и архитектура другая - а вот подиж ты - работает

Ога! Пока никто не звонит.... Не принимая во внимание что процы хоть и не те, но во времена 100mhz дома не у каждого такие стояли...

>>Мне, веришь ли, без разницы. А ты, наверное, и сам знаешь ответ.

>Который подтверждает мое утверждение о том что как стандарт POSIX - беден.

Я не поспеваю за твоей логикой. Попробую изложить ее помедленнее: реализация POSIX в Винде убогая => весь POSIX убог? Кстати, что-то я не припомню, чтобы в винде когда-нибудь был реализован POSIX.1b

>> "Тормозят" - это понятие относительное.

> Как и фактический показатель гарантированного времени отклика.

Гарантированное время отклика - это цифра. Что в ней может быть "относительного" - я не понимаю. Объяснишь?

> Процессоры какие были? 100MHz, теперь процессоры какие? правильно 4Ghz, тех пор сборка мусора в гигагерцах стала в 40 раз быстрее. Следовательно в таких примитивных характеристиках достич реалтайма можно.

Логика потрясает :(. "Процессоры быстрее, следовательно, мы можем достичь РВ".

> Если не будет успевать - процессоры разгоним.

Для справки тебе - я НИГДЕ в РВ не видел процессоров по 4ГГц. Честно говоря, я вообще о таких процессорах не слышал. Довольно типичный пример платформы для РВ - 400МГц PowerPC, 32M памяти на борту, минимальный размер кэша.

>> Но 1) переносимость не достигнута

> Достигнута.

Ну тогда она и на Си достигнута.

>> Берешься предсказать? С обоснованием.

> Да я уже 20 раз это показывал на примере близкой области - разработка под спецдевайсы - телефоны.

Еще одно доказательство по аналогии.

> JavaCard вообще апофигей.

Это единственное твое утверждение, которое очевидно верно :D

>То есть ты тоже считаешь джавой _язык_?

В рамках данного разговора - да. Для протокола: я знаю, что под Java понимают и платформу, точнее, целый набор платформ.

> Для справки тебе - я НИГДЕ в РВ не видел процессоров по 4ГГц.

Ты не вкуриваешь хай-левел-индустриал-солюшн от жабистов. Это когда тебе впаривают быстро состряпанную кривую/косую поделку быстрее чем у конкурентов и дешевле чем у конкурентов, но с небольшой поправочкой - тебе для нее понадобится двухголовая нетра которую они тебе продадут с посредническими скидками...