From: Igor Vlasenko <vlasenko@imath.kiev.ua>
To: ALT Linux Team development discussions <devel@lists.altlinux.org>
Cc: java@altlinux.org
Subject: Re: [devel] Java: no magic wand, no magic hammer
Date: Mon, 14 Jan 2008 23:59:16 +0200
Message-ID: <20080114215916.GA19907@dad.imath.kiev.ua> (raw)
In-Reply-To: <20080114070836.GB28583@mw.local.seiros.ru>
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
next prev parent reply other threads:[~2008-01-14 21:59 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-10 20:41 [devel] Java: no magic wand Igor Vlasenko
2008-01-14 7:08 ` Денис Смирнов
2008-01-14 17:08 ` Igor Vlasenko
2008-01-15 7:48 ` Денис Смирнов
2008-01-15 22:30 ` Alexey Tourbin
2008-01-16 16:29 ` Igor Vlasenko
2008-01-16 16:40 ` Dmitry V. Levin
2008-01-18 3:00 ` Денис Смирнов
2008-01-16 17:30 ` Damir Shayhutdinov
2008-01-16 18:28 ` Igor Vlasenko
2008-01-16 19:25 ` Alexander Bokovoy
2008-01-16 19:35 ` Damir Shayhutdinov
2008-01-16 19:39 ` Alexander Bokovoy
2008-01-16 19:39 ` Igor Vlasenko
2008-01-17 9:38 ` Igor Vlasenko
2008-01-17 9:44 ` Igor Vlasenko
2008-01-14 21:59 ` Igor Vlasenko [this message]
2008-01-15 7:59 ` [devel] Java: no magic wand, no magic hammer Денис Смирнов
2008-01-15 17:54 ` Igor Vlasenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080114215916.GA19907@dad.imath.kiev.ua \
--to=vlasenko@imath.kiev.ua \
--cc=devel@lists.altlinux.org \
--cc=java@altlinux.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
ALT Linux Team development discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
public-inbox-index devel
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.devel
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git