Robert Rittwag ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *commented* on HHH-15743 ( https://hibernate.atlassian.net/browse/HHH-15743?atlOrigin=eyJpIjoiYjg0Mz... ) Re: Querying with empty parameter list fails ( https://hibernate.atlassian.net/browse/HHH-15743?atlOrigin=eyJpIjoiYjg0Mz... ) I get your point. And I respect it. In my former comment I forgot a third and quite important aspect: The widely used Spring Framework and its module Spring Data JPA encourage using queries the way I described. Because of their mechanism of generated repositories ( https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#repos... ) it is quite easy to implement a query this way: @Repository public interface UserRepository extends JpaRepository<User, Long > { List<User> findAllByDepartmentIn( @Param( "deparment" ) List<Department> departments, Sort sort); } This repository method generates a Hibernate query and makes providing departments mandatory (empty list returns 0 result, null returns IllegalArgumentException). Spring 5 (with Hibernate 5) made it easy to provide optional departments : @Repository public interface UserRepository extends JpaRepository<User, Long > { @Query( "from User u " + "where COALESCE(:departments) is null or u.department in (:departments)" ) List<User> findAllByOptionalDepartmentIn( @Param( "departments" ) List<Department> departments, Sort sort); } With Spring 6 (including Hibernate 6) I have to implement it via Criteria API and Custom Repositories ( https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#repos... ) , which is more costlier and verbose: interface CustomizedUserRepository { List<User> findAllByOptionalDepartmentIn(List<Department> departments, Sort sort); } public class CustomizedUserRepositoryImpl implements CustomizedUserRepository { @Autowired private EntityManager em; @Override public List<User> findAllByOptionalDepartmentIn( @Param( "departments" ) List<Department> departments, Sort sort) { CriteriaBuilder cb = em.getCriteriaBuilder(); CriteriaQuery<User> cr = cb.createQuery(User.class); Root<User> root = cr.from(User.class); if (departments != null && !departments.isEmpty()) cr.select(root).where(root.get( "department" ).in(departments)); // TODO: add some sort magic return em.createQuery(cr).getResultList(); } } @Repository public interface UserRepository extends JpaRepository<User, Long >, CustomizedUserRepository { } My point is: The newly released Spring 6 leaves a lot of Spring 5 users asking why and how to migrate their simple queries. That's why I created this issue … and was talking about shady "workaround solutions" 🙂 . ( https://hibernate.atlassian.net/browse/HHH-15743#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-15743#add-comment?atlOrigin=ey... ) Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=Em... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100210- sha1:eab5823 )