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амму...