> We will add the following 2 methods to the QueryBuilder(now CriteriaBuilder) > interface to support the JPQL semantics of returning Long when integers are > summed and Double when floats are summed:

My understanding is that the return types for aggregation function in criteria queries should follow the same rules as defined for JPAQL. So first, is that a correct understanding? The confusion is the type signatures of the builder methods, espcially the ones that "change" based on the argument types. SUM, for example, says the following in the JPAQL section: <quote> SUM returns Long when applied to state fields of integral types (other than BigInteger); Double when applied to state fields of floating point types; BigInteger when applied to state fields of type BigInteger; and BigDecimal when applied to state fields of type BigDecimal. </quote> So for a SUM of int or Integer fileds, JPAQL is clearly expecting back a Long. The CriteriaBuilder sum method, however, is defined as: <N extends Number> Expression<N> sum(Expression<N> x); Which implies that when applied to an int or Integer field/expression should return an Integer. Yes, I realize the last spec version added the sumAsDouble/sumAsLong methods, but that is still not really the same as the JPAQL rules. The TCK does explicitly have a test for this btw and we are currently failing. *However* even the test notes show the confusion here as it states: <quote> Execute a query which contains the aggregate function SUM. SUM returns Long when applied to state-fields of integral types. </quote> Unfortunately as soon as it says that is goes off and actually asserts the return is a Integer ;) So I am trying to decide if this need be a challenge based on "alignment with JPAQL rules", a challenge based on something else you might see or an inconsistency JPA users will have to live with? -- Steve Ebersole <steve(a)hibernate.org&gt; Hibernate.org