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

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

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

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

Писец... Слабо самому замену символов написать? Я в шоке.

> Посоветуйте ява-либу для транслитерации русских строк в английские.

Если в кои8 - срежь старший бит.

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

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

Писец. А ты каждый раз садишься писать libc, когда она тебе в очередной раз требуется? Теперь понятно, почему у винды уже XAML и Aero, а линукс все в той же жж, каждый раз садятся вилосипед писать, вместо того, чтобы воспользоваться написанным кем-то

Писец. Теперь понятно почему под вендой кроме свистелок ничего нету, а что есть глючит безбожно. Потому что даже транслитерациб сделать не могут, куда уж там до чего то сложнее.

Свободно, анонимное убожество.

> А ты каждый раз садишься писать libc,

Сравнил жопу с пальцем

Быдлушко, аналогов XAML у нас были десятки ещё лет за двадцать до венды. У вендовозов же и 20 лет не прошло как они переизобрели баянистый layout manager, и теперь ссутся в тапки от радости.