>> Что же Java классы, зависмые от изменяемого, не требуют обязательной перекомпиляции?
> а) JIT пересоберется (ABI change), так что суть та же
> б) было fx(a, b), стало fx(a, b, c), причём c обязательное (API
> change). Не будете ничего менять?

Э... это уже как бы считается кардинальным изменением API, так как изменяется сигнатура вызова. Все клиенты должны отвалится, по идее, если их код не поправить в соответствии с новым API. Либо изначально закладываться на особенности языка описания вызовов по использованию функций (методов) с переменным числом параметров.

>> Почему так сложно обеспечить обратную совместимость кода на C/C++ с существующим сторонним софтом, версии которого не изменились, его нужно снова перекомпилировать из тех же исходников?
> Потому что получится WinAPI/ABI.

Не понял.

>> Эти моменты легко предсазать и даже управлять этим — как правило, затребованный
>> код сразу же проходит JIT и кэшируется в памяти (вот почему Java приложения требовательны к большому объёму памяти).
> Вот почему J2EE реально юзают только в тяжеленных приложениях под махровый ынтерпрайз, где не лень отдать 100500 нефти за десяток серверов, лишь бы оно хоть как-то работало. Ибо искать/делать решения попроще западло.

Решения, которые попроще, не обладают масштабируемостью, требуемое время на создание таких решений и отладку неизмеримо больше.

>>> А при API changes также потребует и правки софта.
>> Какой? Если API только расширяется, то зависимые неизменившиесы классы (объекты) всё равно не увидят новые методы.
> Какие классы? Забудьте об этом, OO-подход в портабельных системах опять же используется не везде (читать - почти нигде).

Да я понял давно, что объекты в C++ никакие не объекты вовсе, а так — фальшивая ООП-обёртка для сознания программиста с псевдо-RTTI и статическим связыванием кода на этапе компиляции.