ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: Alexey Rusakov <ktirf@altlinux.org>
To: devel@lists.altlinux.org
Subject: Re: [devel] java dependencies
Date: Sat, 9 Jun 2007 03:51:41 +0400
Message-ID: <20070609035141.571e203e@mission> (raw)
In-Reply-To: <20070608153903.GA7815@solemn.turbinal>

On Fri, 8 Jun 2007 19:39:03 +0400
Alexey Tourbin wrote:

> Я переделал rpm-build-java (см. /people/at/packages/rpm-build-java.git).
> Статус экспериментальный и недоделанный (подразумевает новый rpm-build,
> которого пока нет в сизифе), но основные моменты продуманы.
> 
> Вкратце, я предлагаю реализовать поиск зависимостей на основе точной
> информации из *.class файлов, и примерно с такой же гранулярностью (на уровне
> *.class файлов, см. ниже насчет вложенных классов).  Также можно сохранить
> Provides зависимости на уровне *.jar файлов (для совместимости с JPackage),
> но все Requires зависимости я предлагаю перевести на уровень *.class файлов.
> 
> (Для тех, кто совсем не в курсе, поясню, что *.jar файлы -- это zip-архивы,
> которые содержат в себе много-много class-файлов -- байткод.  Java умеет
> смотреть в *.jar архивы как в обычные каталоги и отыскивать там class-файлы.
> Но все реальные зависимости имеют место быть между class-файлами, а не
> jar-архивами.  Дальше можно не читать.)
> 
> Предлагаемый формат зависимостей имеет вид java(java.lang.Object).
> 
> Я пока не во всём разобрался, поэтому ищу специалистов по java (особенно по JVM).
> 
> Я прочитал спецификацию "VM Spec: The class File Format"
> http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html
> и буквально по этой спецификации написал на перле парсер class-файлов, который
> в первом приближении умеет извлекать зависимости.  Похожий парсер есть в
> rpm/tools/javadeps.c, но мой парсер получился в несколько раз короче и проще,
> так что написание с нуля я не считаю убитым временем.
> 
> Парсер называется jcf-reqprov (java class file, по аналогии с jcf-dump из gcc)
> и умеет полностью парсить константный пул и таблицу классов (см. VM Spec).
> Предыдущий предельно упрощенный парсер из java.req (egrep -hao 'L[a-zA-Z/_]+;')
> делал совсем не то что нужно, хотя и выдавал какие-то зависимости.
> 
> Следующий вопрос адресован специалистам по JVM.  Хотелось бы не просто парсить
> константный пул и таблицу классов, а дополнить парсер семантикой зависимостей,
> чтобы можно было сказать, в чем именно состоит зависимость на некоторый класc
> (например, суперкласс, суперинтерфейс и т.п.).  Поддержка семантики
> зависимостей в первом приближении мной уже продумана, но пока как следует не
> работает.  Мне хотелось бы знать, в каких именно случаях JVM ЗАГРУЖАЕТ другой
> class-файл, когда видит на него ссылку.  Например, если некоторый метод умеет
> брать аргумент с типом некоторого другого объекта:
> 	ThisClass.Method(arg=OtherClass)
> означает ли это, что JVM сразу же, в процессе начальной обработки
> (компиляции) ThisClass, будет также (физически) загружать и OtherClass?
> Или же загрузка OtherClass в некотором смысле откладывается, то есть,
> например, происходит по факту вызова ThisClass.Method(arg) откуда-то ещё?
Насколько я ничего не понимаю в JVM, загрузка класса происходит
непосредственно перед использованием его имени в программе (то есть не
при начальной обработке точно). Но есть одно "но": существуют Just-in-Time,
и, хуже того, Ahead-of-Time компиляторы, которые на это поведение могут
существенно повлиять, в частности, поднимая какие-то классы раньше
времени.
Но честно говоря, мне сама идея описания зависимостей в терминах
классов видится неудачной; это не слишком отличается от описания
зависимостей между библиотеками на C в терминах конкретных
предоставляемых/используемых функций. Далеко не все публичные классы на
самом деле рассчитаны на использование снаружи - это мог быть где-то
недогляд программиста, а где-то класс оставили публичным просто "на всякий
случай, вдруг кому пригодится". И перечислять все классы в зависимостях
rpm, имхо, неразумно. Уж лучше изобрести некую концепцию, сходную с
версионированием динамических библиотек.

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team


  parent reply	other threads:[~2007-06-08 23:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-08 15:39 Alexey Tourbin
2007-06-08 17:25 ` Igor Vlasenko
2007-06-08 23:51 ` Alexey Rusakov [this message]
2007-06-09 10:47 ` Igor Vlasenko
2007-06-09 10:54   ` Epiphanov Sergei

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=20070609035141.571e203e@mission \
    --to=ktirf@altlinux.org \
    --cc=devel@lists.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