[devel] Java: no magic wand

[devel] Java: no magic wand

[Igor Vlasenko]

Java: no magic wand.
--------------------

Уважаемые коллеги, хотел бы поделиться своими мыслями 
по поводу развития java - подрепозитория Сизифа.

Некоторые вопросы уже обсуждались в беседах с 
Виталием Липатовым и Денисом Смирновым, в частности, 
был вопрос, когда же в java-пакетах появится 
автоопределение зависимостей.

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

Почему так?

Хотел бы ответить на этот вопрос развернуто.

Напомню, зачем нужно автоопределение зависимостей 
и как оно работает.

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

Работает оно, потому что в языке (perl,python,ruby...)
или стандартно в системе (C,C++,...) есть

1) стандартные названия библиотек 
[никому из нас и в голову не придет собирать libz как 
libaltz и пытаться продавливать в апстримы патчи
вида s/-lz/-laltz/ либо паковать Pod::Parser как 
Documents::Pod::Parser], не зависящие от названия пакета
(zlib или libz или libaltz, perl или perl-Pod или 
perl-PodDocumentUtils)

2) стандартная (мета)информация о зависимостях
(выполнена ли она в виде директивы import в питоне
либо находится в заголовке ELF binary file)

3) стандартные пути поиска (/usr/lib, %perl_vendorsdir,..)

4) стандартный загрузчик, который используя 2) рекурсивно
ищет 1) в 3).
В этом случае для успешной компоновки программы 
с библиотеками есть только одно препятствие --
отсутствие в системе нужных библиотек и автоопределение 
зависимостей эту проблему успешно решает, без труда 
со стороны майнтайнера, как волшебная палочка.

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

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

1') нет метаинформации о компоновочных зависимостях;

2') нет стандартных путей поиска;

3') нет стандартных названий библиотек.

соответственно нет и 
4') стандартного рекурсивного компоновщика/загрузчика, 
который бы использовал 1-3).

(у gcj, правда, есть свой мопед, связанный с компиляцией
в нативный код; но это уже не java.)

Что в этой ситуации даст корректное автоопределение 
зависимостей?

Поясню на примере. Пусть у нас есть редактор .xyz файлов,
jxyzedit. Его запуск неразрывно связан с компоновкой.
Чтобы его запустить, нужно в /usr/bin/jxyzedit 
(шелл - скрипте запуска) написать что-то вроде 
java -classpath $(build-classpath commons-codec):\
$(build-classpath jxyzedit) org.jxyzedit.GUI.Main
либо, раскрывая,
java -classpath /usr/share/java/commons-codec.jar\
:/usr/share/java/jxyzedit.jar org.jxyzedit.GUI.Main

Пример 1.
---------
Пусть идеальный автоопределитель зависимостей, 
изучая jxyzedit.jar, вывел зависимость jxyzedit 
на jakarta-commons-codec (содержащий commons-codec.jar).

Пусть теперь вышла новая версия commons-codec,
у которой внутренняя кухня теперь использует commons-primitives
(нечто подобное, кстати, уже было).

Пусть идеальный автоопределитель зависимостей, 
изучая commons-codec.jar, вывел зависимость нового
jakarta-commons-codec на jakarta-commons-primitives. 
(содержащий commons-primitives.jar).

При обновлении jakarta-commons-codec доустанавливается
jakarta-commons-primitives, но jxyzedit благополучно
падает, поскольку надо руками править запуск jxyzedit
и добавлять туда commons-primitives.jar.

Пример 2.
---------
Пусть вышла новая версия jxyzedit, требующая для работы
commons-compress.jar из jakarta-commons-compress.

Идеальный автоопределитель зависимостей, изучая 
jxyzedit.jar, добавил зависимость jxyzedit на jakarta-\
commons-compress (содержащий commons-compress.jar).

Но скрипты для запуска jxyzedit писал майнтайнер,
поскольку сам апстрим запускает свой jxyzedit в таком
оффтопике, что не к ночи в этой рассылке будь помянуто.
Он невнимательно провел сборку и не поправил запуск jxyzedit.

Теперь при установке jxyzedit устанавливается
jakarta-commons-compress, но jxyzedit благополучно
падает, поскольку надо руками править запуск jxyzedit
и добавлять туда commons-compress.jar.

Таким образом, если нет 1)-4), то 
от идеального автоопределителя зависимостей 
пользователю ни холодно, ни жарко. 
No magic wand.

======================================================
Небольшое отступление.
----------------------

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

Дамир, а потом и Алексей, предлагали реализации 
автоопределителя для java. как понимаю,
у этих подходов проблемы с зависимостями на интерфейсы.

Как я говорил, без  1)-4) идеальный автоопределитель
почти бесполезен. И, как показывает горький опыт,
некорректный автоопределитель существенно вреден,
поскольку иногда проставляет некорректные зависимости.
на борьбу с которыми тратится много сил.

Не хочется иметь ситуацию, когда при установке tomcat
вытягивается jboss, а заодно и jetty (или наоборот).

Примером полезного автоопределителя, на борьбу с которым
тратится много сил, является symlinks.req. Его 
полезным побочным эффектом является обнаружение линковочных
зависимостей для java специального вида, но сейчас у него 
возникают проблемы с разными библиотеками, реализующими 
один и тот же интерфейс. Но и проблемы полезны, поскольку 
тем самым он указывет на некоторые внутренние проблемы 
репозитария (там, где сам не ошибается). Вот как раз в 
последней сборке jetty5 всплыли проблемы с symlinks.req. 
Разберусь - доложу в bugzilla.

====================================================

Вывод.
------
A. без  1)-4) идеальный автоопределитель зависимостей 
для java почти бесполезен.

B. Сначала нужно заботиться об 1)-4).

C. Ошибки в реализации велосипедов с колесами 1)-4)
и рулем в виде автоопределителя зависимостей будут
больно бить и по Сизифу (придется каждый раз 
пересобирать заново), и по пользователям.

поэтому

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

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] Java: no magic wand

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 2472 bytes --]

On Thu, Jan 10, 2008 at 10:41:06PM +0200, Igor Vlasenko wrote:

IV> Java: no magic wand.
IV> --------------------

Выводы верны, но не все предпосылки верны.

IV> 1) стандартные названия библиотек 
IV> [никому из нас и в голову не придет собирать libz как 
IV> libaltz и пытаться продавливать в апстримы патчи
IV> вида s/-lz/-laltz/ либо паковать Pod::Parser как 
IV> Documents::Pod::Parser], не зависящие от названия пакета
IV> (zlib или libz или libaltz, perl или perl-Pod или 
IV> perl-PodDocumentUtils)

Я правильно понимаю, что если я говорю о Jetty, то я говорю об
org.mortbay.*, например?

Поясняю мысль -- у Java нет понятия "библиотека". Есть понятие "класс" и
"каталоги поиска". Эти каталоги могут быть заzipованы, и тогда это jar.

Но jar не обладает практически никакими свойствами нормальной библиотеки.
Хотя по своей сути сильно напоминает старые добрые .a библиотеки.

IV> 2) стандартная (мета)информация о зависимостях
IV> (выполнена ли она в виде директивы import в питоне
IV> либо находится в заголовке ELF binary file)

Они самые, import в Java-исходнике. И ссылки на конкретные классы уже в
.class. Так что это уже есть.

Мы здесь имеем слишком тонкую нарезку правда. Единицей у нас является
класс/интерфейс, но никак не "библиотека". К счастью у нас единица не
"отдельный метод" чему можно сильно радоваться.

IV> 3) стандартные пути поиска (/usr/lib, %perl_vendorsdir,..)

/usr/share/java. Только этот путь подходит для поиска зависимостей, но
никак не для загрузчика.

Хотя у нас есть еще одна вещь -- в META-INF может быть жестко прописаный
classpath. Я не знаю какие недостатки у этого решения, но плюсы очевидны:
 - можно делать простые файловые зависимости
 - их удовлетворение может автоматически означать возможность запустить
   приложение

IV> 4) стандартный загрузчик, который используя 2) рекурсивно
IV> ищет 1) в 3).

Увы. Такой загрузчик даже теоретически можно написать (!), учитывая
alternatives.

И собственно вся задача упирается именно в этот самый стандартный
загрузчик.

Возможна даже реализация чего-то вроде symbol versioning, который бы
использовался генераторами requires и provides.

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

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
АКСИОМА ГУРДА
 На собраниях - экономят минуты и теряют часы.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Java: no magic wand

[Igor Vlasenko]

On Mon, Jan 14, 2008 at 10:08:36AM +0300, Денис Смирнов wrote:

> Выводы верны, но не все предпосылки верны.

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

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

Не туда ушли акценты - не то хотел сказать в письме.
Хотел сказать следующее.

Уже достаточно давно я зачал и вынашиваю идею
платформы для юнит-тестов репозитария. 
С кешированием, БД, интеграцией с prometeus.

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

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

И деструктивные зависимости (порождающие конфликты и т.д.) 
на глаз не очевидны, плюхнешь в Сизиф, и если бы через 
день beehive status +30! error logs, было бы счастье.
Сборочный тест не так часто проходит, поэтому накопится и 
придет через 3 недели beehive status +130! error logs...
Без бутылки ни-ни.

В сложных вопросах робот пусть лучше советует, 
а решает пусть человек.

Проводя аналогию, злобный 
(поскольку ошибается, но думает, что прав)
сборочный робот с криком "Вон, пшел!"
отпихивает ногами, а юнит-тест докладывает 
"Не будет ли любезен благородный дон 
взглянуть на свой загрузочный скрипт..."

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] Java: no magic wand

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1976 bytes --]

On Mon, Jan 14, 2008 at 07:08:53PM +0200, Igor Vlasenko wrote:

IV> И в письме хотел провести мысль, что если 
>> задача получается комплексная и непростая,
IV> то оптимально ее опробовать внешними тестами.
IV> Лучше сначала на собаках, а не на людях, эксперименты ставить. 

Безусловно.

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

Ну, автовыставление provides можно раньше начать использовать (да и нужно
раньше начать) чем requires.

Меня сейчас больше беспокоит проблема раздувания rpm базы. Если
зависимости делать на уровне классов (а то и методов) то это получается не
просто кошмар, а кошмарище.

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

IV> И деструктивные зависимости (порождающие конфликты и т.д.) 
IV> на глаз не очевидны, плюхнешь в Сизиф, и если бы через 
IV> день beehive status +30! error logs, было бы счастье.
IV> Сборочный тест не так часто проходит, поэтому накопится и 
IV> придет через 3 недели beehive status +130! error logs...
IV> Без бутылки ни-ни.

Согласен.

IV> В сложных вопросах робот пусть лучше советует, 
IV> а решает пусть человек.

Безусловно.

IV> Проводя аналогию, злобный 
IV> (поскольку ошибается, но думает, что прав)
IV> сборочный робот с криком "Вон, пшел!"
IV> отпихивает ногами, а юнит-тест докладывает 
IV> "Не будет ли любезен благородный дон 
IV> взглянуть на свой загрузочный скрипт..."

:)

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Русские программисты ненавидят Microsoft и их программы, но впрочем иногда
ими пользуются.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Java: no magic wand

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

On Tue, Jan 15, 2008 at 10:48:22AM +0300, Денис Смирнов wrote:
> Меня сейчас больше беспокоит проблема раздувания rpm базы. Если
> зависимости делать на уровне классов (а то и методов) то это получается не
> просто кошмар, а кошмарище.

А почему так беспокоит раздувание rpm базы?  rpm база раздувается
от java заведомо не больше, чем раздувается /usr.  То есть намного
меньше, конечно же.

К тому же стоит внимательно посмотреть `ls -l --sort=size /var/lib/rpm'.
Речь идёт о файлах Requirename и Providename.  Имена файлов и md5-сумм
раздувают базу на порядок сильнее, чем зависимости (well, this might
not be the case for java), а основной bloat наверное приходится на
слишком длинные changelog'и.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Java: no magic wand

[Igor Vlasenko]

On Wed, Jan 16, 2008 at 01:30:30AM +0300, Alexey Tourbin wrote:
> > Меня сейчас больше беспокоит проблема раздувания rpm базы. Если
> А почему так беспокоит раздувание rpm базы?  rpm база раздувается
> от java заведомо не больше, чем раздувается /usr.  То есть намного
> меньше, конечно же.
> Речь идёт о файлах Requirename и Providename.  Имена файлов и md5-сумм
> раздувают базу на порядок сильнее, чем зависимости (well, this might
> not be the case for java), а основной bloat наверное приходится на
> слишком длинные changelog'и.
Спасибо, будем знать!

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] Java: no magic wand

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 968 bytes --]

On Wed, Jan 16, 2008 at 01:30:30AM +0300, Alexey Tourbin wrote:
> On Tue, Jan 15, 2008 at 10:48:22AM +0300, Денис Смирнов wrote:
> > Меня сейчас больше беспокоит проблема раздувания rpm базы. Если
> > зависимости делать на уровне классов (а то и методов) то это получается не
> > просто кошмар, а кошмарище.
> 
> А почему так беспокоит раздувание rpm базы?  rpm база раздувается
> от java заведомо не больше, чем раздувается /usr.  То есть намного
> меньше, конечно же.
> 
> К тому же стоит внимательно посмотреть `ls -l --sort=size /var/lib/rpm'.
> Речь идёт о файлах Requirename и Providename.  Имена файлов и md5-сумм
> раздувают базу на порядок сильнее, чем зависимости (well, this might
> not be the case for java), а основной bloat наверное приходится на
> слишком длинные changelog'и.

Обычно беспокоит не размер базы, а скорость работы, скажем, apt-get
dist-upgrade.  И на это размеры changelog'ов влияют в последнюю очередь.



-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Java: no magic wand

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 567 bytes --]

On Wed, Jan 16, 2008 at 01:30:30AM +0300, Алексей Турбин wrote:

AT> А почему так беспокоит раздувание rpm базы?  rpm база раздувается
AT> от java заведомо не больше, чем раздувается /usr.  То есть намного
AT> меньше, конечно же.

От жабы все раздувается, она большая и тяжелая -- всех задавит.

У меня и так каждый запуск apt повод для перекура, тормоз он.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Ничто так не ограничивает полёт мысли программиста, как компилятор.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Java: no magic wand

[Damir Shayhutdinov]

У меня тут возникла довольно безумная идея, но может сработать.

Вот основные тезисы:

0. Чтобы было проще понять нижеприведенное, подумайте над следующей аналогией:

a) jar-файл аналогичен файлу динамической библиотеки .so
б) классы в jar-файлах аналогичны символам в динамических библиотеках .so

1. Вводится понятие зависимости между .jar-файлами, и информация об
этих зависимостях хранится в самих .jar-файлах в пока не оговоренном
виде.

2. Если a.jar зависит от b.jar, это означает, что
   a) при загрузке a.jar в переменной CLASSPATH _должен_
присутствовать b.jar (зависимость загрузчика). Эти зависимости
транзитивны(рекурсивны), то есть если запускается

java -jar c.jar,

и если c.jar зависит от a.jar, а тот в свою очередь от b.jar - то в
CLASSPATH должны присутствовать a.jar и b.jar.
   б) при установке пакета содержащего a.jar в систему также должен
быть установлен пакет содержащий b.jar (rpm зависимости) - это
следствие пункта a)

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

  a) Сделать программку, которая внедрит в .jar-файл список его
зависимостей, с возможностью ручной коррекции этого списка
пользователем (фильтровать ненужные зависимости/добавлять незамеченные
автоматикой). Эта программа видимо будет требовать, чтобы все
зависимые .jar-файлы уже были установлены в системе (иначе будет
непонятно какой .jar-файл соответствует каким классам). Набросок такой
программы я уже тут приводил. Предлагаю по аналогии назвать ее
"линковщиком".

Пример: javalink foo.jar --auto --include bar.jar --exclude baz.jar -
в файл foo.jar внедряется информация о зависимостях, состоящая из
автоматически определенных зависимостей, к которым добавлен bar.jar и
исключен baz.jar. Возможно, можно ввести ключ --no-unresolved, который
проваливает линковку, если обнаруживает зависимость на .class, который
не может найти в установленных .jar-файлах.

  б) Научить загрузчик .jar-файлов автоматически и рекурсивно
извлекать граф зависимостей загружаемого .jar-файла и добавлять их в
CLASSPATH (примерно подобное делает ld-linux.so.2).

  в) Научить rpm анализировать список зависимостей .jar-файлов и
генерировать для них нужные rpm-зависимости.

Фактически, список зависимостей .jar файлов в таком случае будет
аналогом секций NEEDED в ELF. Или зависимостей в либтульных .la файлах
для статических библиотек (тут аналогия вообще прямая).

Что мы получаем при такой схеме:
1. Из-за нового загрузчика java исчезнет нужда в правильном заполнении
CLASSPATH.
java -jar foo.jar само заполнит CLASSPATH.

2. Возможность подавления автоматически сгенерированных
зависимостей/добавления ручных зависимостей не только для rpm, но и
для загрузчика Java. Без правильных зависимостей .jar просто не
запустится - следовательно все зависимости будут достаточными. Конечно
зависимости могут быть избыточными - но пока это нам не очень важно, а
в дальнейшем можно будет сделать типа --as-needed.

3. RPM-ные зависимости генерируются автоматически из информации,
внедренной линковщиком. Зависимости будут на уровне jar-файлов, а не
классов, что по идее облегчит нагрузку на базу rpm/apt.

4. По идее, для такой системы можно сделать аналог verify-elf, который
определяет "недолинкованность", то есть зависимости на .class-файлы,
которые не покрываются прилинкованными .jar-файлами. При этом можно
выдавать как warning, так и error.

Минусы у такого подхода я вижу следующие:
1. Как и у soname-интерфейса, если какой-то класс перекочевал из X.jar
в Y.jar, все .jar-файлы, "слинкованные"(прямо или рекурсивно) с X.jar
и не "слинкованные" с Y.jar откажутся запускаться. Выход такой же -
пересборка + возможное введение дополнительных идентификаторов типа
SONAME

2. Если один и тот же класс находится в двух разных .jar-файлах,
автоматическое определение зависимостей "линковщиком" может повести
себя неправильно, для этого надо предусмотреть нужные ручки.

3. Искусственность процесса "линковки" - вряд ли удастся внедрить
процесс линковки в саму сборку, это надо ant перелопачивать, значит
придется запускать его уже после сборки.

Вот собственно и все, жду комментариев.

Re: [devel] Java: no magic wand

[Igor Vlasenko]

On Wed, Jan 16, 2008 at 08:30:31PM +0300, Damir Shayhutdinov wrote:
DS> У меня тут возникла довольно безумная идея, но может сработать.
Гм, почему безумная?
О подобной системе я как раз и думаю...

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

Чтобы она советовала, а не вредительством занималась. 

DS> Вот основные тезисы:
DS> ...
Диавол, как известно, скрывается в деталях,
соберусь со свободным временем и попытаюсь 
обсудить их в отдельном письме.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] Java: no magic wand

[Alexander Bokovoy]

Damir Shayhutdinov пишет:
> Минусы у такого подхода я вижу следующие: 1. Как и у
> soname-интерфейса, если какой-то класс перекочевал из X.jar в Y.jar,
> все .jar-файлы, "слинкованные"(прямо или рекурсивно) с X.jar и не
> "слинкованные" с Y.jar откажутся запускаться. Выход такой же - 
> пересборка + возможное введение дополнительных идентификаторов типа 
> SONAME
> 
> 2. Если один и тот же класс находится в двух разных .jar-файлах, 
> автоматическое определение зависимостей "линковщиком" может повести 
> себя неправильно, для этого надо предусмотреть нужные ручки.
> 
> 3. Искусственность процесса "линковки" - вряд ли удастся внедрить 
> процесс линковки в саму сборку, это надо ant перелопачивать, значит 
> придется запускать его уже после сборки.
> 
> Вот собственно и все, жду комментариев.
4. Модификация загрузчика java сделает получившийся комплекс формально
несовместимым с Java в терминах SUN.
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] Java: no magic wand

[Damir Shayhutdinov]

> 4. Модификация загрузчика java сделает получившийся комплекс формально
> несовместимым с Java в терминах SUN.
Вообще нет, ведь результат работы модифицированного загрузчика по моей
идее - всего лишь автоматически сформированный CLASSPATH, а дальше в
дело вступает обычный Java-загрузчик. Впрочем, может я чего-нить
недодумал, возможно и потребуется несовместимая с SUN реализация.

Re: [devel] Java: no magic wand

[Alexander Bokovoy]

Damir Shayhutdinov пишет:
>> 4. Модификация загрузчика java сделает получившийся комплекс
>> формально несовместимым с Java в терминах SUN.
> Вообще нет, ведь результат работы модифицированного загрузчика по
> моей идее - всего лишь автоматически сформированный CLASSPATH, а
> дальше в дело вступает обычный Java-загрузчик. Впрочем, может я
> чего-нить недодумал, возможно и потребуется несовместимая с SUN
> реализация.
Это формально модификация виртуальной машины, так что изменение
потребует сертификации у SUN, для того, чтобы называться Java.

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] Java: no magic wand

[Igor Vlasenko]

On Wed, Jan 16, 2008 at 10:25:43PM +0300, Alexander Bokovoy wrote:
> Damir Shayhutdinov пишет:
> > Вот собственно и все, жду комментариев.
> 4. Модификация загрузчика java сделает получившийся комплекс формально
> несовместимым с Java в терминах SUN.

Так там и не нужна модификация. Достаточно генератора classpath.

Для запуска java программ все равно приходится писать скрипты - обертки.

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

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] Java: no magic wand

[Igor Vlasenko]

On Wed, Jan 16, 2008 at 08:30:31PM +0300, Damir Shayhutdinov wrote:
> Вот основные тезисы:

Спасибо, буду комментировать:
 
> 0. Чтобы было проще понять нижеприведенное, подумайте над следующей аналогией:
> 
> a) jar-файл аналогичен файлу динамической библиотеки .so
> б) классы в jar-файлах аналогичны символам в динамических библиотеках .so
> 
> 1. Вводится понятие зависимости между .jar-файлами, и информация об
> этих зависимостях хранится в самих .jar-файлах в пока не оговоренном
> виде.

Хотел бы отметить, что аналогия недостаточно точная, 
и если ее уточнить, то выводы другие.

IMHO,
jar-файл аналогичен файлу статической библиотеки .a .
В статической библиотеке каждый .o файл независим от других,
и будь .o файлы глобально уникальными, на них можно было бы 
высчитывать fine-grained зависимости.
Просто в C для статических библиотек это никому не нужно.

А динамическая библиотека --- это нечто особенное, в ней
.o файлы кросс-линкованы и сплавлены в одно целое, наружу
торчит только интерфейс.

Поэтому там зависимость на часть библиотеки проставить нельзя,
и динамические библиотеки .so -- минимальная единица.

В jav'e же вполне реально вычислять точные зависимости 
(классов на классы) которые не раздувают /usr.

и 1) чем хороши внешние тесты, что в них можно иметь
оба вычислителя зависимостей (jar- и class- based)

2) достаточно вычислять/проверять зависимости
для jar c приложениями. Как я показывал в письме,
токрывшем тред, зависимости библиотек на библиотеки
вообще говоря, и не нужны.

Они возникают как особенность реализации менеджера
зависимостей.


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] Java: no magic wand

[Igor Vlasenko]

On Wed, Jan 16, 2008 at 08:30:31PM +0300, Damir Shayhutdinov wrote:
>   a) Сделать программку, которая внедрит в .jar-файл список его
> зависимостей, с возможностью ручной коррекции этого списка
> пользователем (фильтровать ненужные зависимости/добавлять незамеченные
> автоматикой). Эта программа видимо будет требовать, чтобы все
> зависимые .jar-файлы уже были установлены в системе (иначе будет
> непонятно какой .jar-файл соответствует каким классам). Набросок такой
> программы я уже тут приводил. Предлагаю по аналогии назвать ее
> "линковщиком".

Не обязательно хранить эту информацию в самом файле.
Достаточно знать имя jar файла как ключ.
 
> Пример: javalink foo.jar --auto --include bar.jar --exclude baz.jar -
> в файл foo.jar внедряется информация о зависимостях, состоящая из
> автоматически определенных зависимостей, к которым добавлен bar.jar и
> исключен baz.jar. Возможно, можно ввести ключ --no-unresolved, который
> проваливает линковку, если обнаруживает зависимость на .class, который
> не может найти в установленных .jar-файлах.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] Java: no magic wand, no magic hammer

[Igor Vlasenko]

On Mon, Jan 14, 2008 at 10:08:36AM +0300, Денис Смирнов wrote:
DS> On Thu, Jan 10, 2008 at 10:41:06PM +0200, Igor Vlasenko wrote:
DS> IV> Java: no magic wand.
DS> IV> --------------------

DS> Выводы верны, но не все предпосылки верны.

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

> IV> 1) стандартные названия библиотек 
> IV> [никому из нас и в голову не придет собирать libz как 
> IV> libaltz и пытаться продавливать в апстримы патчи
> IV> вида s/-lz/-laltz/ либо паковать Pod::Parser как 
> IV> Documents::Pod::Parser], не зависящие от названия пакета
> IV> (zlib или libz или libaltz, perl или perl-Pod или 
> IV> perl-PodDocumentUtils)

DS> Я правильно понимаю, что если я говорю о Jetty, то я говорю об
DS> org.mortbay.*, например?
DS> 
DS> Поясняю мысль -- у Java нет понятия "библиотека". Есть понятие "класс" и
DS> "каталоги поиска". Эти каталоги могут быть заzipованы, и тогда это jar.

Далее для простоты не будем различать случаи "каталог поиска" и jar, 
так как различие только в синтаксисе и способе хранения.

DS> Но jar не обладает практически никакими свойствами нормальной библиотеки.
DS> Хотя по своей сути сильно напоминает старые добрые .a библиотеки.

Вот теперь начнем разборку.

Возьмем к примеру класс org.viy.Example1 .
Q: что будет, если сказать 
$java org.viy.Example1 
?
A: java.lang.NoClassDefFoundError

Q: почему?
A: не указан -classpath /usr/share/java/viy-example.jar
или -classpath /home/viy/example/build 
. Вот мы и увидели в аргументах вызова 
папку /home/viy/example/build 
и архив /usr/share/java/viy-example.jar.
Обе сущности и являются хранилищами кода java --
java - библиотеками.
Как видим, без указания библиотеки запустить программу
не удалось.

Q: неправда! я сделал
java -classpath /usr/share/java/* org.viy.Example1
и программа нормально отработала 
без всякого указания библиотек!

A: вам везет! org.viy.Example1 лежал только в одном месте - 
в viy-example.jar и зависимостей у него сложных не было.

Попробуйте такой трюк с тем же org.mortbay.jetty, 
особенно если рядом по зависимостям установлены jetty5 и jetty6. 
Там несколько библиотек - загрузятся вперемешку 
и начнут между собой Великую Войну За Тапки.

/usr/share/java - это не библиотека, а одно из мест, где 
библиотеки искать. Было бы нечто вроде /usr/lib,
умей java сама искать org.viy.Example1. 

я считаю аналогию /usr/share/java и /usr/lib обманчивой,
точнее будет соответствие /usr/share/java/** и /usr/lib.
но пусть будет. Тогда -classpath /usr/share/java/*
соответствует линковка ./hello_world cо всеми библиотеками из
/usr/lib --- кошмарная противоположность -Wl,--as-needed.

Q: и что это доказывает?
A: что понятие библиотеки не сводится к понятию класса.
Зная все классы, необходимые для запуска приложения, 
мы тем не менее не сможем слинковать и запустить его,
не указав библиотеки, т.е. места, где эти классы находятся.

DS> IV> 2) стандартная (мета)информация о зависимостях
DS> IV> (выполнена ли она в виде директивы import в питоне
DS> IV> либо находится в заголовке ELF binary file)
DS> 
DS> Они самые, import в Java-исходнике. И ссылки на конкретные классы уже в
DS> .class. Так что это уже есть.

Это зависимости на классы. И они нужны, но из 1) видно, что этого 
мало, для запуска нужно знать библиотеки (рыбные места :) )
Иногда это одно место, тогда все просто и очевидно.
Но в важных достаточно частых случаях их много и так было задумано.


DS> Мы здесь имеем слишком тонкую нарезку правда. Единицей у нас является
DS> класс/интерфейс, но никак не "библиотека". К счастью у нас единица не
DS> "отдельный метод" чему можно сильно радоваться.

IMHO, хорошая библиотека экспортирует методов не намного больше, чем
jar архив - public классов.


DS> Хотя у нас есть еще одна вещь -- в META-INF может быть жестко прописаный
DS> classpath. Я не знаю какие недостатки у этого решения, но плюсы очевидны:
DS>  - можно делать простые файловые зависимости
DS>  - их удовлетворение может автоматически означать возможность запустить
DS>    приложение

jpackage policy не зря запрещает жестко прописаный в META-INF classpath.

см. 
http://www.freesource.info/wiki/Altlinux/Policy/Java/ClassPathInManifest

The Class-Path system of MANIFESTs is evil
http://jpackage.org/jpprequest.php

https://www.zarb.org/pipermail/jpackage-discuss/2003-June/002095.html


Кроме того, добавлю к вышесказанному, что
с одной стороны, это аналог -rpath, а стандартных мест, 
где может быть библиотека, несколько, наподобие /lib и /usr/lib. 
Посмотрите "Глава 3. Структура директорий"
http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation#h11610-10

скрипт build-classpath обходит все эти места, чтобы найти нужную библиотеку.
Тот же самый $(build-classpath xml-commons-apis) может развернуться
в /usr/share/java/xml-commons-apis.jar, а может в
/usr/lib/jvm-exports/jre-1.6.0-sun/xml-commons-apis.jar -> /usr/lib/jvm/java-1.6.0-sun-1.6.0.04/jre/lib/rt.jar

Как и в сишных библиотеках, в дистрибутиве -rpath скорее мешает.

С другой стороны, и это killer, жестко прописаный в META-INF classpath
сделает такие библиотеки непригодными для разработчика.

Так бы люди использовали для своих проектов дистрибутивные jar,
но с жестко прописаным в META-INF classpath поведение программы
с такими библиотеками будет на чужой машине разрушительно непредсказуемым.
Кто знает, что и какой версии оно там загрузит, чтобы начать
Великую Войну За Тапки ?

Придется искать jar'ы по файлопомойкам интернета, откуда угодно,
но только не из родного дистрибутива. Кому тогда они вообще нужны?


DS> IV> 4) стандартный загрузчик, который используя 2) рекурсивно
DS> IV> ищет 1) в 3).
DS> Увы. Такой загрузчик даже теоретически можно написать (!), учитывая
DS> alternatives.

Так я ж в том письме теоретически его и написал :)

Хочу только подчеркнуть, что им нужно заканчивать, 
а ни в коем случае не начинать.
Дом строится не с крыши, а с фундамента.

Так что no magic wand, no magic hammer.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] Java: no magic wand, no magic hammer

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 6456 bytes --]

On Mon, Jan 14, 2008 at 11:59:16PM +0200, Igor Vlasenko wrote:

IV> Далее для простоты не будем различать случаи "каталог поиска" и jar, 
IV> так как различие только в синтаксисе и способе хранения.

У jar есть еще метаинформация. Кстати в обычных каталогах она может
лежать? (я про classpath, собственно).

DS>> Но jar не обладает практически никакими свойствами нормальной библиотеки.
DS>> Хотя по своей сути сильно напоминает старые добрые .a библиотеки.
IV> Вот теперь начнем разборку.
IV> Возьмем к примеру класс org.viy.Example1 .
IV> Q: что будет, если сказать 
IV> $java org.viy.Example1 
IV> ?
IV> A: java.lang.NoClassDefFoundError
IV> Q: почему?
IV> A: не указан -classpath /usr/share/java/viy-example.jar
IV> или -classpath /home/viy/example/build 
IV> . Вот мы и увидели в аргументах вызова 
IV> папку /home/viy/example/build 
IV> и архив /usr/share/java/viy-example.jar.
IV> Обе сущности и являются хранилищами кода java --
IV> java - библиотеками.
IV> Как видим, без указания библиотеки запустить программу
IV> не удалось.

Это как и со "скомпилировать программу на C" -- нужен соответствующий
.a/.so.

IV> Попробуйте такой трюк с тем же org.mortbay.jetty, 
IV> особенно если рядом по зависимостям установлены jetty5 и jetty6. 
IV> Там несколько библиотек - загрузятся вперемешку 
IV> и начнут между собой Великую Войну За Тапки.

А вот тут как раз наиболее интересная ситуация. Пакет не может требовать
одновременно jetty5 и jetty6 (у них, к счастью, даже имена многих важных
классов разные). Однако многие совпадают, и это надо разруливать.

IV> /usr/share/java - это не библиотека, а одно из мест, где 
IV> библиотеки искать. Было бы нечто вроде /usr/lib,
IV> умей java сама искать org.viy.Example1. 

Нет! /usr/lib также потребует от программиста указать библиотеку. Поиск
symbols в /usr/lib производится не будет.

IV> я считаю аналогию /usr/share/java и /usr/lib обманчивой,
IV> точнее будет соответствие /usr/share/java/** и /usr/lib.
IV> но пусть будет. Тогда -classpath /usr/share/java/*
IV> соответствует линковка ./hello_world cо всеми библиотеками из
IV> /usr/lib --- кошмарная противоположность -Wl,--as-needed.

Именно так. Жуткое зрелище.

IV> Q: и что это доказывает?
IV> A: что понятие библиотеки не сводится к понятию класса.
IV> Зная все классы, необходимые для запуска приложения, 
IV> мы тем не менее не сможем слинковать и запустить его,
IV> не указав библиотеки, т.е. места, где эти классы находятся.

Да! Библиотеки в java это скорее аналоги обычным symbols в библиотеках.

Необходимости ручного указания библиотек это не отменяет.

И принципиальная разница только в одном:

 - предположим некий класс A требует для своей работы класс B.
 - некое приложение N требует для своей работы класс A.

У этого приложения можно в classpath прописать ссылку на библиотеку,
содержащую A. Но работать это не будет. Нужно прописывать и на B.

В случае же с shared objects у них есть собственные зависимости.

То есть по факту нам надо иметь у приложения зависимости и на A, и на B
(что в C было бы нужно исключительно при статической линковке).

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

DS> IV>> 2) стандартная (мета)информация о зависимостях
DS> IV>> (выполнена ли она в виде директивы import в питоне
DS> IV>> либо находится в заголовке ELF binary file)
DS>> Они самые, import в Java-исходнике. И ссылки на конкретные классы уже в
DS>> .class. Так что это уже есть.
IV> Это зависимости на классы. И они нужны, но из 1) видно, что этого 
IV> мало, для запуска нужно знать библиотеки (рыбные места :) )
IV> Иногда это одно место, тогда все просто и очевидно.
IV> Но в важных достаточно частых случаях их много и так было задумано.

Угу.

DS>> Мы здесь имеем слишком тонкую нарезку правда. Единицей у нас является
DS>> класс/интерфейс, но никак не "библиотека". К счастью у нас единица не
DS>> "отдельный метод" чему можно сильно радоваться.
IV> IMHO, хорошая библиотека экспортирует методов не намного больше, чем
IV> jar архив - public классов.

Только вот мы не ставим зависимости на функции библиотек -- мы ставим
зависимости на symbol versions. Если бы у нас были зависимости на функции
glibc, база rpm требовала бы отдельного storage с двумя ручками для
переноски.

DS>> Хотя у нас есть еще одна вещь -- в META-INF может быть жестко прописаный
DS>> classpath. Я не знаю какие недостатки у этого решения, но плюсы очевидны:
DS>>  - можно делать простые файловые зависимости
DS>>  - их удовлетворение может автоматически означать возможность запустить
DS>>    приложение
IV> jpackage policy не зря запрещает жестко прописаный в META-INF classpath.
IV> см. 
IV> http://www.freesource.info/wiki/Altlinux/Policy/Java/ClassPathInManifest
IV> The Class-Path system of MANIFESTs is evil
IV> http://jpackage.org/jpprequest.php
IV> https://www.zarb.org/pipermail/jpackage-discuss/2003-June/002095.html

Прочитаю.

IV> скрипт build-classpath обходит все эти места, чтобы найти нужную библиотеку.
IV> Тот же самый $(build-classpath xml-commons-apis) может развернуться
IV> в /usr/share/java/xml-commons-apis.jar, а может в
IV> /usr/lib/jvm-exports/jre-1.6.0-sun/xml-commons-apis.jar -> /usr/lib/jvm/java-1.6.0-sun-1.6.0.04/jre/lib/rt.jar
IV> Как и в сишных библиотеках, в дистрибутиве -rpath скорее мешает.

Гхм. Как раз для дистрибутива спорное утверждения -- мы можем знать куда
будет ссылка.

IV> С другой стороны, и это killer, жестко прописаный в META-INF classpath
IV> сделает такие библиотеки непригодными для разработчика.
IV> Так бы люди использовали для своих проектов дистрибутивные jar,
IV> но с жестко прописаным в META-INF classpath поведение программы
IV> с такими библиотеками будет на чужой машине разрушительно непредсказуемым.
IV> Кто знает, что и какой версии оно там загрузит, чтобы начать
IV> Великую Войну За Тапки ?
IV> Придется искать jar'ы по файлопомойкам интернета, откуда угодно,
IV> но только не из родного дистрибутива. Кому тогда они вообще нужны?

До конца не понимаю почему такая проблема может возникнуть именно в
дистрибутиве.

IV> Так что no magic wand, no magic hammer.

С этим согласен :)

Хотя от таких бы и не отказался :)

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
И Ленин не на Си писал пpогpамму...

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Java: no magic wand, no magic hammer

[Igor Vlasenko]

On Tue, Jan 15, 2008 at 10:59:38AM +0300, Денис Смирнов wrote:
> On Mon, Jan 14, 2008 at 11:59:16PM +0200, Igor Vlasenko wrote:
> 
> IV> Далее для простоты не будем различать случаи "каталог поиска" и jar, 
> IV> так как различие только в синтаксисе и способе хранения.
> 
> У jar есть еще метаинформация. Кстати в обычных каталогах она может
> лежать? (я про classpath, собственно).

Гм. ничто не мешает положить туда META_INF/MANIFEST.MF.
Правда, как я понимаю, java (runtime) туда не сотрит.
но другие смотрят, в том же OSGi, например.

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

Среди наиболее популярных отмечу
среди встроенных в jar - 

OSGi manifest (поля вида Bundle-*)
как 
Bundle-ManifestVersion: 2
Bundle-Name: SpoonJdt Plug-in
Bundle-SymbolicName: fr.inria.spoon.jdt.builder; singleton:=true
Require-Bundle: org.eclipse.ui,
 org.eclipse.core.runtime,
Export-Package: fr.inria.spoon.jdt,
 fr.inria.spoon.jdt.builder.internal
Import-Package: org.eclipse.jdt.internal.ui.preferences,
 org.eclipse.jdt.internal.ui.wizards.dialogfieldsдоп. 
...

Обсуждение
http://felix.apache.org/site/presentations.data/osgi-apachecon-20060628.pdf

Среди внешних -
maven- описания с помощью POM - файлов (xml)

и symbol-db, используемую в gcj.

в частности, OSGi platform имеет, по сути, весь велосипед -
метаинформацию, пути, стандартные имена, загрузку - но только 
для своих сервисов.

У нас в Сизифе почти треть java пакетов имеет описание в виде POM файлов,
и около 2% имеет еще OSGi manifest.

В перспективе хотелось бы, чтобы каждая библиотека имела и POM, 
и OSGi manifest, поскольку это реально нужно для сборки проектов 
на maven либо на платформе eclipse, но это будет долгая 
и кропотливая ручная работа, 
которая, возможно, никогда не дойдет до 100%.
Поэтому это не платформы для AutoReq/AutoProv.

Я сам склоняюсь к какому-то аналогу symbol-db,
но, как и говорил, попытаюсь все это опробовать в тестах.


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine