Вирт в свои языки принципиально не вводит шаблоны, считая их не нужным усложнением. Если это так, то это просто глупо. Отказ от повторного использования! Приведение типов спасает(ло) Яву, но вообще-то, если вдуматься, это жуткий ужасный кошмар. Ява туда принципиально не подходит, хотя-бы из-за сборки мусора.
Ну-ну-ну. 8-)))
Есть и "Real-time Java" проект. Для ЖЁСТКОГО, КРИТИЧНОГО. А уж для некритичного сам Бог велел.

Смотрел я на описание "Real-time Java". Пулы памяти, которая не управляется сборзиком муссора, да еще проверка runtime на обращение реалтаймовой нити к нереалтаймовым данным.
Не жизнеспособная штука.
Здесь интереснее подход языка Cyclone - у него проверка пула статическая. Наверно его не очень сложно допилить до поддержки real-time не теряя возможности собирать мусор в вспомогательных нитях. Но это уж больно экзотический проект.

Не жизнеспособная штука.
8-)
Категорично Вы штатовцев разделали!

Честно говоря, я не спец по системам реального времени, но три общих соображения:
1. Никто не запрещает программе на Яве сначала выделить все структуры данных и потом прекратить динамическое распределение.

Например, в нашем проекте меговые XMLи для каждого пользователя веб-приложения (а их может быть миллион) надо превращать в объекты. Народ тыкнулся -- SAX sucks (миллион строк создаётся), написали свой парсер по "голому" массиву букв. Запрос 50 мс, разбор 80 мс. Лепота!

2. Если задача требует динамического распределения памяти, то какая разница между Java аллокатором и C++ аллокатором. Всё равно объекты надо освобождать, а для C++ аллокаторов надо доказать устойчивость алгоритма по времени. Но и для Явки в таком случае можно написать свой хороший аллокатор (есть API для подключения).

3. Современные Явы уже с 1.4 позволяют контролировать время задержки на сбор. То есть для Явы тоже можно доказать устойчивость по времени. А тем более что один из режимов сбора мусора сейчас не останавливает "вселенную" (параллельное выполнение).

8-)

Вот Вы называете Яву "нежизнеспособной" из-за задержки при сборке мусора (проблемы начальных версий).

А вот я давно не глядел на новости С/С++, не подскажете, были ли решены такие проблемы:
1. Результат каждого выделения памяти может быть NULL, и это надо каждый раз проверять?
2. Если такую ссылку не проверить, то обращение к ней приводит к завершению программы? Или обычный способ -- try/catch ловит эту ситуацию?
3. Повторное освобождение памяти по освобождённой ссылке приводит к зацикливанию аллокатора или к разрушению арены?
4. Сочетание стековых буферов с отсутствием проверки выхода за граница массива даёт возможность перейти в произвольное место программы -- всё ещё не решено?

Если нет, то по-моему, С/С++ просто безумно опасный и ошибочный язык.

Да, конечно. Я же говорил что C++ годится только для пофессионалов очень высокого класса. А таковых мало. К сожалению есть еще одна особенность плюсов - когда на них начинает писать дилетант, ему начинает казаться что он становится профессионалом.
Интересная альтернатива в этом плане - Cyclone.

Кстати, проверку границ массива в C++ можно организовать статически (с помощью шаблонов) в большенстве случаев. Но программировать с помощью того, что получилось будет очень тяжело :-).

Спасибо за новости о Java. Я мало интересуюсь как RT, так и Java, так что отстал от жизни :-).

По ANSI C++ невыделение затребованной памяти должно приводить к окончанию работы программы. Обычно это не реализуется.