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

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

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

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

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

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

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

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

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

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

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

o_O

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

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

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

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

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

>идиотизм, скорость жабы на однотипных операциях раз в 20 ниже чем у нормального кода, плюс непонятно сколько времени будет уходить сборщику мусора. это точно не для ОСРВ

Я тебе больше скажу. Если сравнить мой старый пень 166 то там KDE выгледело не сильно хуже чем текущее не считая рюх и берила. Если не считать игровую индустрию - берем офисную машину - что там такого появилось за последние 10 лет для чего требуются гигагерцы и гигабайты? Что в офисе (если взять венду) не обеспечивает 98 венда и MSO97? А Delphi2 был мегаинструментом для баз данных. И все это работало на железе, которое тормознее самых поганых мобилок сейчас.

Ты понял что _скорость выполнения инструкций_ - не самое главное?

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

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

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

RT-linux и терабайты ОЗУ (в свете предыдущей новости) как раз и понадобились для компенсации наличия жабки?

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

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

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

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

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

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

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

> идиотизм, скорость жабы на однотипных операциях раз в 20 ниже чем у нормального кода, плюс непонятно сколько времени будет уходить сборщику мусора. это точно не для ОСРВ

Э-э-э... месье в курсе, какой сейчас год? Месье слышал о слове JIT? Какой версией жабы месье пользовался в последний раз?

> Поймите простую вещь - всех уже за%#бало трахаться с 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) если всё-таки кто-то засунул туда руку, датчик это зафиксировал, то линия должна быть остановлена немедленно, в то же самое мгновение. Но в этот момент работу начал сборщик мусора....

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

Да что вы все так завелись.

Я, так думаю, стебаются они (svu, r и др).

Разводят вас.

А вы разводитесь. :)

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

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

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

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

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

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

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

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

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

Знаем.

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

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

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

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

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

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

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

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

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

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

+4

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

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

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