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

В стандартной 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-средства. В том же самом технологическом моделировании где скорость и ресурсы лишь вопрос денег очень даже ничего.

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

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

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

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

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

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

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