Создал с нуля библиотеку для JasperReports, которая делает работу с ним легкой

Если речь про «собрать запрос в Java и прокинуть параметром» ($P!{} в <queryString>) - это шаг в правильную сторону, логика выборки уходит в Java, согласен. Но полумера:

• шаблон всё равно сам исполняет SQL - значит держит REPORT_CONNECTION, живой коннект к БД внутри слоя представления. Связь с базой никуда не делась.

• поля (<field> + типы) всё равно вписываются в JRXML руками и синхронятся вручную - передача запроса это не решает.

• $P!{} - сырая подстановка: риск SQL-инъекции и строковая типизация без проверки на компиляции.

И главное: если запрос уже строится в Java — зачем останавливаться на полпути и реализовывать функции репозитория в шаблоне отчета? Исполни его там же и передай в отчёт данные (типизированный DTO-список), а не запрос. Тогда шаблон вообще не касается БД. Это ровно то, что делает библиотека.

Разница в одной точке: передаёшь запрос (шаблон его исполняет, держит коннект) или данные (шаблон только рендерит). Ваш же инстинкт «строить в Java», доведённый до конца, и приводит к передаче данных вместо запроса.

Если схема таблиц меняется, то это уже проблема поддержки

в этом и суть - библиотека позволяет отделить репортинг от ДБ миграции и централизовать поддержку все на уровне Java-модели - поменяли/добавили/убрали поля - в jrxml получите автоматом обновленные параметры с нужныи типами - как бы JasperStudio не был удобен - все равно руками перепрописывать поля.

Ну и по моему глубокому убеждению - jrxml - это только каркас для данных, как HTML разметка. Откуда пришли данные и какие пережили трансформации и калькуляции - за пределами скоупа. Репозитории + Сервисный слой становятся единым источником правды

сделал версию 2.0.1 - убрал разделение артефактов по разным версиям JR - так что теперь унифицировано можно пользоваться

Создал с нуля библиотеку для JasperReports, которая делает работу с ним легкой

-

Создал с нуля библиотеку для JasperReports, которая делает работу с ним легкой

всё, включая загрузку данных

Вы имеете ввиду SQL вызов непосредственно из JRXML файла? Если да, то я вижу здесь 3 проблемы:

1. сам запрос становится статичным и неизменяемым - для выполнения например дополнительной сортировки или фильтрации необходимо менять весь JRXML файл (либо держать его разные версии для разных видов запросов)

2. любая миграция схемы базы данных порождает риски несоответствия полей (или их типов) с филдами JRXML

3. нарушение принципов Separation of Concerns и Single Responsibility

Дополнительно - нужно вручную вписывать все поля ожидаемого из БД ответа и их типы в JRXML - не самая приятная часть работы:

<jasperReport ...>
    <queryString>
        <![CDATA[
            SELECT id, name, salary
            FROM employees
            WHERE department = $P{departmentName}
        ]]>
    </queryString>

    <parameter name="departmentName" class="java.lang.String"/>

    <field name="id" class="java.lang.Integer"/>
    <field name="name" class="java.lang.String"/>
    <field name="salary" class="java.math.BigDecimal"/>
</jasperReport>

Поэтому библиотека реализует в сущности подход аналогичный MVC - данные и модели между слоями не смешаны, что обеспечивает гибкость разработки, а JRXML отвечает только за репрезентацию данных (как фронтенд) и может потреблять любым способом отфильтрованные отсортированные и скалькулированные данные (на тот случай если вы передаете не просто данные намапленные с entity но некую агрегацию их)

нужно ещё использовать обёртку, которая данные вытаскивает

Аннотационный процессор вытаскивает их на этапе компиляции поэтому разработчик получает в /target готовый JRXML в котором все данные предсталены в нужном виде и с точной типизацией.