[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 перелопачивать, значит
придется запускать его уже после сборки.

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