ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: "Денис Смирнов" <mithraen@altlinux.ru>
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: Tue, 15 Jan 2008 10:59:38 +0300
Message-ID: <20080115075938.GB25533@mw.local.seiros.ru> (raw)
In-Reply-To: <20080114215916.GA19907@dad.imath.kiev.ua>

[-- 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 --]

  reply	other threads:[~2008-01-15  7: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   ` [devel] Java: no magic wand, no magic hammer Igor Vlasenko
2008-01-15  7:59     ` Денис Смирнов [this message]
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=20080115075938.GB25533@mw.local.seiros.ru \
    --to=mithraen@altlinux.ru \
    --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