Javolution - Java технология для real-time и safety-critical missions систем

Мне кажется ПО на Java будет содержать меньше ошибок, чем на С++. Что касается скорости, то по вреени переключения между задачами оно процентов на 30 хуже чем на Си.

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

Чегобы и Яве не крутиться? Не вижу технических проблем. Они просто повторяют путь промавтоматики, только в более технологичном варианте (промконтроллеры программируются убогими языками).

+5

>Взять в качестве примера промышленную автоматику. На всех промышленных 
>контроллерах (начиная от крутых западенских брендов и заканчивая 
>китайскими мыльницами) крутиться, как правило, виртуальная машина и ни 
>чего, работает.
>Чегобы и Яве не крутиться? Не вижу технических проблем. Они просто 
>повторяют путь промавтоматики, только в более технологичном варианте 
>(промконтроллеры программируются убогими языками)

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

Я не знаю где вы видели PLC контроллеры, которые выполняют роль коммуникатора и где алгоритмы для автоматики пишутся на С. Для меня это борльшая новость из области фантастики.

Вся промавтоматика как правило, строиться на PLC сонтроллерах, которые поддерживают стандарт языков IEC 61131-6. Стандарт опписывает несколько языков, один из них ST (Structured Text, допотопный аналог pascal), он же в Step7 называется SCL. Ни каких языков и близко похожих на Си стандарт IEC 61131-6 не описывает.

Для каждого PLC контроллера есть своя среда разработки, котоая поддерживает стандарт IEC 61131-6, например Step7 siemens simatic, CoDeSyS, ISaGRAF и другие. Именно в этих средах разратываются АЛГОРИТМЫ управления автоматикой. После разработки алгоритма происходит компиляция, получается некий аланог аппаратно независимого bytecode Java, вот именно он и грузиться в PLC контроллер. Соответсвенно, на PLC контроллере крутиться виртуальная машина, аналог Java VM, которая исполняет загружаемый bytecode. На Си алгоритмы как правило, не пишут. На Си написаны виртуальные машины, нижний уровень обработки прерываний, работа с железом, но ни как алгоритм управления автоматикой.

>Но как правило эти промконтроллеры сами по себе выполняют роль >коммуникатора - мастера промышленной сети,

Вы описываете великий изврат, все PLC контроллеры стандарта IEC 61131-6 редко испорльзуется только как коммуникаторы, основная из задача - сбор информации/управление. Функция коммуникатора вполне реальная, но не главная задача.

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

Конечно можно и так делать, но как правило PLC контроллер, он на то и PLC, потому как программируется языками стандарта IEC 61131-6 (ST и прочие поделия).

То что вы описываете - черезвычайная редкость. Где вы видели это чудо?

Что то я не наблюдал шлюзов IP телефонии на Java Cisco,Samsung,Vega и т.п. разбирались - linux(даже не RT) + C. Опять спрошу прямо: чем Java здесь лучше будет, тем что нужно будет больше памяти дать для её не освобождения? Если цель использовать Java то молодцы - справились, а если цель сделать вещь, то жуйте её сами. Я понимаю, что мечта любого манагера сделать чтобы оно само работало, но пока нет ИИ, будут нужны нормальные вменяемые разработчики, и соответственно будет область применения и Java, но там, где ей место вместе со всеми её плюсами и GC-ами. Любую программу можно сделать оптимальной по эффективности, если писать на асемблере целевой машины, но не любую если писать на языке высокого уровня (пока нет ИИ). Просто блоки крупнее. Как ещё вам нужно разжевать? Чем выше абстракция, тем больше потери эффективности. Помните про коней в вакууме? Ну как вы не крутитесь блоки у Java крупнее. Возможно эта модная система хорошо укладывается в бизнес процессы манагеров, но это не панацея.

Кроме того, насколько мне изестно из теории надёжности чем больше элементов системы, тем она менее надёжная - в случае Java мы имеем ядро + ядро Java. Лично я больше доверяю ядру Linux, чем процессу Java - это про надёжность. Не думаю что синергетический эффект повышения надёжности, сходный с надёжностью мозга, возникнет от симбиоза этих двух факически ядер. То что в Cisco стоит ихняя ОС я в курсе - не нужно мне указывать(заранее).

про надёжность - в программировании есть правило: разделяй и властвуй. Ядро не решает всех проблем.

В некоторых моделях Cisco стоит qnx

>Чем выше абстракция, тем больше потери эффективности.

Не всегда. Пример: надо вычислить 2 + 2. На чём эффективнее? Понятно что на ассемблере. Языки высокого уровня были придуманы для решения более сложных задач., которые на ассемблере решать и отлаживать сложнее.

Каждому языку своя задача.

Опять по древу растекаетесь? Нам втирают что Java это всё, а я и ещё несколько таких же говрят что крайности это зло и маркетоидная провокация. + Тенденция к отуплению.

Когда я говорил про эффектиность имелось ввиду чисто теория информации. Если говорить практически, то и на асемблере можно 2+2 сложить так, что любой современный компилятор фору даст. Ну там криво выровнять, дать не ту размерность и тд. Я говорил про саму теоретическую возможность оптимизации и её теоретически достижимые пределы. На практике очень редко можно совместить эфективность ПО и маркетологические приколы. Поэтому собственно Linux и эффективнее чем NT, MINIX со всеми их микроядрами. Политики меньше.

Во первых, java это не всё - для неё свой класс задач, это надо понимать не взирая не весь маркетинг.

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

В третьих, эффективность ядра Линукса под вопросом:

-API драйверов

- производительность мне кажется падает.

В четвёртых политики не меньше, а больше:

http://www.linux.org.ru/view-message.jsp?msgid=2163291

Я рекомендую вам ознакомиться с творчеством фирмы IBM в плане разработки ядра, а именно к чему привела внедрение флагов MS_BIND и на его осонове MS_PRIVATE, MS_SLAVE, MS_SHARED. MS_BIND ещё ладно, освоил, работает... С остальными просто атас, не смотря на наличие документации, освоить и понять этот вклад IBM мне ума не хватает. Зачем испоганили код ядра мне не понятно.