-=Koba=-А Почему нельзя расширить текущую enity?

Потому что ORM-зло! :-)
А так, обычно при использовании сущностей join делается ч/з @ManyToOne, а не ч/з создание новых сущностей.

-=Koba=-mad_nazgul,

А как длеать сложные запросы?

Ч\з ORM и Entity Framework - никак.

-=Koba=-Petro123,

Ну есть сложный запрос который нужен для построения отчета
Имеет несколько join group

Как такое выполнить

Сейчас работает с помощью nativeQuery

Я думал перевести на criteriBuilder но застопорился на расширении user"? можно конечно продублировать его, но все же.

IMHO criteriaBuilder лучше не пользоваться "от слова совсем".
Преимуществ перед SQL запросом почти никаких, а вот недостатки есть.
1) Ограничение. Данный фреймворк намного уступает по гибкости SQL
2) Сложность. Довольно сложен для понимание. "Простой" запрос, написать не совсем просто
3) Многословность. Писать придется много
4) "Не прозрачность". Вы слабо контролируете какой запрос будет на выходе. Для того, чтобы знать какой будет запрос, надо очень хорошо знать "кишки" CriteriaBuilder'а
5) Нельзя заняться "любимым" занятием DBA - оптимизацией запросов

Единственное сомнительное преимущество это создание динамических запросов.
Почему сомнительное.
Потому что при почти одинаковых запросах план запроса может очень сильно отличаться по времени.

Если нужны сложные динамические запросы, то постарайтесь использовать JDBC, с мапингом в POJO-объекты.
1) Это будет проще.
2) Запросы потом будет легче оптимизировать.

-=Koba=-Petro123,

Цель одинакова способы достижения разные

А параметры как передаете
Или может есть small пример или tuturial ? как вы генерите?

У меня сейчас через native sql или criteria формируются лист бинов
И далее передаю + параметры репорту

Зачем так сложно?
Когда можно просто в JasperStudio рисовать отчет с соответствующими запросами и параметрами.
В отчет из приложения передаются только нужные параметры.

-=Koba=-Вот именно так и реализовано....
Про то, чтоб развернуть отдельный сервер для 3-4 отчетов, ну это по-моему слишком

Вот.
А передавать классы в отчет как-бы не надо.
Только простые типы.
А уже в самом отчете соответствующие запросы.

sanBezPetro123,

Ага )))
Просто меня удивляет. У ТСа налажена разработка через бины. У меня кстати тоже.

А вы ему бах кувалдой по голове: бросай свои бины нафиг, sql рулит.
Ну нельзя же так

Дык у него возникла проблема.
Мы тут просто объясняем, что проблема в использовании бинов, для построения отчетов.

Желательно, чтобы отчет был самодостаточным.
Т.е. на вход принимал только простые типы, для построения отчета.

Если же нужны отчеты, со сложной выборкой в зависимости от бизнес-логики реализованной в коде, тогда возможно нужно/можно передавать бины.

Я редко встречал такие отчеты.

Был конечно аналитический отчет.
Но там БД была сделана таким образом, что каждое свойство хранилось в отдельной таблице их было много.
Причем предполагалось, что количество таблиц будет расти, а отчет переделываться не будет.
Пришлось задействовать ХП, которые по определенным параметрам находили все эти таблицы, потом делался курсор, который и отдавался.
Хотя с помощью бинов это было бы попроще.

-=Koba=-Только не совсем понятен ход работы в таком случае, где хранятся сами SQL запросы?
На уровне сервера и я передаю готовые сформированны SQL
Или в самих отчетах jassper и передаю туда только параметры

У нас было так:
Специально обученные аналитики/программисты рисовали отчет в iReport (тогда еще не было JapserStudio).
Там же писали запрос с параметрами.
А мы просто вызывали нужный нам отчет, передавая параметры.

Поэтому никаких бинов, и прочих entity не было.
SQL + ХП

Отчет был "автономным".
Т.е. мог выполняться, как в iReport, так и в приложении.
Только соединение к БД настрой.
И его легко было "отладить". Т.к. там по факту нужно было написать запрос/запросы (если отчет с подотчетами)