prospero78 писал(а):
Я правильно понимаю: взяли инструмент с исходно кривыми ручками, неудобными рабочими частями, и теперь страдая и потея пытаются исправить инструмент под давно назревшие задачи?))
В данном случае "кривость" не так уж однозначно интерпретируется. С маркетинговой точки зрения выбор Java понятен, и такие вещи, как
PTC Perc Java,
JamaicaVM и др. разработчики профиля "живут себе припеваючи", судя хотя бы по их "white papers" и док-ам (всё-таки, здесь не HotSpot). Устаканивание API для управления процессами, взаимодействия с оборудованием и т.д. и т.п. -- вроде нормальное явление.
Насчёт управления памятью, здесь затронутое. У каждого вендора сейчас есть свои технологии обеспечить real-time (и прочее для задач). В своих док-ах предлагают использование "регионов" в рамках RTSJ лишь для удовлетворения каких-то потребностей соответствовать предопределенным требованиям (ну или для решения специфичных задач аля спецконтейнеры данных). А вокруг (с постепенным переносом в продакшн) кроме "ручного" API наблюдаются техники как в диссере "Cooperative Memory Management ..." (по ссылке в предшествующем посте) -- статический анализ кода для автоматического определения времени жизни объектов и их взаимоотношений, распределения по иерархическим регионам (включая и стеки функций) и в динамическом хипе (а также в спец-памяти) и т.д. (плюс сопутствующее выявление эффектов типизации с последующим их учётом -- что там может изменяться, иметь или нет null, "coalesce" для переменных и пр.). В той же публикации есть акцент на любопытном моменте. При использовании принципов аллокации как в FijiVM -- выделение блоков относительно небольшими порциями ("arraylet"-ы) по некоторым правилам для снижения проблем фрагментации -- языки аля С/С++ и Паскаль-производные создают больше проблем, чем Java, т.к. они предусматривают "композицию": понимание структур как "value"-сущности и "включение" в себя других объектов (поля-структуры), что в итоге может потребовать какие-то выкрутасы фоновой "нарезки" в runtime с нарушением семантики типизации.
В общем, в данном случае стремление быть на уровне примитивного "бейсика" не выглядит кривым (да и, фактически, java используется прежде всего как байткод в качестве метаданных, т.е. сам текстовый язык Java во второстепенных ролях).
А что там будет в SCJ -- сложно сказать. Вероятно, в конечном счёте, сформируется как подмножество RTSJ (к примеру, как текущее понимание Level 0 и 1, а прочее -- как RTSJ со всей динамикой в памяти).