Я переделал 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) откуда-то ещё?

Другими словами, семантика зависимостей нужна для того, чтобы отделить существенные
зависимости, без которых точно нельзя обойтись при начальной загрузке данного
class-файла, от вторичных зависимостей, загрузка которых, возможно, является
необязательной, т.е. они сами по себе загружаются откуда-то ещё.  Этим я пытаюсь
сказать, что в rpm-зависимостях у rpm-пакета нужно писать только реально
необходимые классы, а не просто все имена классов, которые удается извлечь
неким нехитрым способом (с помощью dumb парсера).

Перехожу к техническим подробностям.  Я также переделал java.req и сделал
комплементарный java.prov.  Первый положительный результат: поиск Requires
зависимостей в пакете j2se1.5-sun-1.5.0.11-alt4 дал нулевой результат -- все
Requires взаимно уничтожаются с Provides, т.е. зависимости замкнуты.

Несколько менее положительным результатом следует считать размер as-is Provides
зависимостей у этого же пакета -- около 440K (всего около 10000 классов).  При
этом уже используется одна довольно сильная оптимизация -- исключение т.н.
private классов (см. VM Spec).  Впрочем, использование ещё двух эвристических
оптимизаций (хаков) позволило уменьшить список Provides до 120K (всего около
3000 классов в Provides), что уже более приемлемо, хотя и на грани.

Сгруппируем список as-is provides пакета j2se1.5-sun по префиксам:

$ cut -d. -f-2 prov |sort |uniq -c |sort -n |tail
    207 java(java.util
    215 java(sun.text
    258 java(sun.nio
    322 java(sun.awt
    327 java(sun.io
    385 java(java.awt
    399 java(sun.security
    536 java(org.omg
    851 java(javax.swing
   3456 java(com.sun
$

Отсюда видно, что первая эвристическая оптимизация списка provides должна
состоять в том, чтобы исключить (взаимно уничтожить) зависимости вида
java(com.sun.*) и java(sun.*).  Такие зависимости, по идее, относятся к
особенностям реализации и не должны выходить за рамки этой реализации.

Другая менее очевидная оптимизация, которая позволяет сократить размер
зависимостей ещё примерно на 20%, состоит во взаимном уничтожении зависимостей
"с долларом".  Зависимости типа java(Class$Subclass) появляются, когда файл
Class логически содержит в себе вложенный (полностью объявленный и
реализованный) класс Subclass.  В таком случае зависимость на Class$Subclass
должна полностью сводиться на Class.  Эта оптимизация несколько ухудшает
гранулярность зависимостей, особенно с учетом того, что в java нет средств
версионирования классов.  Однако избавление от bloat (излишнего груза)
представляется скорее привлекательным.  Зависимости "с долларом" кажутся
всё же не слишком органичными (ну, не очень красивыми) для rpm-пакетов.