Spring Data JPA 4.2.0-SNAPSHOT constructs a count query during AOT processing for every annotated string query, named query, and PartTree query. Generated repository code and serialized query metadata consume the count query only when JpaQueryMethod.isPageQuery() is true, so count construction for collection, slice, stream, scalar, modifying, and other non-Page methods is discarded.
In a representative application, only 11 of 729 annotated queries return Page, and ten of those already declare an explicit count query. The current AOT path derives 719 count queries and discards 718 of them.
A cold ReAI-shaped batch of 534 distinct HQL queries on JDK 26 improved from 476.739 ± 33.917 ms and 258.70 MB to 377.378 ± 42.443 ms and 161.72 MB when non-Page count construction was skipped. That is 20.84% less time and 37.49% less allocation; the ten-fork SingleShotTime 99.9% confidence intervals do not overlap.
A permanent JMH benchmark exercising the real JpaRepositoryContributor measured 2,755.374 ± 190.198 ops/s and 643,085.654 ± 1,661.271 B/op before, versus 5,049.177 ± 85.772 ops/s and 372,740.263 ± 1,662.209 B/op after: 83.25% more throughput and 42.04% less allocation across three forks. The 99.9% confidence intervals do not overlap.
The proposed change returns after constructing the result query when the method is not a page query. Page-query behavior, including explicit, named, and derived count queries, remains unchanged. Focused tests cover annotated string, named, and PartTree non-Page paths; the existing page-query test continues to verify derived count construction.
Spring Data JPA 4.2.0-SNAPSHOT constructs a count query during AOT processing for every annotated string query, named query, and PartTree query. Generated repository code and serialized query metadata consume the count query only when
JpaQueryMethod.isPageQuery()is true, so count construction for collection, slice, stream, scalar, modifying, and other non-Page methods is discarded.In a representative application, only 11 of 729 annotated queries return
Page, and ten of those already declare an explicit count query. The current AOT path derives 719 count queries and discards 718 of them.A cold ReAI-shaped batch of 534 distinct HQL queries on JDK 26 improved from 476.739 ± 33.917 ms and 258.70 MB to 377.378 ± 42.443 ms and 161.72 MB when non-Page count construction was skipped. That is 20.84% less time and 37.49% less allocation; the ten-fork SingleShotTime 99.9% confidence intervals do not overlap.
A permanent JMH benchmark exercising the real
JpaRepositoryContributormeasured 2,755.374 ± 190.198 ops/s and 643,085.654 ± 1,661.271 B/op before, versus 5,049.177 ± 85.772 ops/s and 372,740.263 ± 1,662.209 B/op after: 83.25% more throughput and 42.04% less allocation across three forks. The 99.9% confidence intervals do not overlap.The proposed change returns after constructing the result query when the method is not a page query. Page-query behavior, including explicit, named, and derived count queries, remains unchanged. Focused tests cover annotated string, named, and PartTree non-Page paths; the existing page-query test continues to verify derived count construction.