Вышла новая версия JNode 0.2.6

>>где тесты?

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

Это замер некорректный. Надо брать либку от браузера и ее запускать в запускалке.

А что если браузер после каждого кадра svg переlayout (как это по русски? пересчитвыает? ) или даже просто перерисовывает всю хтмл странцу, как например под флешой с прозрачностью? Что мы будем тогда мерить?

Хотя и такой пример уже было бы что-то

wfrr, сделай плиз хотя бы как ты сказал... вообще даже на svg интересно посмотреть со счетчиком кадров, а потом можно уже и допилить

> Но если нового много (jnode, minix3, MenuetOS/Colibri, Inferno, ... ) то развивать надо наиболее перспекивное -- а для этого надо обсуждать и то, как там будут сделаны драйвера nVidia с OpenGL.

>Кстати, в миникс я думаю их не такая проблема перенести как в яву.

nVidia-не nVidia, кажется у ATI больше шансов в связи с открытием спеков. Есть вроде бы Scitech драйвера, есть EGL и Gallium3d, есть на худой конец TinyGL и т.п. Причём SciTech драйвера работают под несколькими ОС. Если и изобретать новые драйвера, они должны быть сделаны как-то похоже: из унифицированной кодовой базы делать несколько аналогичных драйверов под разные ОС, не изобретать велосипед несколько раз заново под каждую ОС.

> Аппаратный MMU был создан под нужды нынешних ОС.

Встречный вопрос, какая архитектура MMU лучше подходит для управляемых ОС, байткода, и т.п.? Мне в голову приходит что-то вроде теговой памяти, указателей с тегами, кеша этих тегов. И безопасно выдавая теги в указателях на ресурсы-объекты можно безопасно управлять выделением ресурсов, реализовать этакое экзоядро.

>Можно ведь и Java bytecode аппаратно поддерживать.

Кажется, Java bytecode специально был сделан так, чтобы ни один реальный процессор его нормально не поддерживал. Стековый байткод, система команд байткода, которые не ложатся естественным образом на систему команд реального процессора.

Сравните, например, байткод в Dis из Inferno (трёхадресный), байткод в llvm или "виртуальный ассемблер" -- VP-code в Elate/Tao OS (там вообще из ассемблера сделали ОО аналог С, с синтаксисом ассемблера. "Байткод" родился из макроассемблеров реальных CPU, поэтому байткод VP отображается в реальный CPU 1:1. Аналогичный подход и в llvm, только более теоретизировано.)

> И даже 1 может, во-первых, не дать ощутимого выигрыша, и во-вторых, для этого не нужен байт-код (более того, байт-код для этого неудобен).

llvm прекрасно оптимизирует такой байт-код. Сам подход llvm показывает (подтверждённый публикациями в ps на тему оптимизаций), что байт-код как раз таки удобен для такой оптимизации :))

> Байт-код - слишком низкоуровневое представление программы, в котором нет многой важной информации для оптимизации.

например? а если байткод, как в llvm специально сделан, чтобы эту информацию сохранять? ( хотя AST туда вряд ли засунут Ж))

>> 2) Для компиляции чего-нибудь из исходников не нужны заголовочные файлы: достаточно только бинарных библиотек. >Но обычно автору программы кроме бинарной либки нужен еще и мануал :-) а вместе с ним не проблема и хедер достать :-)

ага, и всё одной и той же конкретной версии. И получаются файлы-фреймворки в MacOSX, где в одном файле в виде папки-бандла лежат lib, include, doc, и т. п. Правда, бинарные либы в случае С++ не спасут из-за "хрупкости базового класса" (что не страшно, если есть исходники, и не нужно, если ОО реализован более гибко, не ломая бинарную совместимость (например, как MOP или как в ObjectiveC))

>Еще улыбнуло про то, как программа может продолжать работать без одной из библиотек :-)

как мигалка, работает-не работает :))

Кстати, вот ещё преимущества managed кода: если у него есть метаданные про зависимости, конкретная managed "программа на php" может грузить не все библиотеки, а только нужные, и грузить не всю библиотеку целиком, а только отдельные классы-методы.

>> Байт-код - архитектуро-независимое представление

>Правда? Машинный код (пусть и абстрактного, но довольно низкоуровневого) процессора - это архитектурно-независимое представление? Больше вопросов нет.

он наполовину прав. Да, байт-код -- это машинный код абстрактной виртуальной машины. Но этот код в более общем виде, чем машинный код реального конкретного ЦПУ: например, у реальных ЦПУ конечное число регистров, а у виртуальной машины, как в llvm или VPcode может быть неограниченное число регистров.

В этом смысле, байт-код не зависит от реализации на конкретном ЦПУ ))

и поэтому интересен такой байткод и такая виртуальная машина, архитектура которой прозрачно ложится на архитектуру реального ЦПУ, как Dis, llvm, VPcode

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

вон Qt тоже svg умеет показывать, задействует OpenGL. Тоже скрипт для браузера будешь писать чтобы Qt протестировать?

Ява дает решение проблемы хрупкости базового класса, но оно обеценивается окружением и даже немного опасно.

А что если в классе чуть-чуть _несовместимо_ поменялась логика? Такое очень даже бывает. И даже не всегда есть переключение на старую логику.

Вот пример (не ява, но пхп) функция text2html (название неточно) стала вместо <br> вставлять <br /> и у кого-то пошли баги...

Явовское так называемое "решение" дает ложное чувство спокойствия. Полным оно было бы если

1) ява имела в каждом классе поле версии

2) в готовой сборке хранились бы версии классов из которых она собиралась

3) какждый класс указывал с какой своей версией он все еще совместим

--------------------

Почему я считаю что Managed OS это тупик эволюции:

потому что не-Managed OS всегда сможет выполнять под собой код (в основном библиотеки) из ВСЕХ ОСТАЛЬНЫХ Managed OS,

но Managed OS не сможет выполнять под собой код не-Managed OS

и с большим-большим трудом, если вообще, код ДРУГИХ Managed OS

Да, предположим чудо. JNode допилили и переписали всю явовскую библиотеку, написанную на С, на яве.

Что будет тогда?

А тогда кто-то сделает (если уже не сделан) модуль, который позволит прогу запускать прямо в ядре линукса в kernel mode (и паметер ядра типа no_init). Прогой этой будет JVM родной или почти родной.

И если прям таки тебя так напрягает переключение user -- kernel мод, разные адресные пространства празных процессов -- то возьми линукс и грузи его в режиме no_init. Переключений контекста не будет так как юзеровских процессов нет :-) Ну может его пропатчит надо чуток, но это работы не больше чем написать микроядро JNode.

Мое мнение -- разработчиков JNode прет от того, что они делают свою ОС. И в этом только польза от нее, не больше.

>> Байт-код - слишком низкоуровневое представление программы, в котором нет многой важной информации для оптимизации.

> например?

Байткод Явы. Я уже несколько раз постил ссылку на работу Франца о Slim binaries.

> а если байткод, как в llvm специально сделан, чтобы эту информацию сохранять?

А если, как в JVM, не сделан?

> Вот пример (не ява, но пхп) функция text2html (название неточно) стала вместо <br> вставлять <br /> и у кого-то пошли баги...

А в любой линуксовой библиотеке таких изменений случиться не может? Может и случалось. Я знаю, что когда делают несовместимые изменения, меняют цифру после .so, но в яве это решено лучше: совершенно спокойно в одной VM могут существовать разные версии одного и того же класса. ClassLoader - весьма гибкая штука. И это реально работает: сервер приложений может выполнять приложение, которое использует ту же библиотеку, что и сам сервер, но другую версию.

> 1) ява имела в каждом классе поле версии

Это возможно и используется там, где необходимо. Например, при сериализации (поле serialVersionUID). Если очень хочется, никто не мешает определить в классе поле версии.

> 2) в готовой сборке хранились бы версии классов из которых она собиралась

> 3) каждый класс указывал с какой своей версией он все еще совместим

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

>>> Байт-код - слишком низкоуровневое представление программы, в котором нет многой важной информации для оптимизации.

>> например?

> Байткод Явы. Я уже несколько раз постил ссылку на работу Франца о Slim binaries.

Так какой именно информации не хватает в байт-коде Явы?

http://www.linux.org.ru/view-message.jsp?msgid=2541178&lastmod=1204220659986

На объективность не претендует.

> Так какой именно информации не хватает в байт-коде Явы?

Франца почитай. А если ты тот анонимус, который говорил о LLVM - то вот цитата с llvm.org: "Low Level Virtual Machine (LLVM) is:

1. A compilation strategy designed to enable effective program optimization across the entire lifetime of a program. LLVM supports effective optimization at compile time"

И только вторым пунктом идет: "A virtual instruction set - LLVM is a low-level object code representation that uses simple RISC-like instructions, but provides rich, language-independent, type information and dataflow (SSA) information about operands."

SSA нет в .class-файлах. И, подозреваю, что еще много чего из LLVM там нет. Интересуешься деталями - сравнивай сам.

> SSA нет в .class-файлах. И, подозреваю, что еще много чего из LLVM там нет. Интересуешься деталями - сравнивай сам.

Вы удивитесь, наверное, очень, но JIT-компилятор в JVM HotSpot (та самая, что в составе Sun JRE) использует представление SSA, получая его из байт-кода (который достаточно высокоуровневый для этого).

>> 3) каждый класс указывал с какой своей версией он все еще совместим

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

Свой загрузчик классов действительно можно сделать, но...

А) Будут ли это делать программеры, которых сан и прочие верующие пропиарили насчет Великой Явы Гениально И Польностью Решающей За Них Проблему Хрупкости Базовых Классов?

Кто понимает что проблема осталась, тот и на С++ ее не имеет... ее там решить не сложнее чем написать свой загрузчик классов.

Б) Обычно несовместимо меняются чужие классы, так как свои тестируются при новом релизе. Т.е. надо заставить разработчика чужого класса ввести в нем статическое поле с версией.

>меняют цифру после .so, но в яве это решено лучше: совершенно спокойно в одной VM могут существовать разные версии одного и того же класса

чем это лучше цифры после (или перед) .so?

цифра тоже дает возможность "совершенно спокойно в одной OS существовать разным версиям одного и того же класса"

>> 1) ява имела в каждом классе поле версии

>Это возможно и используется там, где необходимо. Например, при сериализации (поле serialVersionUID). Если очень хочется, никто не мешает определить в классе поле версии.

А serialVersionUID абсолютно бесполезен для решения проблемы ХБК. Ибо он не известен программеру в момент написания старого класса.

>Явовское так называемое "решение" дает ложное чувство спокойствия. Полным оно было бы если

угу, вводить манифесты на все компоненты с жестко прописанными версиями, и желательно версии в смысле Mercurial, какой-то GUID Ж))

>Почему я считаю что Managed OS это тупик эволюции:

>потому что не-Managed OS всегда сможет выполнять под собой код (в основном библиотеки) из ВСЕХ ОСТАЛЬНЫХ Managed OS,

>но Managed OS не сможет выполнять под собой код не-Managed OS

разве что запустить в sandbox'е vm с не-managed OS :)

>и с большим-большим трудом, если вообще, код ДРУГИХ Managed OS

это кажется проще: достаточно реализовать sandbox с vm другой managed OS.

>Ява дает решение проблемы хрупкости базового класса, но оно обеценивается окружением и даже немного опасно.

>А что если в классе чуть-чуть _несовместимо_ поменялась логика? Такое очень даже бывает. И даже не всегда есть переключение на старую логику.

это как в Gentoo, вроде бы есть пакетный менеджер, строгие версии на всё.. и все равно, в моменты emerge world можно поймать наполовину обновившиеся компоненты, установить пакет, который сломает другие компоненты, и придётся revdep-rebuild запускать чтобы заново пересобрать.

Хотя если сидеть на замаскированных, вполне stable :)

>А если, как в JVM, не сделан?

придется дополнять нужными метаданными и извращаться, как с аспектами AOP. :))

>А serialVersionUID абсолютно бесполезен для решения проблемы ХБК. Ибо он не известен программеру в момент написания старого класса.

просто надо брать не все serialVersionUID (как версии в репозитории Mercurial), а брать GUIDы, соответствующие release тегам из репозитория.

>А тогда кто-то сделает (если уже не сделан) модуль, который позволит прогу запускать прямо в ядре линукса в kernel mode (и паметер ядра типа no_init). Прогой этой будет JVM родной или почти родной.

емнип, модуль binfmt умеет грузить .class файлы, правда, через wrapper в user-mode.

> емнип, модуль binfmt умеет грузить .class файлы, правда, через wrapper в user-mode.

binfmt - просто запускалка java и др. vm/интерпретаторов/эмуляторов - это не то. Ничего, кроме просто удобства он не дает.

> Свой загрузчик классов действительно можно сделать, но...

Я же сказал, что это можно, но *не нужно*.

> чем это лучше цифры после (или перед) .so?

Цифру после .so могут и не поменять. Не всегда можно заранее достоверно определить, вызовут ли изменения проблемы с совместимостью.

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

> цифра тоже дает возможность "совершенно спокойно в одной OS существовать разным версиям одного и того же класса"

В одной ОС - да (и то не без проблем), в одном процессе - уже сложнее.

> А serialVersionUID абсолютно бесполезен для решения проблемы ХБК

Я сказал, для чего нужен serialVersionUID.

>>но Managed OS не сможет выполнять под собой код не-Managed OS

>разве что запустить в sandbox'е vm с не-managed OS :)

а для запуска sandbox-a надо уметь переключаться между user / kernel модами -- и все хваленые преимущества Managed OS теряются

щас кто-то скажет что "а все остальные проги не будут переключаться" -- так возьмите линукс и напишите к нему модуль грузящий всю вашу Очень Безопасную Яву в ядро и получится то же самое, только лучше, так как

1) не придется wine портировать в jnode

2) и те кто в вашу Очень Безопасную Яву не верит, все же смогут запускать ее вне kernel mode.

>> Свой загрузчик классов действительно можно сделать, но...

> Я же сказал, что это можно, но *не нужно*.

Не нужно поскольку (цитирую) "в одной VM могут существовать разные версии одного и того же класса." -- то есть фактически никто Великим Явовоским Решением Проблемы Хрупкости Базового Класса пользоваться не хочет, а просто держат у себя именно ту самую версию класса которого надо...

>Цифру после .so могут и не поменять. Не всегда можно заранее достоверно определить, вызовут ли изменения проблемы с совместимостью.

Влом отвечать, попросишь -- отвечу... но опять писанины на несколько страниц.

>В Java зависимости разрешаются на уровне классов - более мелкая единица, чем библиотека; используются иерархические пространства имен (пакеты);

Это конечно интересная возможность.

Но мне кажется одна прога использующая хотя бы 2 версии одного и того же класса -- дикое извращение.

А что будет если объект My_Class v.1 попадет аргументом в функцию My_Class v.2 ??? И если ничего страшного не будет, почему бы не иметь единственную версию класса?

> совместимость на бинарном уровне почти равна совместимости на уровне исходного кода (для .so это далеко не так).

Ключевое слово -- почти. Об этом мы уже говорили.

>> А serialVersionUID абсолютно бесполезен для решения проблемы ХБК

> Я сказал, для чего нужен serialVersionUID.

А тебя кто спрашивал о нем? Моя тема на которую ты отвечал была о проблеме хрупкости базовых классов, или о том как ява ее решает, или о том зачем нам jnode. А зачем обсуждать как ява сериализует классы -- не ясно.

> А тебя кто спрашивал о нем?

Это просто пример использования поля класса для обозначения его версии. Я не предлагаю использовать его для контроля совместимости публичных API.

> Не нужно поскольку (цитирую) "в одной VM могут существовать разные версии одного и того же класса." -- то есть фактически никто Великим Явовоским Решением Проблемы Хрупкости Базового Класса пользоваться не хочет, а просто держат у себя именно ту самую версию класса которого надо...

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

> Но мне кажется одна прога использующая хотя бы 2 версии одного и того же класса -- дикое извращение.

Уже был пример с сервером приложений.

> Ключевое слово -- почти. Об этом мы уже говорили.

Почти, но гораздо лучше, чем для разделяемых библиотек вроде .so.
Полностью будет только для интерпретируемых языков.

Я: ... полным было бы если: 1) ява имела в каждом классе поле версии 2) ... 3) ...

Гость: Например, при сериализации (поле serialVersionUID)...

Я: А serialVersionUID абсолютно бесполезен для решения проблемы ХБК

Гость: Я сказал, для чего нужен serialVersionUID.

Я: А тебя кто спрашивал о нем?

Гость: Это просто пример использования поля класса для обозначения его версии. Я не предлагаю использовать его для контроля совместимости публичных API.

------------

Гость, я очень рад что тебе понравились мои слова о поле версии и его использовании... но мне хотелось бы обсдить что-то не столь тривиальное

> но мне хотелось бы обсдить что-то не столь тривиальное

Тогда к чему это сообщение?

Суть моего примера с serialVersionUID в том, что для сериализации (например) нужно поле версии класса, а вот для решения обсуждаемой нами задачи - нет, не нужно.

>Суть моего примера с serialVersionUID в том, что для сериализации (например) нужно поле версии класса, а вот для решения обсуждаемой нами задачи - нет, не нужно.

ОК. Я обсуждал проблему ХБК. А ты видимо проблему разных версий библиотеки. Давай обсудим твою проблему.

1) Насколько я понимаю, запускать в одном процессе один класс разных версий нужно только яве в серверах приложений, поскольку для экономии памяти один процесс сервера приложений запускает под собой то, что в нормальном случае (С, С++, PHP) шло бы в нескольких процессах.

Форк процесса на юниксе на современном проце очень быстр (copy-on-write). Это вам не микрософт.

Т.е. ява успешно решает проблему которой ВООБЩЕ НЕТ под С и С++ и допустим PHP :-)

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

Жду пример когда не-серверу-приложений действительно нужен один класс разных версий.

BTW: как динамически типизированный язык пхп гораздо хуже явы, но очень многие приписываемые Великой Яве достоинства из области мифологии.

2) Гранулярность на уровне класса а не библиотеки... жду пример когда она нужна.

> Форк процесса на юниксе на современном проце очень быстр (copy-on-write). Это вам не микрософт.

Т.е. вы предлагаете во всех модульных приложениях запускать модули в отдельных процессах? Круто!

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

Это решает другую проблему. Ещё раз смотрите пример с сервером приложений.

> Гранулярность на уровне класса а не библиотеки... жду пример когда она нужна.

Уже было. При отсутствии нужного класса в библиотеке (или несовместимости) приложение может запуститься, работать и использовать библиотеку, пока этот класс не понадобиться. Когда понадобиться, произойдет нефатальная ошибка, можно просто сообщить пользователю, что данная функциональность недоступна.

А вы заметили, что Java-приложения вообще отличаются модульностью (NetBeans, Eclipse, JEdit)?

> Форк процесса на юниксе на современном проце очень быстр (copy-on-write). Это вам не микрософт.

>Т.е. вы предлагаете во всех модульных приложениях запускать модули в отдельных процессах? Круто!

Конечно не во всех, а в только тех, кому нужны классы разных версий в одном процессе, ТАК КАК это именно тот случай, когда ява насильно пихает несколько процессов в один.

ПО-ПРЕЖНЕМУ ЖДУ пример когда не-серверу-приложений действительно нужен один класс разных версий.

> А вы заметили, что Java-приложения вообще отличаются модульностью (NetBeans, Eclipse, JEdit)?

Они модульны не потому, что это ява приложения, а потому, что это очень большие приложения и им быть немодульными нельзя.

> Уже было. При отсутствии нужного класса в библиотеке (или несовместимости) приложение может запуститься, работать и использовать библиотеку, пока этот класс не понадобиться. Когда понадобиться, произойдет нефатальная ошибка, можно просто сообщить пользователю, что данная функциональность недоступна.

Представил я... сижу пару часов, редактирую 3Д-сцену, все хорошо, пытаюсь сохранить работу в файл... а оно и говорит -- нет мол одного маааааленького класса, так что функциональность сохранения не работает... редактируй типа дальше, дорогой друг...

Может ява программистов такие приложения устраивают, а меня нет.

> Конечно не во всех, а в только тех, кому нужны классы разных версий в одном процессе, ТАК КАК это именно тот случай, когда ява насильно пихает несколько процессов в один.

Почему "насильно"? Насильно было бы разделять.

> ПО-ПРЕЖНЕМУ ЖДУ пример когда не-серверу-приложений действительно нужен один класс разных версий.

Любые плагины, использующие другую версию той же библиотеки, что и основная программа.

> Они модульны не потому, что это ява приложения, а потому, что это очень большие приложения и им быть немодульными нельзя.

JEdit не такое уж и большое приложение. Просто модульность в Java достигается проще. Без модулей JEdit - "блокнот", с модулями - IDE. Вспомните какую-нибудь программу на C, которая представляет из себя простой каркас, практически неограниченно расширяемый модулями. Обнаружите, что эта программа все-равно использует для расширений интерпретируемый язык (JavaScript в Firefox, Lisp в Emacs). А Java дает в этом смысле ту же гибкость, но гораздо лучшую производительность.

> Представил я... сижу пару часов, редактирую 3Д-сцену, все хорошо, пытаюсь сохранить работу в файл... а оно и говорит -- нет мол одного маааааленького класса, так что функциональность сохранения не работает... редактируй типа дальше, дорогой друг...

В этом случае - это ошибка программиста не предупреждать пользователя заранее о невозможности сохранить документ.

С описанной ситуацией я не сталкивался, но вот такое бывает:
сижу, редактирую что-то в какой-то нативной программе, хочу сохранить - программа падает. Оказывается, что причина - изменения в работе какой-то библиотеки при совместимости ABI.

Java-приложение хотя-бы не упадет. В худшем случае, будет необработанное исключение, которое прервет поток обработки событий. Приложение будет работать дальше, просто не выполнится последнее действие пользователя.

>Почему "насильно"? Насильно было бы разделять.

И что насильного есть в разделении процессов апача под каждый хттп запрос? (так как начался разговор с сервера приложений и того как там уютно разным явовским классам в одном процессе) Как раз наоборот несколько запросов в одном процессе JVM -- это насилие.

> Вспомните какую-нибудь программу на C, которая представляет из себя простой каркас, практически неограниченно расширяемый модулями. Обнаружите, что эта программа все-равно использует для расширений интерпретируемый язык (JavaScript в Firefox, Lisp в Emacs). А Java дает в этом смысле ту же гибкость, но гораздо лучшую производительность.

3DMAX например имел плагины задоооооолго до того как там скриптовый язык появился.

Maya хотя и имела скриптовый язык сразу, но расширябельна через чистый С.

И так далее...

>> ПО-ПРЕЖНЕМУ ЖДУ пример когда не-серверу-приложений действительно нужен один класс разных версий.

>Любые плагины, использующие другую версию той же библиотеки, что и основная программа.

И что случится если плагин передаст в основную программу объект класса своей версии, а не версии основной программы?

> хочу сохранить - программа падает. Оказывается, что причина - изменения в работе какой-то библиотеки при совместимости ABI. Java-приложение хотя-бы не упадет.

1) В Великой Яве не бывает "изменения в работе какой-то библиотеки при совместимости ABI" ? (ABI там всегда совместимо, речь идет именно о библиотеке)

2) Оно таки не упало... Слава Великой Яве!... а в чем польза? Сохранить-то все равно нельзя?

>> так что функциональность сохранения не работает... редактируй типа дальше, дорогой друг...

> В этом случае - это ошибка программиста не предупреждать пользователя заранее о невозможности сохранить документ.

Ошибка программиста в том что он полагается на Прекрасную Фичу, Воспетую Многоми Приверженцами Явы -- загрузку класса по требованию.

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

> хочу сохранить - программа падает. Оказывается, что причина - изменения в работе какой-то библиотеки при совместимости ABI. Java-приложение хотя-бы не упадет.

Если библиотека использует С++ и exceptions, то (при совместимости ABI) приложение тоже не упадет.

> И что насильного есть в разделении процессов апача под каждый хттп запрос? (так как начался разговор с сервера приложений и того как там уютно разным явовским классам в одном процессе) Как раз наоборот несколько запросов в одном процессе JVM -- это насилие.

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

> 3DMAX например имел плагины задоооооолго до того как там скриптовый язык появился.
> Maya хотя и имела скриптовый язык сразу, но расширябельна через чистый С.

Ну да, только эти расширения реализуют функциональность определенного типа. Кроме того, не 3Dmax, не Maya не назовешь каркасом. Все ровно, это не так гибко.

> 1) В Великой Яве не бывает "изменения в работе какой-то библиотеки при совместимости ABI" ? (ABI там всегда совместимо, речь идет именно о библиотеке)

Есть, но программа на Java не упадет.

> Оно таки не упало... Слава Великой Яве!... а в чем польза? Сохранить-то все равно нельзя?

Это в любом случае лучше, чем падение. Можно, например, попробовать сохранить в другом формате.

> И что случится если плагин передаст в основную программу объект класса своей версии, а не версии основной программы?

Ничего страшного, если основная программа требует реализацию некого абстрактного класса или интерфейса (обычная ситуация). Основная программа может получить эту реализацию от модуля и при этом где-то ещё использовать другую реализацию, которая есть тот же класс, но другой версии.

> Слава Великой Яве!

Я тут не Яву защищаю, а идею управляемого кода и управляемой ОС в общем. JVM - пример. То же верно и для Dis, CLR, etc.

> Если библиотека использует С++ и exceptions, то (при совместимости ABI) приложение тоже не упадет.

Это смотря в чем выражается несовместимость.

> Ну да, только эти расширения реализуют функциональность определенного типа. Кроме того, не 3Dmax, не Maya не назовешь каркасом. Все ровно, это не так гибко.

Ты видимо и тысячи часов не сидел в 3Dmax. Без плагинов он вообще мало пригоден к работе, и много чего там вообще идет как плагины от разработчика.

Могу соврать (ибо давно это было) но вроде как если длл-ки удалить то он запустится но даже куб не создать. Но сцена в файл сохраняется.

А еще интересно какого типа функциональность нельзя создать там плагином. Просвети, ведь "эти расширения реализуют функциональность определенного типа".

> Я тут не Яву защищаю, а идею управляемого кода и управляемой ОС в общем. JVM - пример. То же верно и для Dis, CLR, etc.

Ява это конечно вопиющий пример маркетоидного наезда по ушам.

Но по сути не верю я в управляемую ОС, почему -- писал уже -- она не совместима с неуправляемыми и другими управляемыми, но неуправляемая ОС совместима с любыми управляемыми.

> Ничего страшного, если основная программа требует реализацию некого абстрактного класса или интерфейса (обычная ситуация). Основная программа может получить эту реализацию от модуля и при этом где-то ещё использовать другую реализацию, которая есть тот же класс, но другой версии.

В С++ можно указатель на потомок передавать вместо указателя на базовый класс, и часто БИНАРНО этот указатель не меняется. Компилятор этот указатель бинарно изменяет при множественном наследовании __и__ при кастинге на указатель не на первый из базовых классов, что в общем случается редко, так как множественное наследование часто используется как наследование интерфейса явы или как приватное/защищенное наследование, в результате чего указатель на приватный/защищенный базовый класс невозможно получить вне производного класса/его потомков.

В целом, сан возможно и придумал в яве что-то интересное, но это надо изучить и портировать под С++. Во всяком случае рефлекшн до определенной степени нужен... хотя может совсем не так как в яве.

>> Если библиотека использует С++ и exceptions, то (при совместимости ABI) приложение тоже не упадет.

>Это смотря в чем выражается несовместимость.

Если хорошо знаешь вопросы линковки, расскажи плиз.

Хотя я критикую Яву, мне всегда очень интересно знать проблемы реализаций С++.

Я допускаю возможность разработать в native коде гибкую архитектуру плагинов, но это сложнее и ненадежно (кривой плагин может уронить все приложение).

> Во всяком случае рефлекшн до определенной степени нужен...

С трудом представляю себе рефлекшн на C++. Это вообще фича интерпретируемых и управляемых языков.

> Если хорошо знаешь вопросы линковки, расскажи плиз.

Я здесь имел в виду уже не проблемы с линковкой, а несовместимые изменения в реализации тех же функций, например, такие, которые приводят к переполнению буфера из-за неправильной интерпретации аргументов.

> С трудом представляю себе рефлекшн на C++. Это вообще фича интерпретируемых и управляемых языков.

Ерунда. Компилятор имеет всю информацию, и может положить ее в объектный файл в стандартном формате (DWARF2 - это практически оно).

>> Во всяком случае рефлекшн до определенной степени нужен...

> С трудом представляю себе рефлекшн на C++. Это вообще фича интерпретируемых и управляемых языков.

Типичная жертва Sum Microsystems. Я не удивлюсь если тут мне скоро будут говорить что и велосипед возможен только в управляемых языках под управляемыми ОС :-)

Для плюсов рефлекшн есть в boost, есть куча разных на основе внутреннего представления gcc, кажись есть на основе dwarf ... а плакался я тут по поводу рефлекшн только потому, что нет единого стандарта, как в яве :-)

Кстати аннотации тоже полезны... но не такие убогие как в яве, там даже нельзя от аннотации сделать производный класс.

(щас опять нам скажут что аннотации возможны только в интерпретаторе?)