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

Вт Янв 15 10:59:38 MSK 2008

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амму...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.altlinux.org/pipermail/devel/attachments/20080115/7479cade/attachment.bin 