Можно ли подружить Stream API и JPA?

Решение очень интересное. Убивает его только одно - отсылка некой таинственной статистики на третью сторону. На это прямо указывает их документация https://speedment.github.io/jpa-streamer/jpa-streamer/1.0.1/introduction/introduction.html#_phone_home:

JPAstreamer sends certain data back to Speedment’s servers as described here. If you wish to disable this feature, please contact us at info@jpastreamer.org.

Похоже на очень странную политику монитезации, которая не даст шансов широкому распространению продукта.

Имхо, недопустимо использовать библиотеку с представленными политиками, особенно если это не pet project. А делать это еще и без явного согласия - крайне некорректно. И на сколько я понимаю это блоккер для многих:

Кто согласен, апвотим здесь: https://github.com/speedment/jpa-streamer/issues/156.

Идея, крутая, но...

Мне не нравится введение дополнительных сущностей, бесполезных для бизнес-логики. Чем меня в своё время сильно бесила Java EE: вместо использования POJO-объекта на все случаи жизни с обычными конструкторами она вносила целый зоопарк всяких мета-сущностей (для базы Entity, для клиента DTO, для логики бизнес-классы, итого три класса на по сути одну сущность), с особыми правилами создания через всякие абстрактные фабрики декораторов и со своим жизненным циклом в каждом конкретном случае. Spring в какой-то степени смог обойтись без этой избыточности, хоть и не везде, потому и выиграл.

Вот и здесь вместо стнадратных функциональных интерфейсов Stream API предполагается использование каких-то очередных сгенерированных мета-классов и мета-методов.

Я не хочу работать над оптимизацией, я хочу, чтобы над оптимизацией работала библиотека.

Я хочу просто написать

var books = jpaStreamer.stream(Book.class)
       .filter(x -> x.getYear() >= 2020)
       .toList();

и сразу получить

Hibernate: select book0_.id as id1_1_, book0_.author_id as author_i5_1_, book0_.price as price2_1_, book0_.title as title3_1_, book0_.year as year4_1_ 
from book book0_ where book0_.year>=?

безо всякой мета-модели и паразитных сущностей.

Да, идея супер. В свое время, лет 5 назад, написал обертку на CriteriaBuilder в похожем стиле и теперь тащу ее из проекта в проект. Обертку писал, потому что с этими классами CriteriaBuilder, Root, Query сам черт ногу сломит в части их связи между собой. Хотелось построение запроса в Spring хоть отдаленно похожее на стиль SQL, а не вот это вот всё

А не лучше сразу на jooq перейти вместо этого всего?