Thank you for the explanation. 🙂

I had always assumed that surely Hibernate must know the java types of it’s parameters at the time hql types are decided, after all the hql produced usually matches the java type closely. I guess in reality it’s just really good at type guessing. But I can see how relying on any amount of type guessing is undesirable in terms of minimizing unexpected behavior.

What would have helped me getting to the bottom of this earlier is an error message that expresses why hibernate even attempted the coercion in the first place.
I initially thought that Hibernate was deriving the hql type from the java type of my parameter and for some reason my field’s java type was used to determine the parameter’s hql type whereas it should’ve been my parameter’s java type. See also the title of this issue 😄

In any case, I’ll be using the cast for my arithmetic operand parameters from now on. If Hibernate ever improves it’s automatic type inference so that the explicit casting is no longer required I’d be happy but doing it if and only if a good rule can be made seems quite reasonable.