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

кто такой "ялро"? судя по тому что "л" и "д" рядом - таки ядро?

Ждём дебилов.

http://sourceforge.net/projects/jos/

и это не первый и не последний.

зачем их преодолевать? может просто не заходить в них? люблю жабу, но RT перебор: давайте создадим себе проблему и возьмемся ее дружно решать разнвми методами: Deterministic garbage collection, Native code compilation for RT, загрузчик классов, управление потоками.

:)))

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

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

Однако оно не полностью на яве:

http://jos.cvs.sourceforge.net/jos/old-JJOS/common/nativecode/

С другой стороны, и ядро Линукс не полностью на си.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Попивая? Выпивая? Напевая?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

wieker, ты пользуешься браузером, написанным на java? Тебе рассказать, как перейти на что-то, к чему прикручивается спеллчекер?

ЗЫ thanks fixed.

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

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

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

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

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

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

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

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

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

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

Вам льдинку или клубничку сверху? :)

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

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

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

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

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

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

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