>[оверквотинг удален]
> Если спецификации не являются стандартом, да еще и права на них принадлежат....
> , то мы получаем, то, что творится вокруг Java последнее время...
> Вот это и есть настоящий vendor lockin, причем, проявившийся во всей
> красе. И платное оно там, или бесплатное роли никакой не играет.
> В случае vendor lockin применительно к языку, даже если в реализации
> будет 100%-соответствие спецификациям (ни в плюс ни в минус ни на
> миллиметр), то это ничего не значит - нет высочайшего благословения вендора
> - есть проблемы и всем плевать на какое-то там соответствие (всегда
> же можно сказать, что ваша реализация "не следует духу языка" или
> вообще патентом помахать).Читаю wiki что есть vendor lock, чтобы не спорить о разных терминах. Ага "lock in" - "зависимость потребителя от продуктов и сервисов одного поставщика, невозможность сменить поставщика из‑за высоких затрат на переход".
так вот неполная поддержка стандарта - это пол беды, но вот "Конкретная реализация компилятора (или СУБД в случае с SQL) должна в какой-то мере этим спецификациям следовать, причем ... и наличие дополнительных (далеко не всегда совместимых) расширений". так вот не совместимые расширения и есть lock in. Иначе придется признать что IE не делал lock in на себя, а всего лишь доработал HTML своими дополнительными (далеко не всегда совместимыми) расширениями.
То же самое с СУБД если в компании стоит MS SQL, то на Oracle его менять не будут. Просто потому что дорого и дешевле научится готовить MS SQL. И наоборот. Потому СУБД-хи это яркий пример vendor lock.
Значит на С стандарты слабее, чем на java. если VM не полностью поддерживает спецификацию java, то она не станет JDK пока не реализует полную поддержку. Кстати все спеки на java и другие JCR (аналог RFC для java) общедоступны. по сути java это практически полностью заспецифицированная платформа. Дело то в другом...
