Это последняя часть серии — и самая плотная. Поля-коллекции и повторяющиеся субрепорты, что именно роняет сборку, как собирается карта параметров в рантайме и что происходит на старте приложения.

Дальше — про две версии движка: шаблоны у шестой и седьмой несовместимы, и одного файла на обе не бывает. Плюс пример целиком, переход с 2.0.x и честный список шероховатостей: где подход неудобен, где он не работает и кому он не подходит вовсе.

Последнее — про цену проверки при компиляции. Шаблоны лежат в ресурсах приложения, а структура отчёта — в Java-классах, значит любая правка идёт через сборку и деплой. Если отчёты у вас меняются чаще, чем выкатывается приложение, подход вас затормозит — и лучше знать об этом заранее.

Третья часть серии — практическая. Как подключить библиотеку к Maven-проекту, написать первый модульный отчёт и что после этого происходит с шаблоном при сборке.

Субрепорт — это класс, отчёт — тоже класс, а поля класса и есть содержимое отчёта. Имена параметров шаблона берутся из имён полей, поэтому один и тот же модуль можно поставить в отчёт дважды и получить два независимых субрепорта со своими данными. Аннотационный процессор при компиляции находит существующий JRXML, дописывает в него недостающие параметры, датасеты и банды субрепортов и кладёт результат в target/generated-sources. Шаблон в src он не трогает никогда.

Отдельно — про то, кто владеет шаблоном, когда в один файл пишут и кодогенератор, и человек в Jaspersoft Studio, и где у этой схемы слабое место.

Первая часть — откуда взялся Jasper и почему он так устроен, вторая — один стандарт и три идеи.

Во второй части серии — чего ждёт от инструмента отчётов современный Java-разработчик и на каких идеях я собрал свою надстройку над JasperReports — не переписывая движок и не отказываясь от Jaspersoft Studio.

Один стандарт вместо нескольких способов передать данные: в отчёт едут обычные Java-объекты. Дерево вместо плоской сетки банд: отчёт собирается из модулей, вложенных друг в друга, включая повторяющиеся. Слои: данные добывает Java, вёрстка остаётся в JRXML и в Studio. И объект как единый носитель структуры, данных и имён — вместо одного и того же смысла, продублированного и в XML, и в коде.

Отдельно — ответ на возражение из комментариев к первой статье: зачем вообще выносить выборку данных из шаблона, если Jasper умеет ходить в базу сам.

Первая часть серии — откуда взялся Jasper и почему он так устроен.

JasperReports появился в самом начале нулевых: румынский разработчик Теодор Данчу делал большой Java-проект, где нужно было формировать и печатать много сложных документов, а готовые решения оказались проекту не по карману. Прошло двадцать пять лет, движок жив и широко используется, а работают с ним примерно так же, как тогда. И на это есть причины, которые лежат в его происхождении.

В первой части серии — откуда взялся Jasper и почему он устроен именно так. Почему отчёт умеет сам ходить в базу и что из этого выросло: несколько разных способов передать в него данные, ручной вайринг субрепортов через строковые имена параметров и роли разработчика и верстальщика, между которыми нет чёткой границы. Плюс короткий срез состояния движка в 2026 году.

Это не критика. Ядро у Jasper мощное, просто он наследник другой традиции — той, где отчёт является самостоятельным приложением, а не частью вашего.

Работать с JasperReports тяжело — данные передаются хрупкими механизмами, бизнес-логика утекает в XML, а субрепорты требуют ручной синхронизации между Java и JRXML. jasper-modular-library решает это: отчёт описывается деревом POJO с аннотациями, процессор генерирует JRXML при компиляции, а рантайм собирает всё автоматически. В статье — типичные подходы к передаче данных и их проблемы, и как библиотека их устраняет.